Databases as a compromise damage limiter in web applications

June 7, 2011

Here is a thought that I have been toying around with lately: you could say that one attraction of using databases in web applications is that they limit the damage from an application compromise.

You can at least conceptually separate web applications into the 'computation' (such as it may be) and the backend data storage. Historically, many web application vulnerabilities have given the attacker various sorts of unfiltered access to the backend storage system (usually this is some variety of passthrough attack where parameters are not filtered enough).

When your backend database is an actual database (SQL or otherwise), all the attacker gets is, well, access to the SQL database. This is damaging, but generally the damage is confined to the contents of the database. However, when your backend storage is files in the filesystem unfiltered access will often give an attacker access to the entire filesystem, not just the directory hierarchy you are using as a data store; they can read and sometimes write all sorts of files outside of your 'database'. This is an unconfined breach (and in some situations can almost immediately escalate to code execution, for example by dropping files into places where they will be executed by further web requests).

Or to put it more simply: if your program never opens any files, it's a lot harder to persuade it to open the wrong one. Using a database gets you storage without having to actually open any files.

(I doubt that this is why very many people pick a database backend for their web application, though. There are lots of other reasons, including that someone else has already written the storage system for you.)

This thought came to mind lately because I have been thinking about relaxing DWiki's constraints on file IO. DWiki uses the filesystem for all of its storage, and as a result I made the storage backend very limited and very cautious about what it did; these limits are now starting to be inconvenient. But, of course, the more I relax the limits the closer I am to one mistake giving an attacker full filesystem access.

Comments on this page:

From at 2011-06-10 00:19:24:

Did you consider simply putting Dwiki into a chroot?

By cks at 2011-06-10 02:01:19:

The short answer is that a chroot would be too complicated; it requires a great deal of setup work, special privileges, and complicates actually using DWiki to write things.

From at 2011-06-12 15:24:18:

Of course, this doesn't help if people can call system commands from the DB itself, although limiting the commands the user the database runs as helps. Nor does it help if attackers can gain access to the DB password hashes and people who use the DB use the same passwords for the system itself, although good hashes can help to mitigate there.

Generally though, you're correct. Not that you need my validation. :-)


Written on 07 June 2011.
« How much space a Python dictionary entry uses
OpenBSD pf rule numbers and tcpdump filtering »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Jun 7 01:14:37 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.