RE: (clarification) GET and POST Methods Accepted

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

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.