mod_security: правило, разрешающее POST-запросы без тела запроса.

У меня установлены Apache 2.4 и mod_security 2.9.1, и они работают с некоторыми очень простыми правилами.

Я пытаюсь сделать запрос POST, который включает некоторую информацию заголовка, но ничего не имеет в теле запроса (запрос относится к конечной точке API, которая защищена mod_security, и эта конечная точка требует POST без тела запроса) . POST, который не требует тела, действителен в соответствии со следующим: Требуется ли/ожидается ли, что запросы PUT и POST будут иметь тело запроса?

mod_security блокирует запрос, потому что кажется, что он не может разобрать/отформатировать тело (вероятно, потому что оно не существует).

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

Конкретное правило, которое срабатывает:

SecRule REQBODY_ERROR "!@eq 0" \
"id:'200002', phase:2,t:none,log,deny,status:415,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"

Ошибка:

[Fri Jul 08 10:32:32.901230 2016] [:error] [pid 7697] [client 10.0.2.2:57442] [client 10.0.2.2] ModSecurity: JSON parser error: parse error: premature EOF\n [hostname "example.com"] [uri "/api/v1/logout"] [unique_id "V377qH8AAQEAAB4RU6cAAAAD"]

[Fri Jul 08 10:32:32.901555 2016] [:error] [pid 7697] [client 10.0.2.2:57442] [client 10.0.2.2] ModSecurity: Access denied with code 415 (phase 2). Match of "eq 0" against "REQBODY_ERROR" required. [file "/etc/modsecurity/modsecurity.conf"] [line "61"] [id "200002"] [msg "Failed to parse request body."] [data "JSON parser error: parse error: premature EOF\\x0a"] [severity "CRITICAL"] [hostname "example.com"] [uri "/api/v1/logout"] [unique_id "V377qH8AAQEAAB4RU6cAAAAD"]

Или я должен просто не отправлять HTTP-заголовок Content-Type, чтобы заставить mod_security анализировать тело (хотя я бы предпочел, чтобы все запросы POST всегда имели определенный Content-Type)?

Я изложил суть используемого файла modsecurity.conf (который является базовый пример с двумя дополнительными правилами для фильтрации Content-Type).


person pnairn    schedule 08.07.2016    source источник
comment
Если у вас нет контента, у вас нет типа контента.   -  person Tony Chiboucas    schedule 08.07.2016
comment
Привет, но в целях безопасности не рекомендуется ли гарантировать, что запросы POST всегда имеют Content-Type? Или у вас есть только тип контента, если у вас есть сценарий тела?   -  person pnairn    schedule 08.07.2016
comment
mod_security выполняет проверку содержимого. Действительный HTTP требует тела сообщения, если только это не ответ HT 100, 204 или 304. w3.org/Protocols/rfc2616/rfc2616-sec4.html   -  person Tony Chiboucas    schedule 08.07.2016
comment
когда вы устанавливаете тип содержимого, например text/html, mod_security будет следить за тем, чтобы содержимое было действительным, что для html самым коротким действительным содержимым является <!doctype html><head></head><body></body>, хотя технически он не пройдет большинство валидаторов, в то время как это будет <!doctype html><meta charset=utf-8><title>shortest html5</title>   -  person Tony Chiboucas    schedule 08.07.2016


Ответы (1)


Вы можете отключить доступ к телу для запроса с нулевой длиной тела:

SecRule REQUEST_BODY_LENGTH "@eq 0" "id:12345,phase:1,nolog,ctl:requestBodyAccess=off"

Или, если вы хотите сделать это только для определенного URL-адреса, используйте такое связанное правило:

SecRule REQUEST_URI /my/weird/api "phase:1,id:12346,nolog,chain"
   SecRule REQUEST_BODY_LENGTH "@eq 0" "ctl:requestBodyAccess=off"
person Barry Pollard    schedule 08.07.2016
comment
Это очень хакерское решение, которое на самом деле не решает проблему. - person Tony Chiboucas; 20.07.2016
comment
Отправка POST-запросов без тела — очень сложная задача! - person Barry Pollard; 20.07.2016
comment
Обновленный ответ, чтобы иметь лучшие решения. Доволен этим? - person Barry Pollard; 21.07.2016
comment
Это не совсем правильно. Особенно в отношении API. Вместо того, чтобы отключать обнаружение контента, в запросе не следует указывать тип контента. Лучше было бы отправить текстовый тип содержимого, а содержимое содержало бы только закодированную контрольную сумму. - person Tony Chiboucas; 21.07.2016
comment
Однако, учитывая, что вы изменили свое решение, чтобы оно соответствовало URL-адресу, этого было бы достаточно. - person Tony Chiboucas; 21.07.2016
comment
Новый синтаксис SecRule REQUEST_BODY_LENGTH "@eq 0" "id:12345,phase:1,nolog,ctl:requestBodyAccess=Off" - person vikas027; 22.06.2017