Home page logo

webappsec logo WebApp Sec mailing list archives

Re: SQL Injection
From: David Cameron <david () uberconcept com>
Date: Wed, 16 Jun 2004 00:04:01 +1000

> Exactly. I think that Alex Russell first started talking about "boundary
> validation" [1] (although I think that Sverre Huseby was talking about
> the concept previously), which refers to making sure that content
> inappropriate for the "service" on the other side of the boundary is
> appropriately filtered. This could be done on either side of the
> boundary, of course, but is not restricted to "input filtering".

Boundary filtering is an excellent concept which aids in good application design. However it can add to the complexity in other ways. As I pointed out in the referenced discussion it pushes the error checking further from the source of the error. In addition to that, in some cases the source of the error might be the only place where this problem may be solved. I talked about this as a problem only in an asynchronous environment, I think it has wider application though. I'll try to explain using an example.

Suppose you have a web application that goes something like this (MS platform:

Front End(1)  Bus Logic(2)      DB(3)
ASP.Net -------> MSMQ ------> SQL Server
        <------- COM <-------

Applying Boundary filtering, SQL injection and basically data that would be filtered between 2 and 3. Taking the example further. Suppose you have a comments which is represented at the web app as a textbox and in the database as a VarChar(2000) column. Consider the case where someone enters 2001 characters into the field. As far as the web application is concerned, text is text and how much text should be allowed is a concern for the database. If the update is sent to an asynchronous MSMQ process, what action should be taken if it fails at the boundary? The solution proposed by Alex (http://seclists.org/lists/webappsec/2003/Jan-Mar/0163.html) would be to drop the relevant message and log the issue for later. However from the user perspective the comment has been updated, there haven't been any errors, despite the fact that the comment hasn't in fact been updated.

Now consider that there may be further tiers between 2 and 3. The problem then becomes more difficult again. I believe is better to ensure that "exceptions" are passed back up the tree until the reach a place where they can be dealt with (in the example, all the way back to the user). In an asynchronous environment this may need to be implemented using some sort of call back system (verifying the update). I think this error handling "chain" is a common structure in OO systems.

David Cameron

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]