WebApp Sec mailing list archives

XSS, SQL injection etc - permutations of input strings


From: "Mike Andrews" <mike () se fit edu>
Date: Sat, 18 Sep 2004 19:15:54 -0400

Over the past few days I've seen many posts about different ways of encoding
XSS/SQL injection strings, as well as leveraging a discovered vulnerability
in order to get more information about the target (other DB fields/schema).

The question I'd like to ask the list is once you know a particular input
vector is vulnerable, why are people trying to push the exploit further,
assuming that they are pen-testing rather than hacking the target?  For the
uninformed client, being able to show them that you 0wn3 their server/app
once should be enough to treat *any* discovered flaw as serious enough to
fix, even if it's only a JS alert box, a "or 1=1", or a "select from another
table" attack.

My assumption here is a tester should use a variety of inputs to see how an
application responds, but when it's clear that there's a defect somewhere
you report the flaw back to the developers, telling them what/when/how, etc,
then work with them to ensure they only accept *valid* input and not just
filter for all of the ways you've attacked the flaw.  There's obviously
alternative inputs (i.e. debugging to help understand the defect),
re-testing issues, and ensuring the fix actually did what it was supposed
to, but my belief is that once developers know they have a problem (for
whatever reason) they are in much better position to put in a generic fix.

Any thoughts on this.  What is the point of extending an attack to (for
example) discover the entire DB schema unless it is just showing off?


Cheers,
Mike

----
Mike Andrews
Florida Institute of Technology



Current thread: