RE: (clarification) GET and POST Methods Accepted (testing guide version)

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

Amit,

Thanks for the response and clarification. I was lumping the
social engineering into the XSS attack method but accept that
defining a separate phishing or luring condition is valid and
legitimate, and means we agree. :)

Some scanners, I think I saw this in testing Web Inspect recently
but it could have been AS (the shame, I didn't document) were
making checks by tampering the referer (sic) field in the HTTP
header which is a potentially effective way of evaluating broken
access controls (that rely on things like header field elements
for authorization).

This to me is similar; scanner doesn't know if you should or
shouldn't get to /secretpage.asp from ed.com or arian.com but
it can dump that data out and suggest eyeball analysis.

I would like that data dumped to review.

But heck the vast majority of scanners still cannot and do not
automatically evaluate an (example) four-digit numeric session
cookie that increments by one and tell you if it is a potential
issue, if it is set post-login behind a form-based authentication.

A few have manual tools to test this but by default give an
app thumbs up that a five year old could compromise.

So while I'm openly requesting scan vendors add this feature
I'm also not suggesting prioritizing it above session token
testing. :o

Now back to the subject, I see pretty clearly how and why this
happens in ASP or ASP.NET and apparently in Java servlets, so
where is Andrew VDS?

Maybe we should add some additional method validation verbiage
to the OWASP Guide regarding this, and the implications, as
all the commentary seems to support was we've been thinking
internally, but Ed had to go and stir up a public discussion.

As an aside, this seems to me (method verbs) a framework issue
and one should be able to define data types and have the
framework make default assumptions about how they are handled.

Image = GET
numeric string of particular length/position != GET (account, session token, whatever)

Where are the Spring and Struts folks? Not my area for sure,

-ae




> -----Original Message-----
> From: Amit Klein (AKsecurity) [mailto:aksecurity () hotpop com] 
> Sent: Friday, October 14, 2005 8:33 AM
> To: webappsec () securityfocus com
> Subject: RE: (clarification) GET and POST Methods Accepted
>
>
> 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.