On 14 Oct 2005 at 10:05, <webappsec@securityfocus.com> wrote:
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).
Re-thinking on this, I'd throw in some other cases where changing the method
can aid an
attack (note: aid an attack, not enable it):
- HTTP Response Splitting and Request Smuggling (in some cases, it may be
beneficial to use
a POST instead of a GET, and vice versa, I think this is mentioned in the
articles).
- CSRF (per Thomas Schreiber's message earlier in this thread).
This makes a stronger argument (in my opinion) to include this in automated
scanners.
