fix(933100): reduce false positive on Extensible Metadata Platform and xsl-stylesheets#4445
Conversation
|
📊 Quantitative test results for language: |
|
Honestly, at this point I'm trying to understand what the hell is XML doing here. |
|
I think I now got it. The idea was to eliminate FPs with
|
There was a problem hiding this comment.
Pull request overview
This PR updates CRS rule 933100 (PHP open tag detection) to reduce false positives triggered by XMP metadata processing instructions such as <?xpacket ...?>, and expands the regression test suite accordingly.
Changes:
- Adjusts rule 933100 regex to narrow matching and avoid
<?xpacket/similar non-PHP processing instructions. - Updates the regex-assembly source for 933100 to reflect the new matching logic.
- Adds extensive positive/negative regression tests for PHP open tags, XML lookalikes, and XMP
<?xpacketcases.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| tests/regression/tests/REQUEST-933-APPLICATION-ATTACK-PHP/933100.yaml | Adds many new regression tests, including XMP <?xpacket negative cases and additional PHP/XML variants. |
| rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf | Modifies rule 933100 detection regex to reduce false positives on XMP-like processing instructions. |
| regex-assembly/933100.ra | Updates the regex-assembly definition for rule 933100 to align with the new intended matching behavior. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
for more information, see https://pre-commit.ci
Signed-off-by: Felipe Zipitria <felipe.zipitria@owasp.org>
Signed-off-by: Felipe Zipitria <felipe.zipitria@owasp.org>
Signed-off-by: Felipe Zipitria <felipe.zipitria@owasp.org>
Signed-off-by: Felipe Zipitria <felipe.zipitria@owasp.org>
<?php without trailing whitespace should no longer match.
|
@azurit Can I get your eyes on this one also? |
|
@fzipi Sure, give me some time. |
|
ping @azurit so this one makes the next release |
Proposed changes
Hello,
Following this issue: #4443 , I see no reason why we should not treat this as a false positive, and I do not see any abuse or bypass use case at this time on the scope of this rule.
At this point, I don’t think it would be relevant to create a custom rule to block this, but perhaps one of you may have a different opinion on the matter.
PR Checklist
commentfield to write the expected behaviorFurther comments
For the reviewer
ctl:requestBodyAccess=Offwere used in the rule