RE: (clarification) GET and POST Methods Accepted

["Evans, Arian" <Arian.Evans () fishnetsecurity com>]

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