8000 Rule 920300 false positive in Chrome for hyperlink with download attribute (also pdf viewer) · Issue #2001 · coreruleset/coreruleset · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Rule 920300 false positive in Chrome for hyperlink with download attribute (also pdf viewer) #2001

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
tbroyer opened this issue Feb 4, 2021 · 2 comments · Fixed by #2013
Closed

Rule 920300 false positive in Chrome for hyperlink with download attribute (also pdf viewer) #2001

tbroyer opened this issue Feb 4, 2021 · 2 comments · Fixed by #2013
Assignees
@franbuehler
Labels
➕ False Positive PR available this issue is referenced by an active pull request

Comments

@tbroyer
Copy link
tbroyer commented Feb 4, 2021

Description

Chrome doesn't include an Accept header in requests triggered by <a href=… download> links: https://crbug.com/916983

In some cases, Chrome's PDF Viewer doesn't send it either: https://crbug.com/1010917

This would trigger the 920300 rule AFAICT:

coreruleset/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf

Lines 520 to 524 in ac2a0d1

#
# Do not accept requests without common headers.
# All normal web browsers include Host, User-Agent and Accept headers.
# Implies either an attacker or a legitimate automation client.
#

coreruleset/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf

Lines 1215 to 1248 in ac2a0d1

#
# Missing Accept Header
#
# -=[ Rule Logic ]=-
# This rule generates a notice if the Accept header is missing.
#
# Notice: The rule tries to avoid known false positives by ignoring
# OPTIONS requests coming from known offending User-Agents via two
# chained rules.
# As ModSecurity only reports the match of the last matching rule,
# the alert is misleading.
#
SecRule &REQUEST_HEADERS:Accept "@eq 0" \
"id:920300,\
phase:1,\
pass,\
t:none,\
msg:'Request Missing an Accept Header',\
tag:'application-multi',\
tag:'language-multi',\
tag:'platform-multi',\
tag:'attack-protocol',\
tag:'OWASP_CRS',\
tag:'capec/1000/210/272',\
tag:'PCI/6.5.10',\
tag:'paranoia-level/2',\
ver:'OWASP_CRS/3.3.0',\
severity:'NOTICE',\
chain"
SecRule REQUEST_METHOD "!@rx ^OPTIONS$" \
"chain"
SecRule REQUEST_HEADERS:User-Agent "!@pm AppleWebKit Android" \
"t:none,\
setvar:'tx.anomaly_score_pl2=+%{tx.notice_anomaly_score}'"

https://github.com/coreruleset/coreruleset/blob/ac2a0d15c5f2e3b4a142e0be18bc6974a5908837/tests/regression/tests/REQUEST-920-PROTOCOL-ENFORCEMENT/920300.yaml

Audit Logs / Triggered Rule Numbers

Your Environment

I do not use ModSecurity myself, but one of our customers had 403 Forbidden for all downloads in Chrome (but not Firefox for instance) from our app when deployed in their production environment (everything's OK in their preprod, and in our own demo server), and I suspect ModSecurity here (haven't heard back from our customer yet whether they use it or not, and whether that's the culprit here).

Confirmation

[x] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.
@dune73
Copy link
Member
dune73 commented Feb 5, 2021

Sorry for the inconvenience and thank you for doing the writeup. 920300 is a misbehaving kid in our class.

920300 carries exceptions for AppleWebKit and Android already. So we might need to whitelist Chrome as well and I wonder if it's not time to abandon the rule alltogether. Or move it to paranoia level 3.

For the record, RFC 7231 does not enforce the use of the Accept header. It's just happens to be a typical behavior of browsers to send it. See https://tools.ietf.org/html/rfc7231#section-5.3.2.

Out of curiosity: You are not running CRS yourself, but you support customers running CRS, even CRS in paranoia level 2 (this is a paranoia level 2 rule). I would expect too many false positives at PL 2 for somebody not being a professional CRS users. Great to hear it works out for you.

@dune73 dune73 mentioned this issue Feb 15, 2021
Closed
@franbuehler
Copy link
Contributor

Issue chat meeting Feb 15: We decide to change the PL to 3 or 4. @franbuehler will propose a PR.

@franbuehler franbuehler self-assigned this Feb 15, 2021
@franbuehler franbuehler mentioned this issue Feb 18, 2021
Merged
@franbuehler franbuehler added the PR available this issue is referenced by an active pull request label Feb 18, 2021
@franbuehler franbuehler linked a pull request Feb 18, 2021 that will close this issue
Move rule 920300 from PL2 to PL3 #2013
Merged
@M4tteoP M4tteoP mentioned this issue Jan 2, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@franbuehler franbuehler

Labels
➕ False Positive PR available this issue is referenced by an active pull request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Move rule 920300 from PL2 to PL3 franbuehler/coreruleset
3 participants
@tbroyer @dune73 @franbuehler
0