Modsecurity OWASP Core Rule Set - base64 false positive rule 941170

Question

We use ModSecurity 3.X for NGIX with the OWASP core rule set.

We have a problem with image in base64 and the rule 941170 .

The pattern of the rule is

SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|REQUEST_HEADERS:User-Agent|REQUEST_HEADERS:Referer|ARGS_NAMES|ARGS|XML:/* "@rx (?i)(?:\W|^)(?:javascript:(?:[\s\S]+[=\\\(\[\.<]|[\s\S]*?(?:\bname\b|\\[ux]\d))|data:(?:(?:[a-z]\w+\/\w[\w+-]+\w)?[;,]|[\s\S]*?;[\s\S]*?\b(?:base64|charset=)|[\s\S]*?,[\s\S]*?<[\s\S]*?\w[\s\S]*?>))|@\W*?i\W*?m\W*?p\W*?o\W*?r\W*?t\W*?(?:\/\*[\s\S]*?)?(?:[\"']|\W*?u\W*?r\W*?l[\s\S]*?\()|\W*?-\W*?m\W*?o\W*?z\W*?-\W*?b\W*?i\W*?n\W*?d\W*?i\W*?n\W*?g[\s\S]*?:[\s\S]*?\W*?u\W*?r\W*?l[\s\S]*?\("

Log:

HTTP/1.1 200
Access-Control-Max-Age: 600
Access-Control-Allow-Headers: x-requested-with, Content-Type, origin, authorization, accept, client-security-token
Set-Cookie: SESSION_ID=b57248f3aa2ac2c169e664b1862e49ed_; path=/
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE, PUT
Date: Wed, 06 Oct 2021 16:06:52 GMT
Cache-Control: no-cache, no-store
Connection: keep-alive
Content-Type: text/xml; charset=utf-8; boundary=xYzZY
Access-Control-Expose-Headers: Content-Security-Policy, Location
Content-Length: 67
Server: nginx
Pragma: no-cache
Access-Control-Allow-Origin: *

---RleKJMgH---H--
ModSecurity: Warning. Matched "Operator `Rx' with parameter `(?i)(?:\W|^)(?:javascript:(?:[\s\S]+[=\\\(\[\.<]|[\s\S]*?(?:\bname\b|\\[ux]\d))|data:(?:(?:[a-z]\w+\/\w[\w+-]+\w)?[;,]|[\s\S]*?;[\s\S]*?\b(?:base64|charset=)|[\s\S]*?,[\s\S]*?<[\s\S]*?\w[\s\S]*?>))|@\ (188 characters omitted)' against variable `ARGS:screen' (Value: `data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/4gIoSUNDX1BST0ZJTEUAAQEAAAIYAAAAAAIQAABtbnRyUkdCI (47619 characters omitted)' ) [file "/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "236"] [id "941170"] [rev ""] [msg "NoScript XSS InjectionChecker: Attribute Injection"] [data "Matched Data: data:image/jpeg; found within ARGS:screen: data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/4gIoSUNDX1BST0ZJTEUAAQEAAAIYAAAAAAIQAABtbnRyUkdCIFhZWiAAAAAAAAAAAAAAAABhY3NwAAAAAAAAAAAAAAAA (47576 characters omitted)"] [severity "2"] [ver "OWASP_CRS/3.2.0"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-xss"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A3"] [tag "OWASP_AppSensor/IE1"] [tag "CAPEC-242"] [hostname "192.168.1.1"] [uri "/wsrfef.subirArchivo"] [unique_id "1633536412"] [ref "o0,16v1288,47719t:utf8toUnicode,t:urlDecodeUni,t:htmlEntityDecode,t:jsDecode,t:cssDecode,t:removeNulls"]
ModSecurity: Warning. Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "80"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.2.0"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "192.168.1.1"] [uri "/wsrfef.subirArchivo"] [unique_id "1633536412"] [ref ""]

Now we are using the SecRuleUpdateTargetById 941170 "!ARGS:screen" command but this way the rest of the checks are not applied

Is there any way to modify the pattern of the rule so that it does not detect base64 as NoScript XSS InjectionChecker: Attribute Injection?

Answer 1

The SecRuleUpdateTargetById rule exclusion you provided looks good to me.

To be clear, the effect of that rule exclusion is:

• Rule 941170 no longer applies to the screen argument
• Rule 941170 still applies to all other arguments as usual
• All other rules still apply to all arguments, including screen , as usual

Is there a reason you're not happy with this?

If you're running a super-high security setup which means that the SecRuleUpdateTargetById rule exclusion is too coarse, two suggestions I would make:

• If appropriate for your web application, limit the rule exclusion for rule 941170 to only apply to the screen argument and only for a given location (for example, only for requests to /login.php )

• Limit the rule exclusion for rule 941170 to only apply to the screen argument and only when screen begins with the string data:image/jpeg;base64

You could even combine both of those suggestions to be extremely specific.

If either, or both, of those sound applicable to your situation, let me know if you would like help to put those rule exclusions together.

Also, what paranoia level are you currently running in, out of interest?

---

Regarding your suggestion to modify rule 941170's regular expression, it's a bad idea to directly modify third-party rules, such as the Core Rule Set rules. You essentially end up creating your own fork of the rule set, and you're left with the responsibility for maintaining any modifications you make. Upgrading the rule set would become difficult: you would have to remember to keep re-applying, and possibly change, your modifications. In short: rule exclusions are the way to go!

---

Update

The second rule exclusion described above may look something like this:

#
# -- CRS Rule Exclusion: 941170 - NoScript XSS InjectionChecker: Attribute
#                                 Injection
#
# Disable this rule for the "screen" argument when it begins with the string
# "data:image/jpeg;base64,". This resolves a false positive caused by base64
# encoded images.
#
SecRule ARGS:screen "@beginsWith data:image/jpeg;base64," \
    "id:1000,\
    phase:2,\
    pass,\
    nolog,\
    ctl:ruleRemoveTargetById=941170;ARGS:screen"

The exclusion would need to be placed before the directive(s) that includes the Core Rule Set.