WebApp Sec mailing list archives
RE: SQL Injection Basics
From: "Brass, Phil (ISS Atlanta)" <PBrass () iss net>
Date: Thu, 13 Feb 2003 11:37:22 -0500
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
Current thread:
- Re: SQL Injection Basics, (continued)
- Re: SQL Injection Basics Jim McGarvey (Feb 11)
- Re: SQL Injection Basics Mark Curphey (Feb 11)
- Re: SQL Injection Basics Jim McGarvey (Feb 12)
- Re: SQL Injection Basics dreamwvr () dreamwvr com (Feb 12)
- Re: SQL Injection Basics Jim McGarvey (Feb 11)
- RE: SQL Injection Basics David Cameron (Feb 11)
- RE: SQL Injection Basics Mark Mcdonald (Feb 11)
- RE: SQL Injection Basics Jason Benson (Feb 12)
- RE: SQL Injection Basics David Cameron (Feb 12)
- Re: SQL Injection Basics Alex Russell (Feb 12)
- RE: SQL Injection Basics David Cameron (Feb 12)
- RE: SQL Injection Basics Brass, Phil (ISS Atlanta) (Feb 13)
- Re: SQL Injection Basics Bart McKinnley (Feb 14)