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
