Аудит безопасности сайта глазами заказчика21.07.2015 14:48

В этом топике я хочу рассказать, как проходит коммерческий аудит безопасности сайта, в чем отличие от bounty-программ и «свободного рисерча».
Итак, у клиента есть сайт, в безопасной работе которого он хочет быть уверен. В первую очередь многие сами пытаются исследовать свой сайт на наличие уязвимостей и возможность взлома — например с помощью онлайн сервисов, бесплатных утилит и инструментов. Многие клиенты приходят уже постфактум, когда их сайт был скомпрометирован злоумышленниками. Здесь, помимо лечения зараженного сайта, у клиента есть естественное желание минимизировать возможность повторного взлома сайта.

Основная цель аудита безопасности

Основной целью комплексного аудита безопасности сайтов является определение всех уязвимостей и «слабых» мест сайта. Аудит сайта в режиме «BlackBox» имитирует настоящую атаку хакеров на сайт заказчика без деструктивных последствий. Аудит безопасности сайта на наличие уязвимостей является мощным инструментом для обеспечения информационной безопасности ресурса. Это комплекс работ по выявлению ошибок в коде сайта и программном обеспечении сервера, которыми могут воспользоваться злоумышленники для атаки и взлома сайта. Как правило, в эти работы входят мероприятия: сканирование сайта на уязвимости, ручной анализ содержимого сайта, поиск и выявление ошибок в логике работы скриптов и компонентов веб-приложения.

Аудит безопасности в режиме BlackBox

Процесс тестирования на проникновение подразумевает моделирование реальных действий злоумышленника — поиск уязвимостей системы защиты и их последующую эксплуатацию. Тест на проникновение позволяет получить независимую оценку и экспертное заключение о состоянии защищенности информационной системы. Аудит ресурса (веб-компонентов и веб-окружения) производится методом «BlackBox» и включает следующие этапы:

Пассивный сбор информации;
Определение веб-окружения;
Определение платформы;
Определение типа CMS;
Сканирование портов;
Сбор баннеров / поиск публичных эксплойтов;
Автоматическое сканирование;
Выявление «узких мест» ресурса;
Анализ данных;
Определение «узких мест» ресурса;
Ручной анализ в пассивном режиме;
Сбор и анализ полученной информации;
Анализ векторов атаки;
Подтверждение полученных векторов;
Составление отчета.

Действия над ресурсом:

Поиск уязвимостей серверных компонентов;
Поиск уязвимостей в веб-окружении сервера;
Проверка на удаленное выполнение произвольного кода;
Проверка на наличие переполнений;
Проверка на наличие инъекций (внедрение кода);
Попытки обхода системы аутентификации веб-ресурса;
Проверка веб-ресурса на наличие XSS / CSRF уязвимостей;
Попытки перехватить привилегированные аккаунты (или сессии таких аккаунтов);
Попытки произвести Remote File Inclusion / Local File Inclusion;
Поиск компонентов с известными уязвимостями;
Проверка на перенаправление на другие сайты и открытые редиректы;
Сканирование директорий и файлов, используя перебор и «google hack»;
Анализ поисковых форм, форм регистраций, форм авторизации и т.д.;
Проверки ресурса на возможность открытого получения конфиденциальной и секретной информации;
Атаки класса race condition;
Подбор паролей.

С чего начинается

Договор о неразглашении или NDA. С каждым клиентом подписывается Договор о неразглашении, независимо от объекта и целей аудита. Любая компания, дорожащая своей репутацией, априори не будет распространять конфиденциальную информацию о своих клиентах, но этот Договор даст дополнительную гарантию. Более того, в ходе аудита атакующая сторона (Исполнитель) может получить доступ к критичным данным, коммерческой тайне и т.д.

Подтверждение легитимности. Для исполнителя крайне важно иметь подтверждение законности проведения аудита безопасности — т.е. заказчик должен являться владельцем сайта. В любом другом случае, в том числе и при «свободном рисерче», когда энтузиасты исследуют чужие веб-проекты на наличие уязвимостей, действия атакующей стороны подпадают под 272 статью УК РФ. Что касается Bug-bounty программ — в описании обычно указано перечисление ресурсов и разрешенные действия. При коммерческом аудите заказчик обычно добавляет специализированные маркеры — подтверждение легитимности действий над сайтом; или же заверяет разрешение на проведение аудита документально.

Как итог — составляется договор на оказание услуг, содержащий:

объекты аудита (перечисление адресов ресурсов);
регламент и сроки проведения работ
особые требования (например, не проверять ресурсы *backup).

Как проходит

Обязательным условием является наличие наличие резервных копий объектов аудита, находящихся вне периметра аудита. Как правило, наиболее оптимальный вариант — разворачивание тестового стенда.

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

Итог

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

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