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: (clarification) GET and POST Methods Accepted

Subject: RE: (clarification) GET and POST Methods Accepted
Date: Thu, 13 Oct 2005 13:24:02 -0500
Some great responses but I'm not sure they are following the
intended question about GET used where POST is expected.

The simple version of the question is:

How often do you see applications that accept a GET where they
should be or are only intending to receive a POST?

There are a number of differences between GET and POST in terms
of attack surface, from storage of sensitive data in server logs
to ability to launch attacks from a pre-formed URL string.

While we are all for more discussion about the security implications
of using GET versus POST, the questions I'm seeking to answer are
(don't want to speak for Ed here, but I think we're on the same page):

1) Are other people seeing that the applications they test
accept GETs where they are intended/expecting to accept POSTs?

2) Are you seeing this more or less on specific platforms?

3) Anyone know why none of the automated tools test this?

4) Does anyone on the list find this issue worth discussing/addressing
in more detail?

I have to disagree with Amit about degree of triviality. There is
an attack surface increase using GET over POST.

I believe we've broken this down pretty thoroughly, both regarding
theory and what attacks we are seeing being used in the wild (and
in the wild almost everything I've seen is encoded URL strings).

For the example of XSS:

Link/GET has unique triviality in that the attack can use natural
domain names in links, e.g.--xss_victim_site.com

versus having to use injection_site.com to POST to the former.

That's one layer of social engineering and browser-anti-spoof
bar defense type hiccup removed from having to link to a secondary
site and then POST to the target_victim_site.

Thoughts? Clarifications? Corrections?

-ae





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