Wandering Thoughts archives


Databases as a compromise damage limiter in web applications

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.

web/DatabasesAsCompromiseLimiters written at 01:14:37; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.