Назад | Перейти на главную страницу

Работает ли ModSecurity 2.7.1 с ASP.NET MVC 3?

Я пытаюсь заставить ModSecurity 2.7.1 работать с веб-сайтом ASP.NET MVC 3. Установка прошла без ошибок, и если посмотреть журнал событий, ModSecurity запускается успешно. Я использую modsecurity.conf-recommended файл, чтобы установить основные правила.

Проблема, с которой я сталкиваюсь, заключается в том, что всякий раз, когда я отправляю данные формы POST, они не передаются в действие контроллера (или привязку модели).

у меня есть SecRuleEngine установлен в DetectionOnly.

у меня есть SecRequestBodyAccess установлен в On.

С этими настройками тело POST никогда не достигает действия контроллера. Если я установлю SecRequestBodyAccess к Off это работает, так что это определенно связано с тем, как ModSecurity пересылает данные тела. В ModSecurity debug показывает следующее (мне кажется, что все прошло):

Second phase starting (dcfg 94b750).
Input filter: Reading request body.
Adding request argument (BODY): name "[0].IsSelected", value "on"
Adding request argument (BODY): name "[0].Quantity", value "1"
Adding request argument (BODY): name "[0].VariantSku", value "047861"
Adding request argument (BODY): name "[1].Quantity", value "0"
Adding request argument (BODY): name "[1].VariantSku", value "047862"
Input filter: Completed receiving request body (length 115).
Starting phase REQUEST_BODY.
Recipe: Invoking rule 94c620; [file "*********************"] [line "54"] [id "200001"].
Rule 94c620: SecRule "REQBODY_ERROR" "!@eq 0" "phase:2,auditlog,id:200001,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:%{reqbody_error_msg},severity:2"
Transformation completed in 0 usec.
Executing operator "!eq" with param "0" against REQBODY_ERROR.
Operator completed in 0 usec.
Rule returned 0.
Recipe: Invoking rule 5549c38; [file "*********************"] [line "75"] [id "200002"].
Rule 5549c38: SecRule "MULTIPART_STRICT_ERROR" "!@eq 0" "phase:2,auditlog,id:200002,t:none,log,deny,status:44,msg:'Multipart request body failed strict validation: PE %{REQBODY_PROCESSOR_ERROR}, BQ %{MULTIPART_BOUNDARY_QUOTED}, BW %{MULTIPART_BOUNDARY_WHITESPACE}, DB %{MULTIPART_DATA_BEFORE}, 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}'"
Transformation completed in 0 usec.
Executing operator "!eq" with param "0" against MULTIPART_STRICT_ERROR.
Operator completed in 0 usec.
Rule returned 0.
Recipe: Invoking rule 554bd70; [file "********************"] [line "80"] [id "200003"].
Rule 554bd70: SecRule "MULTIPART_UNMATCHED_BOUNDARY" "!@eq 0" "phase:2,auditlog,id:200003,t:none,log,deny,status:44,msg:'Multipart parser detected a possible unmatched boundary.'"
Transformation completed in 0 usec.
Executing operator "!eq" with param "0" against MULTIPART_UNMATCHED_BOUNDARY.
Operator completed in 0 usec.
Rule returned 0.
Recipe: Invoking rule 554cbe0; [file "*********************************"] [line "94"] [id "200004"].
Rule 554cbe0: SecRule "TX:/^MSC_/" "!@streq 0" "phase:2,log,auditlog,id:200004,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
Rule returned 0.
Hook insert_filter: Adding input forwarding filter (r 5541fc0).
Hook insert_filter: Adding output filter (r 5541fc0).
Initialising logging.
Starting phase LOGGING.
Recording persistent data took 0 microseconds.
Audit log: Ignoring a non-relevant request.

Я не вижу ничего необычного в Fiddler. Я использую ViewModel в параметрах моего действия. Данные не привязаны, если SecRequestBodyAccess установлен на On. Я даже регистрирую все Request.Form.Keys и значения через log4net, но не получаю там никаких значений.

Я начинаю задаваться вопросом, если ModSecurity действительно работает с ASP.NET MVC или если есть конфликт с ModSecurity http модуль и привязка модели.

У кого-нибудь есть предложения или кто-нибудь может подтвердить, что ModSecurity работает с веб-сайтом ASP.NET MVC?

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

На самом деле это не проблема MVC. Это мощь быть проблемой IIS, хотя что-то похожее, похоже, влияет на NGINX (исходя из этого: https://github.com/SpiderLabs/ModSecurity/issues/664) И это по-прежнему кажется проблемой в версии ModSecurity, которая устанавливается с помощью программы установки веб-платформы, и в версии, которая автоматически доступна в Azure AppService, поэтому, если есть исправление, оно, вероятно, не широко развернуто.

На основе (https://github.com/SpiderLabs/ModSecurity/issues/562), Я устанавливал:

SecStreamInBodyInspection On

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

Интересно, что правила OWASP CRS для ModSecurity устанавливают SecRequestBodyInspection, но не SecStreamInBodyInspection, что говорит мне о том, что эта ошибка затрагивает не все хосты, но определенно является ловушкой для пользователей IIS.

HTH

Я отправил отчет об этой проблеме, и теперь она исправлена ​​в modsecurity 2.7.2. https://www.modsecurity.org/tracker/browse/MODSEC-371