Когда мы видим web-ресурс в адресной строке, которого красуется "id=", как-то рефлекторно хочется добавить одинарную кавычку в подобный запрос. Возможно для того, чтобы не искушать своих посетителей, web-разработчики активно используют ModRewrite . Но не всегда его использование оказывается полезным.
Эпизодически приходится сталкиваться с уязвимостями различной степени критичности, в web-приложениях использующие mod_rewrite. Это связано с тем, что безопасность приложения в подобных случаях пытаются обеспечить модулем Apache, но при этом задают неточные регулярные выражения. Так, использование директивы RewriteRule с "кривым" regexp:
name='more'>
... RewriteRule (.+)/(.+)/(.+)/$ / index.php?action=view&module=$1&category=$2&id=$3
...
Позволяет эксплуатировать уязвимость " Внедрение операторов SQL ", например, следующим образом:
http://victim/mod/cat/1+union+select+1,2,3--/
Не случайно, приведенный мною пример RewriteRule, содержит параметр "action". Дело в том, что ознакомившись сегодня с проведенным ресерчем Luca Carettoni и Stefano diPaola , я увидел уязвимость HTTP Parameter Pollution , вызванную теми же факторами, что и при использовании mod_rewrite (использование неточных регулярных выражений). Например, такой запрос:
http://victim/mod/cat/1&action=edit/
Уже позволяет перезаписать значение параметра "action". Стоит отметить, что приведенный пример с HTTP Parameter Pollution в контексте ModRewrite это частный случай для данного класса уязвимостей. Границы применения HPP гораздо шире. Например, исследователи приводят пример по обходу ModSecurity :
/index.aspx?page=select 1&page=2,3 from table where id=1
Сразу же возник вопрос, а подвержен ли уязвимости HPP WAF от "1C-Битрикс" ? Не вдаваясь в подробности, ответ нет. Проведенные мною сегодня исследования на данную тему показали, что во многих случаях воспользоваться HPP не получится. Однако, HPP действительно богат своими возможностями для некоторых случаев. Тут и Cross-Site Scripting, и SQL-Injection и даже CSRF-атаки. Потому, всем интересующимся сюда .
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.
Что с нашим NGFW? Ответы — 14 апреля в Кибердоме
Конференцию откроет сессия с участием Минцифры, где оценят конкурентоспособность NGFW-решений.