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. |

| 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>
| Previous by Date: | RE: XSS, SQL injection etc - permutations of input strings, Scovetta, Michael V |
|---|---|
| Next by Date: | Re: XSS, SQL injection etc - permutations of input strings, Devdas Bhagat |
| Previous by Thread: | Re: XSS, SQL injection etc - permutations of input strings, James Barkley |
| Next by Thread: | Re: XSS, SQL injection etc - permutations of input strings, focus |
| Indexes: | [Date] [Thread] [Top] [All Lists] |