RE: SQL Injection Basics

["David Cameron" <dcameron () itis-now com>]

I suspect I am going beyond the bounds of the original poster's questions, but I'll run with this anyway. I enjoyed 
your handout.

> I can easily see needs for systems taht provide much more robust feedback 
> about error conditions that we are proposing with the OWASP Filters, but I 
> think that for the majority of situations we're going to be dealing with 
> are either one-way or logically asynchronous requests (requests that may be 
> currently implemented in a synchronous way but aren't garunteed to be so in 
> the future) that won't strictly need that kind of reporting. Oftentimes, we 
> dump data into a database and request it back 5 months later. In that case, 
> I'm going to care much more that my scripting environment is safe when 
> pulling the data back out than I am about whether or not the SQL layer had 
> to do something to keep itself protected 5 months ago (at which point, my 
> logging will be a much more timely indicator of a problem).
>
> So I'm taking the approach that it's much better to worry about integrity 
> first, and let things fail "silently" across borders (but not be silent to 
> a central logging facility), than it is to communicate state across 
> boundaries, something that both increases complexity of the tools and 
> requires that both sides of the boundary understand the error codes being 
> transmitted (thereby making implementation of filtering more complex and 
> less granular).

Just one short comment.

I agree that the primary concern of the programmer (in this area) is data integrity, but once that is met, the next 
concern is usability. Let's take the web app example. A user fills in a form and posts it. As we are running 
asynchronously there is no information on whether that data has made it to the db successfully or not. If they then 
examine a page that reports on that data, they may be surprised to find that it is not there. From a user perspective 
the system has failed.

> From a user perspective this could be very dangerous. Suppose they are uploading files to a document m'ment system. 
> User uploads the file. No indication of any errors. User then deletes the file because it is now stored on the web and 
> therefore is no longer needed.

In the case of a web app I guess the solution to the problem would be to query the database for the data to check if it 
has inserted correctly to provide report on the insert to the user.

Don't get me wrong, I really like the idea of boundary filtering. In fact I think it is one of the most intelligent 
security innovations I have heard of for a while. I just see some problems arising when applied to asynchronous systems.

regards
David Cameron
nOw.b2b
dcameron () itis-now com