Технологии аутентификации и шифрования

Кодирование запросов и ответов, использующих chunk

Протокол НТТР поддерживает метод передачи запроса, при котором размер содержимого заранее не известен. В этом случае тело запроса доставляется с использованием chunk’ов. Следовательно, должно существовать кодирование именованных chunk’ов. ModSecurity в настоящее время не поддерживает анализ запросов, состоящих из chunk’ов; когда запрос разбивается на chunk’и, тело запроса игнорируется. Насколько известно, браузеры не посылают разбитых на chunk’и запросов. Хотя Apache поддерживает данное представление для некоторых операций, большинство модулей (например, модуль РНР с Apache 1.3.x) его не поддерживает.

Использование запросов, состоящих из нескольких chunk’ов, представляет возможность для атакующего разместить враждебное содержимое. Следует добавить следующую строчку в конфигурационный файл для предотвращения использования данной уязвимости:

SecFilterSelective HTTP_Transfer-Encoding "!^$"

Это не влияет на возможность посылать ответы, использующие разбиение на куски.

Список действий по умолчанию

Всякий раз, когда запрос соответствует правилу, выполняется одно или более действий. Каждый фильтр может иметь свои собственные действия, но можно определить множество действий по умолчанию для всех фильтров. При желании всегда можно задать действие для каждого правила. Например, следующим образом конфигурируется занесение в лог каждого правила, для которого выполнено соответствие, и запрос отвергается с кодом статуса 404:

SecFilterDefaultAction "deny, log, status:404"

Директива SecFilterDefaultAction имеет только один параметр – разделенный запятыми список действий. Действия будут выполняться для каждого фильтра, для которого выполнено соответствие, за исключением правил, которые имеют свои собственные списки действий.

Замечание. Если указан нефатальный список действий по умолчанию (список, который не вызовет ситуацию, при которой запрос может быть отвергнут, например, log, pass ), то такой список действий будет игнорироваться на фазе инициализации. Фаза инициализации предназначена для того, чтобы получить информацию о запросе. Разрешение нефатальных действий будет приводить к тому, что некоторые части запроса могут быть пропущены. Поскольку данная информация требуется для внутренней обработки, такие действия не могут быть разрешены. Если ModSecurity должен выполняться в "detect-only" режиме, необходимо запретить все неявные проверки корректности (проверку корректности представления URL, проверку корректности представления Unicode, проверку корректности формата cookie и ограничение диапазона байтов).

Замечание. Некоторые действия не могут появиться в списке по умолчанию такие как: id, rev, skipnext, chain.

Неявная проверка корректности

Неявная проверка корректности запроса (если она сконфигурирована), выполняется только в начале обработки запроса. Эта проверка состоит из проверок строки запроса и заголовков.

Замечание. Проверка корректности Unicode не применяется к содержимому заголовка Referer как часть начальной неявной проверки корректности запроса. Это делается потому, что данный заголовок часто содержит информацию о других web-сайтах, и их кодирование обычно отличается от кодирования, используемого на защищаемом web-сайте.

Наследование фильтра

Фильтры, определенные в родительских каталогах, обычно наследуются во вложенных контекстах Apache. Такое поведение приемлемо (и требуется) в большинстве случаев, но не всегда. Иногда необходимо ослабить проверки для некоторой части сайта. Используя SecFilterInheritance директиву

SecFilterInheritance Off

можно указать ModSecurity не учитывать родительские фильтры, тем самым начать задавать правила заново. Данная директива влияет только на правила. Конфигурация всегда наследуется от родительского контекста, но ее можно перекрыть, используя соответствующие конфигурационные директивы.

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

При решении не наследовать правила из родительского контекста можно либо написать новые правила для нового контекста, либо просто использовать директиву Include для включения определенных правил в несколько различных контекстов. Иногда требуется только небольшое изменение в наборе правил в дочернем контексте. В таком случае можно использовать опцию выборочного наследования с помощью следующих директив:

• SecFilterImport – импорт единственного правила из родительского контекста. Данная директива применяется, когда в дочернем контексте надо начать заново задавать правила, а из родительского – импортировать только выбранные правила.
• SecFilterRemove – удалить правила из текущего контекста. Данная директива задействуется, когда требуется начать с некоторого множества правил в родительском контексте, выборочно удаляя из него правила.

В обеих директивах ( SecFilterImport и SecFilterRemove ) указываются в качестве параметра IDs списка правил. Требуемые правила должны иметь соответствующие IDs (это выполняется использованием действия id ). Директивы будут выполняться в том порядке, в котором появляются в конфигурационном файле. Следовательно, возможно удаление правила с помощью SecFilterRemove и затем добавление его снова с помощью SecFilterImport. Далее будут приведены два примера, в которых создается одна и та же конфигурация правил, но разными способами.

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

Пример 1. Правила из родительского контекста не наследуются, но одно правило импортируется.

SecFilter XXX id:1001
SecFilter YYY id:1002
SecFilter ZZZ id:1003
<Location /subcontext/>
SecFilterInheritance Off
SecFilterImport 1003
</Location>

Пример 2. Правила из родительского контекста наследуются, при этом два правила удаляются.

SecFilter XXX id:1001
SecFilter YYY id:1002
SecFilter ZZZ id:1003
<Location /subcontext/>
SecFilterRemove 1001 1002
</Location>

Замечание. Web-сервер Apache поддерживает много различных типов контекстов (например, <Directory>, <Location>, <Files> ). Последовательность, в которой контексты соединяются, важна. Не следует смешивать наследование и контексты разного типа. В любом случае следует тщательно протестировать конфигурацию, чтобы быть уверенным, что все работает так, как ожидается.