Обновление правила Apache Mod Security Core Rule OWASP 950120, чтобы разрешить URL-адреса в одном конкретном входе.

В моей форме есть поле ввода, где пользователи могут вводить URL-адреса. Я знаю, как обновить целевое правило, чтобы предотвратить ложные срабатывания:

SecRuleRemoveById 950120 !ARGS:urlField

Но это не относится к правилу 950120: Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link. Ошибка не указывает, какой аргумент нарушает правило. Он просто дает сообщение:

Message: Access denied with code 403 (phase 2). 
Match of "beginsWith %{request_headers.host}" against "TX:1" required. 
[file "/etc/httpd/crs-tecmint/owasp-modsecurity-crs/base_rules/modsecurity_crs_40_generic_attacks.conf"] 
[line "163"] [id "950120"] [rev "3"] 
[msg "Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link"] 
[data "Matched Data: http://asite.com.hk/live found within TX:1: asite.com.hk/live"] 
[severity "CRITICAL"] [ver "OWASP_CRS/2.2.9"] 
[maturity "9"] [accuracy "9"] 
[tag "OWASP_CRS/WEB_ATTACK/RFI"]
Action: Intercepted (phase 2)

Без аргумента нарушения в сообщении означает ли это, что SecRuleRemoveById не будет работать с этим правилом? Как я могу обновить его, не удаляя полностью это правило?


apache mod-rewrite owasp mod-security
person RedGiant    schedule 28.09.2015    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Правило можно увидеть здесь: https://raw.githubusercontent.com/SpiderLabs/owasp-modsecurity-crs/master/base_rules/modsecurity_crs_40_generic_attacks.conf, и я также скопировал его ниже:

SecRule ARGS "^(?:ht|f)tps?://(.*)$" \
    "chain,phase:2,rev:'3',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,capture,ctl:auditLogParts=+E,block,msg:'Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',id:'950120',severity:'2',tag:'OWASP_CRS/WEB_ATTACK/RFI'"
   SecRule TX:1 "!@beginsWith %{request_headers.host}" "setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/RFI-%{matched_var_name}=%{tx.1}"

Итак, это цепное правило, состоящее из двух частей. Первое правило проверяет, начинается ли аргумент с http:// или https://, или с ftp://, или с ftps://. Поскольку в шаблоне регулярного выражения используются скобки, он также устанавливает переменные TX. TX:0 устанавливается либо на ht, либо на ft, а TX:1 устанавливается на адрес после протокола.

Следующее правило в цепочке проверяет, не начинается ли TX:1 с хоста, указанного в заголовке запроса (который должен быть хостом этого сервера). Если это так, это внешний URL-адрес, и он блокируется.

Итак, ваше исправление:

SecRuleRemoveById 950120 !ARGS:urlField

не будет работать как 1) если вы думаете, что собираетесь обновить правило, а не удалить его, поэтому у вас неправильная команда, и 2) urlField предположительно является ARG_NAME, а не значением ARG. Итак, попробуйте следующее:

SecRuleUpdateTargetByID 950120 !ARG_NAMES:urlField

или, в качестве альтернативы, вы можете выборочно удалить это правило с другим правилом, например, чтобы отключить правило только для вашего URL-адреса /post/location, используйте следующее:

SecRule REQUEST_URI /post/location/ "id:1000,phase:2,log,ctrl:ruleRemoveByID=950120"

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

SecRuleRemoveById 950120
person Barry Pollard    schedule 30.09.2015

arrow_upward
2
arrow_downward

В вашем ответе есть небольшая ошибка, Барри. Линия:

SecRule REQUEST_URI /post/location/ "id:1000,phase:2,log,ctrl:ruleRemoveByID=950120"

выдает следующее: Ошибка синтаксического анализа действий: Неизвестное действие: ctrl

Правильная строка

SecRule REQUEST_URI /post/location/ "id:1000,phase:2,log,ctl:ruleRemoveByID=950120"

В остальном: отлично, спасибо! Мне очень помог. Я бы прокомментировал, но недостаточно репутации. Я бы написал вам, но вы, похоже, не принимаете сообщения.

person Mark Dazo    schedule 17.05.2018