Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

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

Subject: Re: XSS, SQL injection etc - permutations of input strings
Date: Sun, 19 Sep 2004 04:00:45 -0500
Good point.. but i think in some organizations unless you show the
full extent of what could happen if the problem is not fixed, they are
not likely to waste time and effort to fix it in a timely manner
before things go haywire

~Harrison

On Sat, 18 Sep 2004 19:15:54 -0400, Mike Andrews <mike@se.fit.edu> 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?

Cheers,
Mike

----
Mike Andrews
Florida Institute of Technology





-- 
___________________________________
Harrison Gladden <hgladden@gmail.com>
Computer Engineer & Science Major
~Past experience: He who never makes 
   mistakes, never did anything that's worth.~

<Prev in Thread] Current Thread [Next in Thread>