WEb практикум. Web'cepbep

• Название: Web'cepbep
• Анкор: WEb практикум
• Дата: 22.01.2023
• Размер: 4.76 Mb.
• Имя файла: WEB.docx
• Тип: Документы; #898678
• страница: 8 из 18

Preg test

---

Команда:

Параметр:

---

if (isset($_GET['command']))

{

$command = $_GET['command'];

$var = $_GET['var'];

print("Executed command: $command
"); preg_replace("/(".$command.")/e", "\\1", $var); print($var);

}

?>





Форма отображает два поля ввода: команда и параметр. Затем происходит про­верка; если параметр command получен методом get, то происходит его замена с по­мощью функции preg_replace. В общем виде эта функция выглядит следующим образом:

preg_replace(pattern, replace, var);

Функция ищет в параметре var строку, соответствующую регулярному выражению из первого параметра, и заменяет его значением второго параметра replace. Если указан модификатор e, то перед заменой происходит выполнение найденного кода.

А что если хакер может воздействовать на регулярное выражение и строку, в которой происходит поиск (первый и третий параметр)? Если третий параметр очень часто и есть передаваемое пользователем значение, то на первый он влиять не должен.

Давайте теперь рассмотрим сценарий из листинга 3.14. Здесь у нас и в первом, и в третьем параметре есть переменные, на которые влияет пользователь:

preg_replace("/".$command."/e", "\\1", $var);

А что если через параметр command передать system\ (is\), а в параметре var пере­дать system(ls) ? Почему в первом случае перед скобками стоят слеши? Дело в том, что значение будет попадать в регулярное выражение, где круглые скобки имеют специальное значение, и чтобы они воспринимались просто как скобки, необходи­мо перед ними поставить слеши. В этом случае сценарий будет искать в var значе­ние из command, и найдет, потому что в нашем случае эти параметры идентичны. А когда функция найдет соответствие, код будет выполнен. В данном случае в каче­стве кода передается PHP-функция system с командой ls, которая отображает со­держимое текущего каталога.

Усложним задачу. Допустим, что в регулярном выражении используется модифи­катор i, который ничего не выполняет:

preg_replace("/".$command."/i", "\\1", $var);

Красиво, но тоже не безопасно, потому что в регулярном выражении все еще ис­пользуется переменная, содержащая пользовательские данные, которая не подвер­гается проверке. В параметре command попробуем передать следующее выражение:

system\(ls\))/e%00

Давайте рассмотрим это выражение внимательнее. Для этого я разбил его на три части и выделил их пробелами: system\(ls\) )/e %00

Первая часть — это команда, которую мы передавали и в прошлый раз, и ее необ­ходимо выполнить. Вторая часть закрывает регулярное выражение и указывает мо­дификатор e. Последняя часть — это нулевой байт, который является концом стро­ки. Благодаря нулевому байту строка и вся оставшаяся часть регулярного выраже­ния, которая прописана в сценарии, будет проигнорирована. Таким простым трюком мы подменили регулярное выражение и модификатор i заменили на e.

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

Напоминаю, что модификатор e в регулярном выражении используется только в функции preg_replace.

Не забываем, что это регулярное выражение Perl, а значит, что там тоже может быть подобная проблема. Почему "может быть"? Я этот язык знаю намного хуже и не могу утверждать этого наверняка.

5. 
   Опасность переменных окружения
   

В PHP есть несколько переменных окружения. Посмотрим некоторые из этих пе­ременных:

• 
  $server_addr — IP-адрес web-сервера, на котором запущен сценарий;
  
• 
  $server_port — порт web-сервера, к которому подключился клиент для выпол­нения запроса;
  
• 
  $server_name — имя хоста web-сервера;
  
• 
  $server_protocol — версия HTTP;
  
• 
  $remote_addr — IP-адрес компьютера, запросившего файл сценария;
  
• 
  $remote_port — порт удаленного компьютера, с которым установлено соедине­ние;
  
• 
  $request_uri — URL к файлу без имени домена или адреса web-сервера. Напри­мер, если был запрошен адрес http://192.168.L1/admm/mdex.php, то эта пере­менная будет содержать значение "/admin/index.php";
  
• 
  $query_string — строка запроса, которая содержит список переданных парамет­ров. Параметры разделены символом амперсанда, а сами параметры имеют вид "имя=значение";
  
• 
  $http_user_agent — строка, идентифицирующая программу клиента, например название браузера, хотя ее значение не всегда соответствует действительности;
  
• 
  $http_accept — перечень файлов, которые может обработать клиент.
  

Далеко не все из этих переменных безопасны, потому что хакер может воздейство­вать на них. Дело в том, что некоторые параметры берутся из полученного от поль­зователя пакета, и нет гарантии, что не хакер подделал их. Например, переменная $http_user_agent указывает на браузер, который отправил запрос. Этот параметр заполняется браузером автоматически, но хакер легко может сформировать такой запрос, в котором $http_user_agent будут содержать неверные данные.

Давайте рассмотрим всю опасность на примере переменной $request_uri. Не дове­ряйте этому параметру, потому что хакер может легко повлиять на него. Допустим, что у вас есть следующий код формы:


print("

");

// Здесь находятся элементы управления

print(""); print("

");

?>

В данном случае форма передает введенные данные сценарию, адрес которого формируется из переменных $server_name и $request_uri. Если объединить содер­жимое этих двух переменных, то мы получаем полный URL к текущему сценарию, то есть данные сценарий направит сам себе, но при этом URL будет определен ди­намически. Очень удобное решение, но опасное.

Допустим, что хакер введет в строке URL следующий адрес: http://yoursite/ mdex.php?">. В ответ на это окно браузера отобразит модальное окно, в котором будет отображено содержимое cookies. Да, хакер увидит свои cookies, но чтобы украсть данные другого пользователя, доста­точно сделать так, чтобы жертва щелкнула на нужной ссылке, и подставить ей нужный JavaScript-код.

Это классическая XSS-атака, о которой более подробно мы поговорим в главе 10. Сейчас же мы только обозначили источник проблемы. А о самой проблеме и как с ней бороться, мы поговорим отдельно, потому что она не связана только с языком PHP, эта уязвимость присуща и другим языкам и платформам.

5. 
   Выполнение в iframe
   

Вроде бы какая может быть проблема, если кто-то запустит ваше приложение внутри фрейма? Но нет, проблема действительно тут есть. Если вы разрешаете вы­полнение приложения во фрейме, то у хакера появляется возможность попробовать воровать данные ваших пользователей, и для этого есть несколько достаточно ин­тересных методов атаки.



(Ь + о
ritoy//UMrs/nbkh*ilfl«nov/Projecti/Weto/pftpbook/1r*ffle html С

Основной сайт

I Подкасты Плюс»




*

т
Програмыспи

Рис. 3.5. Мой сайт во фрейме

Следующий HTML-код страницы может располагаться на любом сайте





<Ь1>Основной сайт