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

["Eyal Udassin" <eyal () swiftcoders com>]

Hi Mike,

Well, technically speaking you're absolutely right. Once an injection/xss
vulnerability has been discovered there's no added value to further
exploiting that vulnerability. It's just there :-)

Unfortunately applications should not be looked upon in a pure technical
manner. They serve a business process of the organization and as such it is
crucial (to my belief) to demonstrate the possible implications of leaving
the vulnerability unattended.
Regarding the show-off claim - some of the times you're right, nothing wrong
with putting your skills to the test every once in a while. However, most of
the time it's just helping the people in charge understand the potential
risks in a language they best understand - money, clients and competitors.

Cheers,
Eyal Udassin
Swift Coders

-----Original Message-----
From: Mike Andrews [mailto:mike () se fit edu] 
Sent: Sunday, September 19, 2004 1:16 AM
To: webappsec () securityfocus com
Subject: XSS, SQL injection etc - permutations of input strings


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