Файл: Web'cepbep.docx

infQtgJskanditek.ru

random designs

Wooden house ALEX

feedback dealers in europe

jroducts standard designs technologies ohotogallerv

tel/fax: +7 812 327-1999, +7 812 323-2301, +7 495 169-65Б7, +7 495 168-0342

Copyright © 2005 SkandiTak Ltd. All Rights Reserved, Design: Siluet Studio

Rambler's

Щ Internet
PORSA

Рис. 5.8. Web-сайт www.skanditek.ru

У меня зачесались руки сделать что-то и показать разработчику ошибку на приме­ре, но ничего не вышло. Настройки хостинговой компании и права доступа в MySQL, под которыми работал web-сайт, не позволяли внедрить код. При попытке добавить команду удаления всех записей из таблицы меня культурно отправляли на web-сайт хостинговой компании, где красовалась надпись "Request rejected". По­пытки вставить данные, удалить таблицу, обновить данные также заканчивались неудачей. Тогда я решил попробовать получить доступ к файловой системе через функции load_file и into outfile, но снова меня ждала неудача.

Единственное, что я мог делать, — просматривать таблицы и выполнять любые за­просы select, но так как в доступных таблицах ничего особенного не было, то и ломать было нечего. Вот что значит правильная настройка, которая спасает даже от неопытных рук программистов.

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

Несмотря на то, что безопасность web-сервера, в основном, зависит от выполняе­мых на нем сценариев и программистов, которые их пишут, есть возможность по­

строить защиту, которая не зависит от этих факторов. Отличное решение данной проблемы — бесплатный модуль для Apache под названием mod_security.




Рис. 5.9. Ошибка SQL




Принцип действия модуля схож с действиями сетевого экрана, который встроен в ОС, только в данном случае он специально разработан для обеспечения взаимодей­ствия по протоколу HTTP. Модуль на основе правил, которые задает администра­тор, анализирует запросы пользователей к web-серверу и выносит свое решение о возможности пропустить пакет.

---

Правила определяют, что может быть в запросе, а что нет. Там обычно содержится URL, откуда необходимо взять документ или файл. Как можно сформулировать правило для модуля с точки зрения безопасности системы?

Рассмотрим простейший пример: для web-сервера представляет опасность несанк­ционированное обращение к файлу /etc/passwd, а значит, его не должно быть в строке URL. Таким образом, создаем правило, и модуль проверяет на основе задан­ных фильтров адрес URL, и если он нарушает правила, то запрос отклоняется.

Итак, модуль mod_security можно найти на web-сайте http://www.modsecurity.org. По­сле его установки в файле httpd.conf можно будет использовать дополнительные директивы фильтрации запросов.

Рассмотрим наиболее интересные из них:

• 
  secFilterEngine On — включить режим фильтрации запросов;
  
• 
  secFilterCheckURLEncoding On — проверять кодировку URL (URL encoding is valid);
  
• 
  SecFilterForceByteRange 32 126 — использовать символы только из указанного диапазона. Существует достаточное количество служебных символов (напри­мер, перевод каретки, конец строки), коды которых менее 32. Большинство из них невидимы, но требуют обработки нажатия соответствующих клавиш. Но как же тогда хакер может ввести такой символ в URL? Только через их код. Напри­мер, чтобы применить символ "конец строки", необходимо указать в URL "%13". В данном случае коды символов менее 32 и более 126 являются недопус­тимыми для адреса, поэтому вполне логично такие пакеты не пропускать к web- серверу;
  
• 
  secAuditLog iogs/audit_iog — определяет файл журнала, в котором будет со­храняться информация об аудите;
  
• 
  SecFilterDefaultAction "deny,log,status:406" — задает действие по умолча­нию. В данном случае указан запрет (deny);
  
• 
  SecFilter xxx redirect:http://www.webkreator.com — обеспечивает переадреса­цию. Если правила соблюдены, то пользователя отправляют на web-сайт
  

http://www.webkreator.com;

• 
  SecFilter yyy log,exec:/home/apache/report-attack.pl — запускает сценарий. Если фильтр срабатывает, то будет выполнен сценарий /home/apache/report- attack.pl;
  
• 
  SecFilter /etc/password — устанавливает запрет на использование в запросе пользователя обращения к файлу /etc/passwd. Таким же образом нужно добавить ограничение на файл /etc/shadow;
  
• 
  SecFilter /bin/ls — отказ пользователям в обращении к директивам. В данном случае запрещается команда ls, которая может позволить хакеру уви­деть содержимое каталога, если в сценарии есть ошибка. Необходимо предотвра­тить обращения к таким командам, как cat, rm, cp, ftp и др.;
  
• 
  SecFilter "\.\./" — классическая атака, когда в URL указываются символы точек. Их не должно там быть;
  
• 
  SecFilter "delete[[:space:]]+from" — запрет текста delete...from, который чаще всего указывается в SQL-запросах для удаления данных. Такая строка очень часто используется в атаках типа SQL-инъекции. Помимо этого, рекомен­дуется установить следующие три фильтра:
  

---

• 
  SecFilter "insert [ [: space: ] ] +into" — используется в SQL-запросах для до­бавления данных;
  
• 
  SecFilter "select.+from" — используется в SQL-запросах для чтения данных из таблицы базы данных;
  
