coreruleset / coreruleset

OWASP CRS (Official Repository)
https://coreruleset.org
Apache License 2.0
2.05k stars 351 forks source link

xss attack not blocked on juice shop #3726

Open louis07r opened 4 weeks ago

louis07r commented 4 weeks ago

Hello everyone, I'm working on a final year project for my school. The project is a simple nginx reverse proxy with modsecurity and behind it a juice shop. The problem is that modsecurity blocks sql injections but not xss attacks (example the one in the juice shop search bar with <iframe src="javascript:alert(`xss`)">). I have coreruleset-3.3.5 rules.

here's my modsecurity configuration:

# Default recommended configuration
SecRuleEngine On
SecRequestBodyAccess On
SecRuleInheritance On
# SecFilterScanPOST On
SecResponseBodyMimeType text/plain text/html text/xml application/json SecResponseBodyLimit 524288

SecResponseBodyLimitAction ProcessPartial
SecRule REQUEST_HEADERS:Content-Type "text/xml" \
     "id:200000,phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
SecRequestBodyInMemoryLimit 131072
SecRequestBodyLimitAction Reject
SecRule REQBODY_ERROR "!@eq 0" \
"id:200001,phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"id:200002,phase:2,t:none,log,deny,status:400,msg:'Multipart request body \
failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_MISSING_SEMICOLON}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IP %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"

# Définir des règles pour détecter les tentatives XSS
SecRule ARGS "<.*src=[\"']?javascript:.*[\"']?" \
    "id:1000001,phase:2,deny,log,status:403,msg:'XSS attack detected'"
SecRule ARGS "<(iframe|script|img|div|object|embed|style).*>" \
    "id:1000002,phase:2,deny,log,status:403,msg:'XSS attack detected'"
SecRule ARGS "['\"<>]" \
    "id:1000003,phase:2,deny,log,status:403,msg:'Potential XSS attack detected'"

# Activez l'encodage des données d'entrée pour éviter les injections XSS
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
    "id:200003,phase:2,t:none,log,deny,status:44,msg:'Multipart parser detected a possible unmatched boundary.'"

SecPcreMatchLimit 1000
SecPcreMatchLimitRecursion 1000

SecRule REQUEST_METHOD "POST" \

"id:1058701, \
phase:2, \
deny, \
log, \
msg:'Potential XSS Attack Detected in POST Request', \
chain"

SecRule REQUEST_BODY "https://github.com/contains <script>"
"t:none,
setvar:tx.xss_attack=1,
ctl:ruleRemoveById=1001"

SecRule TX:/^MSC_/ "!@streq 0" \
    "id:200004,phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"

SecRule REQUEST_HEADERS:Content-Type "application/json" \
    "id:15487,phase:2,nolog,pass,ctl:requestBodyProcessor=JSON"

SecRule REQUEST_BODY "@contains \"' or 1=1; --\"" \
    "id:105963,phase:2,deny,log,status:403,msg:'Tentative d\'injection SQL détectée dans le formulaire de login'"    

SecResponseBodyAccess Off
SecDebugLog /var/log/httpd/modsec_debug.log
SecDebugLogLevel 3
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Serial
SecAuditLog /var/log/httpd/modsec_audit.log
SecArgumentSeparator &
SecCookieFormat 0
SecTmpDir /var/lib/mod_security
SecDataDir /var/lib/mod_security
SecPcreMatchLimit 150000

Include /etc/httpd/conf/crs/crs-setup.conf
Include /etc/httpd/conf/crs/rules/*.conf
</IfModule>
azurit commented 4 weeks ago

HI @louis07r Thank for reporting. Can you try it with newest CRS version? This was probably fixed in version 4.

louis07r commented 4 weeks ago

thank you @azurit for your help but I've tried version 4 and it's no better

azurit commented 4 weeks ago

Which version? In the issue above, you were talking about version 3.3.5: I have coreruleset-3.3.5 rules.

azurit commented 4 weeks ago

Your payload is definitely catched by multiple rules:

$ curl -H "x-crs-paranoia-level: 1" -H "x-format-output: txt-matched-rules" "https://sandbox.coreruleset.org/?bla=<iframe%20src=\"javascript:alert(\`xss\`)\">"
941100 PL1 XSS Attack Detected via libinjection
941160 PL1 NoScript XSS InjectionChecker: HTML Injection
941170 PL1 NoScript XSS InjectionChecker: Attribute Injection
941210 PL1 IE XSS Filters - Attack Detected
941390 PL1 Javascript method detected
949110 PL1 Inbound Anomaly Score Exceeded (Total Score: 25)
980170 PL1 Anomaly Scores: (Inbound Scores: blocking=25, detection=25, per_pl=25-0-0-0, threshold=5) - (Outbound Scores: blocking=0, detection=0, per_pl=0-0-0-0, threshold=4) - (SQLI=0, XSS=25, RFI=0, LFI=0, RCE=0, PHPI=0, HTTP=0, SESS=0, COMBINED_SCORE=25)
louis07r commented 4 weeks ago

@azurit Yes, it matches the modsecurity configuration, I think.

azurit commented 4 weeks ago

@louis07r It was matched by CRS rules, as you can see in my comment above.

franbuehler commented 4 weeks ago

Yes, I remember when I tested the OWASP CRS with the OWASP Juiceshop, not all attacks were detected. I think this could be because some of the attacks are only executed on the client-side and not sent/transmitted to a server. Of course, the CRS cannot detect anything there. For the CRS developers with access to our share: have a look at the "Juiceshop_Vulns_CRS" file to see what attack was detected and what was not. I tested them all for our BB program.