Re: SQL Injection Basics

[Alex Russell <alex () netWindows org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 12 February 2003 04:29 pm, David Cameron wrote:
> Consider that case where you have three layers, resulting in two
> boundaries, where communication between the layers is
> asynchronous/disconnected. 

this is the case we are most interested in with webapps.

> Communication between the layers takes the
> form of fire and forget messages. Suppose then a message were sent from
> the top layer to the bottom layer. Boundary checking at boundary 1 raises
> no problems, however boundary checking at layer 2 finds a problem. There
> are two ways of managing this: ignore the message or try to communicate
> the error to higher layers. Obviously the latter option is preferable.

to some extent, communicating failure or policy violation between layers is 
much less important than making sure that each "layer" can watch it's own 
back.

> If you performed the checking in the first layer this would not be a
> problem. On the other hand the first layer should not necessarily be
> "aware" that there are layers below that. The way we got around this was
> to force the first layer to wait for a reply message.

I don't think that's strictly necessaray is most webapps. Rather, each layer 
should only worry about threats that are going to affect THAT LAYER. 
Nothing else. If you implement filtering this way, you require that 
developers touch more sections of code (and obvious drawback), but you 
increase the survivability of any layer, and you reduce your depency on a 
single point of failure (say, doing all your filtering at one layer, and 
expecting to know everything that comes after it and the problems that can 
be exposed at those layers).

I put togeather a short handout for a talk I gave not too long ago on the 
topic, perhaps it'll be useful?

        http://alex.netwindows.org/owasp/filters/owasp_filters_handout.pdf

> In case you are wondering if there would be a situation where this might
> actually occur, any situation where part of the chain is "disconnected",
> could cause this problem. 

taking boundary filtering to it's logical conclusion, one pretty much stops 
caring about communicating policy violations across boundaries, but instead 
starts carring about logging for later analysis. It's a tradeoff: have 
monolithic or synchronous filtering mechanisms that report everything that 
happens (and then require that those errors pass filtering at every stage) 
with the potential for much better error "bubbling", or take a "dumber is 
better" approach and worry about introspecting on failure modes only after 
each part of a system is locked down.

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).

But like I said, there are plenty of situations where this is sub-optimal. 
Doing it this way satisfies some needs I can see in webapps, but might not 
be as relevant for some types of apps.

- -- 
Alex Russell
alex () netWindows org
alex () SecurePipe com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+Sam1oV0dQ6uSmkYRAkFnAJ0XGNdR7GbbECT+e6Lf7ODuVoZT+wCdH5vX
mizSufUoA9Y2YxQ+sJrJNMA=
=R9LU
-----END PGP SIGNATURE-----