Блог

Мы используем ModSecurity 3.X для NGIX с набором основных правил OWASP.

У нас проблема с изображением в base64 и правилом 941170 .

Схема этого правила такова

 SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|REQUEST_HEADERS:User-Agent|REQUEST_HEADERS:Referer|ARGS_NAMES|ARGS|XML:/* "@rx (?i)(?:W|^)(?:javascript:(?:[sS] [=\([.<]|[sS]*?(?:bnameb|\[ux]d))|data:(?:(?:[a-z]w /w[w -] w)?[;,]|[sS]*?;[sS]*?b(?:base64|charset=)|[sS]*?,[sS]*?<[sS]*?w[sS]*?>))|@W*?iW*?mW*?pW*?oW*?rW*?tW*?(?:/*[sS]*?)?(?:["']|W*?uW*?rW*?l[sS]*?()|W*?-W*?mW*?oW*?zW*?-W*?bW*?iW*?nW*?dW*?iW*?nW*?g[sS]*?:[sS]*?W*?uW*?rW*?l[sS]*?("
 

Лог:

 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:(?:[sS] [=\([.<]|[sS]*?(?:bnameb|\[ux]d))|data:(?:(?:[a-z]w /w[w -] w)?[;,]|[sS]*?;[sS]*?b(?:base64|charset=)|[sS]*?,[sS]*?<[sS]*?w[sS]*?>))|@ (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 ""]
 

Теперь мы используем SecRuleUpdateTargetById 941170 "!ARGS:screen" команду, но таким образом остальные проверки не применяются

Есть ли какой-либо способ изменить шаблон правила, чтобы оно не обнаруживало base64 как NoScript XSS InjectionChecker: Инъекция атрибутов?

Обновить

У меня есть еще одно ложное срабатывание со страницей под названием /organirama и кнопкой с классом btn-предупреждения. OWASP обнаруживает имя страницы и класс btn-предупреждения как утечку информации Oracle SQL.

 ---X96Job8w---A--
[26/Oct/2021:09:43:43  0200] 1635234223 2.152.144.73 57524 10.10.2.11 443
---X96Job8w---B--
GET /organigrama HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36
Sec-Fetch-Site: same-origin
sec-ch-ua-platform: "Windows"
Referer: domain.net/inicio
Upgrade-Insecure-Requests: 1
sec-ch-ua-mobile: ?0
Accept: text/html,application/xhtml xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Cache-Control: max-age=0
sec-ch-ua: "Google Chrome";v="95", "Chromium";v="95", ";Not A Brand";v="99"
Sec-Fetch-User: ?1
Connection: keep-alive
Sec-Fetch-Mode: navigate
Host: domain.net
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Cookie: SESSION_ID=06699c6dd9769a905e968ba2932edd75
Accept-Language: es-ES,es;q=0.9

---X96Job8w---D--

---X96Job8w---E--

ModSecurity: Warning. Matched "Operator `Rx' with parameter `(?i:ORA-[0-9][0-9][0-9][0-9]|java.sql.SQLException|Oracle error|Oracle.*Driver|Warning.*oci_.*|Warning.*ora_.*)' against variable `RESPONSE_BODY' (Value: `<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">x0a<html>x0a  <head>x0a    <!--x0 (304143 characters omitted)' ) [file "/etc/nginx/coreruleset/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf"] [line "69"] [id "951120"] [rev ""] [msg "Oracle SQL Information Leakage"] [data "Matched Data: warning" title="Fxc3xbatbol  -  Infantil  -  Infantil  40 Masculino">x0dx0a              <strong>Fxc3xbatbol  -  Infantil  -  Infantil  40 Masculino</strong>x0dx0a            </button>x0dx0a          </div> (420740 characters omitted)"] [severity "2"] [ver "OWASP_CRS/3.3.2"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-oracle"] [tag "attack-disclosure"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/118/116/54"] [hostname "192.168.1.1"] [uri "/organigrama"] [unique_id "1635235649"] [ref "o33323,193787v756,227110"]
ModSecurity: Access denied with code 403 (phase 4). Matched "Operator `Ge' with parameter `4' against variable `TX:OUTBOUND_ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/coreruleset/rules/RESPONSE-959-BLOCKING-EVALUATION.conf"] [line "68"] [id "959100"] [rev ""] [msg "Outbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "0"] [ver "OWASP_CRS/3.3.2"] [maturity "0"] [accuracy "0"] [tag "anomaly-evaluation"] [hostname "192.168.1.1"] [uri "/organigrama"] [unique_id "1635235649"] [ref ""]
 

Я стараюсь не применять это правило RESPONSE BODY , но продолжаю его ловить

 SecRule REQUEST_FILENAME "@beginsWith /organigrama" 
    "id:1030,
    phase:2,
    pass,
    nolog,
    ctl:ruleRemoveTargetById=959100;RESPONSE_BODY"
 

SecRuleUpdateTargetById Исключение из правил, которое вы предоставили, мне нравится.

Чтобы было ясно, последствия исключения из этого правила таковы:

• Правило 941170 больше не применяется к screen аргументу
• Правило 941170 по-прежнему применяется ко всем остальным аргументам, как обычно
• Все остальные правила по-прежнему применяются ко всем аргументам, в том числе screen , как обычно

Есть ли причина, по которой тебя это не устраивает?

Если вы используете сверхвысокую настройку безопасности, что означает, что SecRuleUpdateTargetById исключение правил слишком грубое, я бы сделал два предложения:

• Если это подходит для вашего веб-приложения, ограничьте исключение правила для правила 941170, чтобы оно применялось только к screen аргументу и только для данного местоположения (например, только для запросов /login.php ).
• Ограничьте исключение правила для правила 941170, чтобы оно применялось только к screen аргументу и только тогда, когда screen начинается со строки data:image/jpeg;base64

Вы даже можете объединить оба этих предложения, чтобы быть предельно конкретными.

Если один из них или оба применимы к вашей ситуации, дайте мне знать, если вы хотите помочь объединить эти исключения из правил.

Кроме того, на каком уровне паранойи вы сейчас находитесь, из интереса?

Что касается вашего предложения изменить регулярное выражение правила 941170, то было бы плохой идеей напрямую изменять правила сторонних разработчиков, такие как Основные правила набора правил. По сути, вы в конечном итоге создаете свою собственную ветвь набора правил, и на вас ложится ответственность за сохранение любых внесенных вами изменений. Обновление набора правил станет затруднительным: вам придется помнить о необходимости повторного применения и, возможно, изменения ваших изменений. Короче говоря: исключения из правил-это правильный путь!

Обновить

Исключение из второго правила, описанное выше, может выглядеть примерно так:

 #
# -- 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"
 

Исключение должно быть помещено перед директивой(директивами), которая включает Основной набор правил.

Обновление 2

Что касается вашего второго ложного срабатывания: вы используете Oracle SQL server? Правило 951120 специфично для Oracle SQL. Если вы не используете такой сервер, я бы рекомендовал отключить это правило, например:

 #
# -- CRS Rule Exclusion: 951120 - Oracle SQL Information Leakage
#
# Disable this Oracle SQL specific rule, as the rule causes false positives for
# the /organirama page and the Oracle SQL server/service is not in use.
#
SecRuleRemoveById 951120
 

Это исключение должно быть помещено после директивы(ов), которая включает Основной набор правил.