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: (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> |
|---|---|---|
| ||
| Previous by Date: | Re: User verification questions, Gary Gwin |
|---|---|
| Next by Date: | RE: GET and POST Methods Accepted, Joe Teff |
| Previous by Thread: | XSS & SQL injection "determining false positives", mike king |
| Next by Thread: | RE: (clarification) GET and POST Methods Accepted, Joe Teff |
| Indexes: | [Date] [Thread] [Top] [All Lists] |