WebApp Sec: Re: SQL Injection

[David Cameron <david () uberconcept com>]

> 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.
regards
David Cameron