RE: (clarification) GET and POST Methods Accepted

["Amit Klein (AKsecurity)" <aksecurity () hotpop com>]

On 13 Oct 2005 at 13:24, Evans, Arian wrote:

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

Yes, e.g. JSP pages (request.getParameter(...) doesn't distinguish between body parameters 
and query parameters, the page can usually be called either way), and ASP.NET (similar).

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

I think in those platforms that don't distinguish between query and body parameters, we're 
likely to see this much more often, as there's no motivation for the developer to make this 
distinction.

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

The question is how you define a vulnerability. In the discussions so far, I haven't seen a 
case (in this thread at least) wherein chnaging POST to GET (say) is problematic, except 
for the user himself/herself (we talked about data leakage through logging and Referer). So 
this leaves us with an XSS vector (only), and that is still technically exploitable with 
POST much as it is with GET (up to the point of the need of an external site).
In other words, if it all boils down to the fact that it's easier to run a phishing (or URL 
spoofing) XSS attack, then I expect the vulnerability scanner to pick the XSS hole and 
point at the root cause.
I'm not saying that accepting GET where POST is expected is a good practice. I would 
definitely prefer not to have such "functionality" in any application. But without a good 
argument (i.e. this is a vulnerability, and this is how it can be exploited), I'm not sure 
vulnerability scanner vendors would be happy to include it (I'm not taking a stance here 
though).

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

I suppose I'd like us to continue this thread.

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

But I didn't say there isn't an attack surface increase! I said:
"So XSS on POST method URLs isn't much more complicated than XSS on GET URLs."
And it was all in response to Ed's statement "POST is still
attackable, but it becomes more complicated than simply emailing a link.", to which I 
objected (and I still object).
I didn't refer to phishing (and URL spoofing) like vectors.
 
> 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.

I agree to all of the above, and as I said, my original post was about XSS only, not about 
the ease of spoofing a URL for the attack.

-Amit