Re: XSS, SQL injection etc - permutations of input strings

[Ben Timby <asp () webexc com>]

Mike, while this is true, going thru the motions of exploiting the hole 
does three additional things.

1. It is fun. :-).

2. Proves the problem is serious. Some shops can't fix all the problems 
at one time, so priority can be set for more serious flaws. While all 
flaws should be fixed eventually, this is the real world, and sometimes 
developer bandwidth is at a premium.

3. May allow the tester to uncover other flaws in underlying application 
layers.

I read somewhere that IT security is like an onion, and I think this is 
true. If you are able to peel back the first layer, and see what is 
behind it, you may uncover problems that would be hidden otherwise. This 
is a general observation, I could possibly provide specific examples of 
what I mean if you like.

Hope that helps.

Mike Andrews wrote:
> 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?