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

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

Сбор информации о сайте

Итак, для того, чтобы попытаться найти какие-либо конфиденциальные данные на сайте, злоумышленнику прежде всего необходимо проанализировать его структуру (ПО веб-сервера, его версия, общедоступные адреса ресурсов, хранящихся на нём и т.д.). А для того, чтобы провести хоть какой-то анализ, нужны хоть какие-то сведения. Верно? В зависимости от того, сколько на самом деле изначально знает злоумышленник о системе, методы сбора информации и последующего анализа могут различаться. Мы же будем рассматривать вариант, когда последний изначально обладает минимальным объёмом информации о анализируемом объекте. Т.е. он знает, что перед ним веб-сайт, но не знает ни ПО установленного на нём, ни версии, ни того, что на нём находится.

В этом случае, сбор информации начинается с просмотра всех доступных данных выдаваемых веб-сервером. Некоторые методы сбора информации приведены ниже.

Сканеры безопасности

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

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

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

Содержимое HTML документов

Этот способ заключается в банальном просмотре содержимого HTML документов выдаваемых сайтом (View Source). Ведь даже там можно обнаружить множество интересных вещей

Пример 1 – ищем в формах:

Пример 2 – ищем адреса ресурсов

Комментарии:
Узнаём о существовании каталога secret и подкаталога simple в нём (быть может, доступ к одному из них открыт и в нём есть что-то полезное

Пример 3 - сообщения об ошибках

П.С: Нередко взломщик умышленно вызывает сценарии, передавая им некорректные параметры, для того, чтобы последние выдавали такие сообщения.

Служебные файлы

Пример - robots.txt

User-Agent: *
Disallow: /cgi-bin/
Disallow: /admin/

Комментарии:
Взломщик узнаёт о существовании каталогов cgi-bin и admin на сайте.

П.С: В своей предыдущей статье я уже упоминал о пользе этого файла с одной стороны, и опасности, которую он может нести с другой.

Это были лишь самые известные методы сбора данных о чужом веб-сайте. Перечисление их всех выходит за рамки этой статьи. Да и вообще сомневаюсь, что это возможно сделать.

Анализ полученных данных

Как говорится в одном старом анекдоте - вероятность того, что на улице встретишь слона составляет 50% =) Так и тут, вероятность того, что злоумышленник соберёт или не соберёт достаточный объём информации о веб-сайте зависит в основном от квалификации веб-мастера и изобретательности хакера. Автор искренне надеется, что вы относитесь к тем веб-мастерам у которых "шиш" что найдёшь. Однако, как показывает практика, второй случай встречается чаще (как это не печально).

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

Имеется некий веб-сайт. На нём обнаружен сценарий user.php, который выдаёт следующее сообщение об ошибке:

Warning: Failed opening '/home/www/user.inc' for inclusion (include_path='') in /home/www/user.inc on line 28

Значит на сайте в корневом каталоге существует файл с подпрограммами - user.inc. А т.к. его расширение "inc", а не "php", то вполне возможно, что веб-сервер выдаст его содержимое, а не как задумывал программист, выполнит этот файл как сценарий. После этого, злоумышленнику удаётся просмотреть содержимое данного файла из которого, помимо всего прочего, он узнаёт о существовании скрипта admin.php. Взломщик также обращает внимание, на то, что веб-мастер любит называть прилагаемые PHP модули, как и сами сценарии, только с расширением inc, которое, в свою очередь, администратор забыл сделать исполняемым для PHP (бывают же такие совпадения И соответственно, пытается скачать файл admin.inc. Что ему на этот раз и удаётся. В файле он находит пароль администратора. А в последствии обнаруживается, что этот пароль годен и для доступа на сервер через FTP.

Итог - сайт взломан. Администратор горюет (смотрит логи), хакер ликует (пьёт пиво).

Ошибки веб-мастера и администратора в данном случае:

1. Администратор забыл отключить отладочный режим (debug mode) в PHP;

2. В некоторых учебниках по PHP даются примеры, где прилагаемые файлы имеют расширение inc. Если давать такие расширения прилагаемым файлам, то необходимо "привязывать" их к соответствующему интерпретатору, иначе это дело становится весьма рискованным (вы же не хотите, чтобы ваши сценарии могли читать посторонние). Намного безопаснее давать модулям двойное расширение следующего вида - "inc.<оригинальное расширение>" (в данном случае - "inc.php");

3. Администратор использует одинаковые пароли к нескольким сервисам на сервере (для доступа к FTP и БД).

Подведём итоги

В этот раз я намерено пропустил колонку "Решение проблемы", так как универсальной панацеи от всех возможных недугов не существует. Тем не менее, настоятельно рекомендую всем веб-мастерам и сисадминам ещё раз проверить, что и как хранится на вашем сайте, верно ли проставлены права доступа к файлам, имеется ли возможность просмотра содержимого каталогов, отключён ли режим отладки у PHP и т.д. и т.п. Словом, насколько сложно злоумышленнику добраться до ваших сокровенных данных Можете даже на время встать на его место и попробовать взломать СВОЮ собственную систему (ещё раз повторяю, только СВОЮ И НЕ ЧЬЮ ДРУГУЮ, т.к. взлом чужого сайта - дело противозаконное). И помните – не бывает абсолютной защиты, бывает лишь максимально возможная!