Не совсем верно, так как в этом правиле есть несколько неправильных моментов. Но думаю, вы поняли общую концепцию.
Чтобы объяснить, что не так с правилом в его нынешнем виде, требуется немало объяснений:
Во-первых, синтаксис ModSecurity для определения правил состоит из нескольких частей:
- SecRule
- поле или поля для проверки
- значения для проверки этих полей
- действия, которые нужно предпринять
У вас есть два набора деталей 2 и 3, которые недействительны. Если вы хотите проверить 2 вещи, вам нужно связать два правила вместе, пример которых я покажу позже.
Затем вы проверяете заголовки запроса на наличие тега сценария. Это не то место, где существует большинство XSS-атак, и вместо этого вам следует проверять аргументы — хотя см. Ниже дальнейшее обсуждение XSS.
Также проверка на <script> не очень тщательная. Например, его легко победить <script type="text/javascript">. Или <SCRIPT> (необходимо добавить t:lowercase, чтобы игнорировать регистр). Или путем экранирования символов, которые могут обрабатываться вашими частями вашего приложения.
Двигаясь дальше, нет необходимости указывать оператор @rx, так как это подразумевается, если не указан другой оператор. Хотя нет ничего плохого в том, чтобы быть явным, немного странно, что вы не дали его для blah, но сделали для <script> бита.
Также рекомендуется указать фазу, а не использовать значение по умолчанию (обычно фаза 2). В этом случае вам нужна фаза 2, когда все заголовки запроса и части тела запроса доступны для обработки, поэтому значение по умолчанию, вероятно, правильное, но лучше указать его явно.
И, наконец, 404 — это код ответа «страница не найдена». 500 или 503 могут быть здесь лучшим ответом.
Поэтому ваше правило было бы лучше переписать как:
SecRule REQUEST_URI "/blah.html" id:101,phase:2,msg: ‘XSS Attack’,severity:ERROR,deny,status:500,chain
SecRule ARGS "<script" "t:lowercase"
Хотя это по-прежнему не охватывает все способы, которыми можно обойти базовую проверку, которую вы выполняете для тега скрипта, как упоминалось выше. Основной набор правил OWASP — это бесплатный набор правил ModSecurity, созданный со временем и содержит некоторые правила XSS, которые вы можете проверить. Хотя имейте в виду, что некоторые из их регулярных выражений довольно сложны для понимания!
ModSecurity также работает лучше как более общая проверка, поэтому необычно хотеть защитить только одну страницу таким образом (хотя и не совсем неслыханно). Если вы знаете, что какая-то страница уязвима для конкретной атаки, часто лучше закодировать эту страницу или то, как она обрабатывается, чтобы устранить уязвимость, а не использовать ModSecurity для ее обработки. Исправить проблему в источнике, а не исправлять ее, всегда хорошая мантра, которой нужно следовать, где это возможно. Вы бы сделали это, очистив и экранировав входной HTML-код, например, из входов.
Говоря, что часто хорошим краткосрочным решением является использование правила ModSecurity для быстрого исправления, пока вы работаете над более правильным долгосрочным исправлением - это называется «виртуальное исправление». Хотя иногда они имеют тенденцию становиться долгосрочными решениями, поскольку ни у кого нет времени решить основную проблему.
Однако, если вам нужна более общая проверка «скрипта» в любых аргументах для любой страницы, то для этого чаще используется ModSecurity. Это помогает добавить дополнительную защиту тому, что уже должно быть в правильно закодированном приложении, в качестве резервной копии и дополнительной линии защиты. Например, если кто-то забудет защитить одну страницу из многих, очистив пользовательский ввод.
Поэтому, возможно, было бы лучше отказаться от первой части этого правила и просто использовать следующее для проверки всех страниц:
SecRule ARGS "<script" id:101,phase:2,msg: ‘XSS Attack’,severity:ERROR,deny,status:500,"t:lowercase"
Наконец, XSS — довольно сложная тема. Здесь я предположил, что вы хотите проверить параметры, отправленные при запросе страницы. Так что, если он использует пользовательский ввод для построения страницы и отображает ввод, то вы хотите защитить это, известное как «рефлексивный XSS». Однако есть и другие XSS-уязвимости. Например:
Если неверные данные хранятся в базе данных и используются для построения страницы. Известен как «хранимый XSS». Чтобы решить эту проблему, вы можете проверить результаты, возвращенные со страницы в параметре RESPONSE_BODY на этапе 4, а не входные данные, отправленные на страницу в параметре ARGS на этапе 2. Хотя обработка страниц ответов обычно медленнее и требует больше ресурсов по сравнению с к запросам, которые обычно намного меньше.
Возможно, вы сможете выполнить XSS, не проходя через ваш сервер, например. При загрузке внешнего контента, такого как сторонняя система комментариев. Или страница обслуживается через http и манипулируется между сервером и подключением. Это известно как «XSS на основе DOM», и поскольку ModSecurity находится на вашем сервере, он не может защитить от этих типов атак XSS.
Там было довольно много подробностей, но надеюсь, что это поможет объяснить немного больше. Я нашел Руководство по ModSecurity лучшим ресурсом для изучения ModSecurity, несмотря на его возраст.
14.01.2016
