feat(920650): add detection for framework method overrides#4416
Conversation
Signed-off-by: Felipe Zipitria <felipe.zipitria@owasp.org>
|
📊 Quantitative test results for language: |
|
The only doubt I might have is if we do it the other way around. E.g. we disable the detection initially, and users need to enable. 🤔 |
|
@fzipi Wouldn't it make more sense to only use an allow-list here instead of just blacklisting dangerous methods? The second example you gave is currently not covered by the new rule you've added. |
|
The idea is just detecting, not blacklisting I guess. We can, if you want, remove those in our own allowed list. But the idea is using cross methods, right? |
|
@fzipi I'm just thinking ahead here when new methods are introduced or if we simply just missed one. It would be more robust against bypasses. |
|
Ok, we already use generic matching at PL1 in coreruleset/regex-assembly/920100.ra Line 23 in e4d3374 ^[a-z]{3,10}.
|
I agree with this in general, but then we should review methods every X time, right? Could be part of out "lists" update. |
You lost me here, why should we review the methods or update them if we're using a generic match? There is no list to update. |
|
Ok. If we do a "generic regex", we might get some false positives. A more controlled list might get us less FPs, but then we need to update. Let's go for the generic regex, and see where we get. Hopefully, those people using PHP can test and tell us if it is too aggressive. |
|
@fzipi We could have the generic match at PL-3 in that case, and an denylist approach at PL-2.
FYI I've also seen this on GitLab which uses Ruby and not PHP. Based on the tests I have for the GitLab plugin I'm working on so far, only the |
Signed-off-by: Felipe Zipitria <felipe.zipitria@owasp.org>
EsadCetiner
left a comment
There was a problem hiding this comment.
LGTM
Also, we're now no longer specifying individual test authors, just "OWASP CRS Team"?
Nah, it is a good catch: my template for tests creates that automatically. |
what
This PR adds a new rule (920650) to detect HTTP method override attempts via the
_methodparameter in query strings and request bodies.New components:
Rule 920650 (
REQUEST-920-PROTOCOL-ENFORCEMENT.conf, PL2): Detects_methodparameter containing dangerous HTTP methods (DELETE, PUT, PATCH, OPTIONS, TRACE, TRACK, CONNECT, HEAD, DEBUG)Rule 901510 (
REQUEST-901-INITIALIZATION.conf): Initializestx.allow_method_override_parameterto 0Configuration option 900210 (
crs-setup.conf.example): Allows users to permit_methodparameter usage for applications that legitimately require itTest suite (
tests/regression/tests/REQUEST-920-PROTOCOL-ENFORCEMENT/920650.yaml): 32 test cases covering positive and negative scenarioswhy
The
_methodparameter is a method override mechanism supported by many popular web frameworks including Laravel, Ruby on Rails, Symfony, CakePHP, Express.js, Phoenix, and others. While this is legitimate framework functionality designed to work around HTML form limitations (forms only support GET and POST), it can be abused for:WAF Bypass: An attacker sends a POST request with
_method=DELETE. The WAF sees a POST request and applies POST-related rules, but the application processes it as DELETE, potentially bypassing method-specific security controls.CSRF via SameSite=Lax Bypass: Browsers send cookies for top-level GET navigations under SameSite=Lax. An attacker can craft
GET /transfer?amount=1000&_method=POSTwhich the browser treats as GET (sending cookies) but the application processes as POST, enabling CSRF attacks.ACL Bypass: Applications with method-based access controls (e.g., "only admins can DELETE") can be circumvented when the actual HTTP method doesn't match what the application processes.
CRS already blocks method override via HTTP headers (
X-HTTP-Method-Override,X-HTTP-Method,X-Method-Override) in rule 920450. This PR complements that coverage by addressing the parameter-based vector, providing comprehensive protection against method override attacks.refs