RE: SQL Injection Basics

> Sorry about the lateness of this. Just had a thought as to a

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 Received on Thu Feb 13 13:04:29 2003