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: Mon, 20 Sep 2004 22:20:55 -0500
Hello Mike,

Saturday, September 18, 2004, 6:15:54 PM, you 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.

While sometimes it seems odd to continue bashing away at certain
points, consider it a good method to establish what else lies beneath.
You might be able to find out a lot more, and find further weaknesses
in other points of the system. Consider it like a punctured tire,
simply covering the hole doesn't mean you fixed the issue, you just
averted all the air escaping. To really fix the issue, you need to
remove the nail, and plug it correctly. You can never know when a code
change in another location might have an unsuspecting affect on the
"fix" you put over that hole, or if it'll leave a new hole to a
security issue you could have discovered by bashing away at the same
hole that was discovered before.

-- 
Jonathan Angliss
<jon@netdork.net>

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