• 
  SecFilter "<(.|\n)+>" и SecFilter "<[[:space:]]*script" — позволяют защи­титься от XSS-атак (Cross-Site Scripting, межсайтовое выполнение сценариев).
  

Мы рассмотрели основные методы, использование которых может повысить безо­пасность вашего web-сервера. Таким образом можно защищать даже сети из web- серверов.

3. 
   Защита СУБД
   

Ошибке, приводящей к возможности SQL-инъекции, подвержены сценарии на всех языках программирования и все СУБД. Дело в том, что к этому приводит особен­ность языка SQL, а хакер использует именно его возможности.

Простейшая защита от SQL-инъекции строится следующим образом: вы должны запрещать использовать или изолировать (обезвреживать) одинарную кавычку там, где она может нанести вред. Это простая, но не самая эффективная защита, а о са­мой эффективной чуть ниже.

Возможности, которые может получить хакер при использовании SQL-инъекции, зависят именно от используемой СУБД. Если я не ошибаюсь, то до сих пор наибо­лее популярной является MySQL, но ей на пятки точно наступает PostgreSQL.

Однако в интернете можно встретить множество web-серверов, которые использу­ют более мощные (обладающие большим количеством возможностей) СУБД, на­пример, Oracle или MS SQL Server. Но именно дополнительные возможности могут дать хакеру опасные привилегии при неправильной настройке.

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

У простых пользователей не должно быть возможности удалять записи, поэтому для них должен стоять запрет на выполнение оператора delete. Вставка данных необходима таким сценариям, как форум или гостевая книга, а если у вас сценарии, которые только отображают данные (выполняют оператор select), то нужно запре­тить и insert

---

. Обновление данных тоже достаточно популярная функция, и редко бывает возможность запретить ее.

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

В MS SQL Server есть одна очень опасная процедура — xp_cmdsheii, с помощью которой можно выполнять команды от имени учетной записи, под которой работа­ет MS SQL Server. Так как эта СУБД очень часто работает под системной учетной записью, то хакер может получить неограниченные права.

Еще одна процедура, которая может быть опасной, — sp_makewebtask; создающая новую задачу, а также функции отправки сообщений электронной почты xp_startmail, xp_sendmail. Почему так опасны почтовые функции? Дело в том, что хакеры могут использовать ваш web-сервер для рассылки спама, который может оказаться достаточно опасным. Чем? Ваш web-сервер может попасть в спам-листы, и ваши пользователи не смогут получать нужную корреспонденцию, да и не ис­ключены проблемы с правоохранительными органами. Спам во многих странах стал уголовно преследуемым. Да, вы не виноваты в том, что хакер использовал ваш web-сервер, и вас оправдают, но проблемы с законом ничего хорошего не принесут. Разве что можно заработать временную скандальную известность. Если вам нужен скандал, то можете оставить дыру и повесить объявление: "Взломайте меня", или объявите конкурс на лучший взлом.

Но с какой базой данных вы бы ни работали, универсальный и самый лучший ме­тод защиты от SQL инъекции — это параметризированные запросы.

Когда-то было мнение, что для защиты, от инъекции нужны хранимые процедуры. Это так, они действительно защищают, потому что единственный способ вызвать хранимую процедуру и при этом повлиять на ее выполнение - это передать ей зна­чения в качестве параметров. Так что хранимые процедуры или простые запросы с использованием параметров являются идеальным способом защиты.

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

Параметры — отличный способ защиты, и раз уже мы начали использовать PHP для иллюстрации примеров, давайте продолжим это делать. В SQL на месте, где будут находиться данные, полученные от пользователей, нужно написать двоето­чие и имя, которое вы хотите дать параметру. Если мы проверяем имя и пароль, то можно назвать параметры :username и :password:

---

$sql = "SELECT * FROM user WHERE username = :username AND password = :password";

У нас одна большая строка, которая заключена в двойные кавычки, и уже нет ника­ких объединений с помощью плюсов или точек. Какой бы язык программирования вы ни использовали, основной признак SQL-инъекции — это внедрение параметров в запрос SQL через плюс или любой другой метод сложения строк. Если же у вас одна цельная строка, то это хороший знак, что запрос будет безопасным, если толь­ко вы потом ничего в него не вставляете и никак не изменяете эту строку. Я никак не меняю строку, так что она безопасна.

Теперь подготавливаем запрос, как мы это делали и раньше с помощью prepay, чтобы получить объект $query. У этого объекта есть метод bindValue, принимаю­щий два параметра — имя параметра, которому нужно предоставить значение, и само значение:

$query = $connection->prepare($sql);

$query->bindValue(":username", $_POST['username']); $query->bindValue(":password", $_POST['password']);

$query->execute();

И вот когда все параметры уже привязаны, можно выполнять запрос.

То же самое можно было бы сделать в две строки без использования bindValue, просто передать все имена параметров и значения прямо методу execute: $query->execute([":username" => $_POST['username'],

":password" => $_POST['password']]);

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

[имя параметра 1 => значение 1, имя параметра 2 => значение 2]

Параметры очень удобны, когда мы точно знаем, сколько их и где они расположе­ны в запросе, потому что мы просто ставим имя в нужном месте и используем. А что, если есть какое-то параметр, который может проверяться на соответствие не­скольким значениям? В SQL это часто выражается оператором in (). Что, если в in может находиться 2, а то и 10 значений? Можно как-то динамически собирать стро­ку SQL, но в нее помещать не сами значения, а именно параметры:

---