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
