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.
