WebApp Sec mailing list archives
RE: (clarification) GET and POST Methods Accepted (testing guide version)
From: "Evans, Arian" <Arian.Evans () fishnetsecurity com>
Date: Fri, 14 Oct 2005 11:23:30 -0500
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 thediscussions so far, I haven't seen acase (in this thread at least) wherein chnaging POST to GET(say) is problematic, exceptfor the user himself/herself (we talked about data leakagethrough logging and Referer). Sothis leaves us with an XSS vector (only), and that is stilltechnically exploitable withPOST much as it is with GET (up to the point of the need ofan external site).In other words, if it all boils down to the fact that it'seasier to run a phishing (or URLspoofing) XSS attack, then I expect the vulnerabilityscanner to pick the XSS hole andpoint at the root cause. I'm not saying that accepting GET where POST is expected isa good practice. I woulddefinitely prefer not to have such "functionality" in anyapplication. But without a goodargument (i.e. this is a vulnerability, and this is how itcan be exploited), I'm not surevulnerability scanner vendors would be happy to include it(I'm not taking a stance herethough).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.
Current thread:
- RE: (clarification) GET and POST Methods Accepted (testing guide version) Evans, Arian (Oct 14)