Re: SQL Injection Basics

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

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

> Communication between the layers takes the

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

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

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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

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----- Received on Wed Feb 12 22:16:28 2003

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek