RE: SQL Injection Basics

["Brass, Phil (ISS Atlanta)" <PBrass () iss net>]

> Sorry about the lateness of this. Just had a thought as to a 
> situation where boundary filtering could be difficult to 
> implement. I actually ran across this when working on my BE thesis.
>
> Consider that case where you have three layers, resulting in 
> two boundaries, where communication between the layers is 
> asynchronous/disconnected. 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.

A third options is to have the second layer fix the problem, for example
by performing appropriate escaping or filtering.  Boundary testing does
not need to result in an error.  The way I see it, the point of boundary
testing is that each layer should be aware of the issues posed by the
next layer down, especially for those layers that you have not yourself
written, such as SQL databases, HTML browsers, perl scripts,
command-line processors, XML parsers, XSLT processors, etc.  For these
layers, it is necessary for the calling layer to be aware of safety
issues in the 3rd party layers and ensure that input to that layer is
safe.  

In particular, generating a client-visible error for all boundary test
failures is a great way for an attacker to map your boundary testing
capabilities.  For example, if you are returning an error if any "bad"
characters are in a form field, an attacker will simply send request
after request with each ASCII character (and possibly each unicode)
value to see what your filter looks like.

One thought I have had about this, for those app developers with too
much time on their hand, would be to generate valid-seeming error
messages when boundary tests fail and you can't sanitize the data.  The
key is to do this in a way that is confusing but not obviously random.
My thinking is, hash the field, then use the hash (say the bottom byte)
to lookup error messages in a table.  That way, the same error message
is always returned for the same value (thus not clueing the attacker in
when he gets 10 different error messages for the exact same request),
but each different erroneous submission will result in a different error
message.  Kind of a honey-pot for attackers (and, sadly, pentesters),
since they are likely to spend hours trying to figure out the method to
the madness...

Phil