ИНТРО
Добрый день, товарищи!
Сегодня мы поговорим о тестировании безопасности веб-приложений. Сам я инженер по тестированию, по образованию – специалист по информационной безопасности, а по жизни – параноик.
В то время, когда я учился в университете, было не принято преподавать какие-то реальные вещи (читай – потребности отрасли), касающиеся защиты и компрометации информационных систем. Конечно, это можно было бы списать на бюрократию и сложности внедрения новых методик, но я думаю, что там, как и везде, просто больше любят бумажки – оттуда и безопасность у нас — «бумажная». В работе же необходимы практические навыки и знания.
1. СНАРУЖИ
Ни для кого не секрет, что количество сетевых атак неуклонно растет. Каждый день их совершается около 1000, подсчитать же их число за год практически невозможно (это наглядно видно из статьи Стива Моргана). Атакам подвергаются самые разные сетевые ресурсы – от сайта местного провайдера до федерального размера (агентурной) торговой сети суши и атомных станций. Можно даже посмотреть на интерактивную карту кибератак в режиме онлайн.
И каждый уязвим. И каждый отдает себе отчет об этом риске. И каждый думает, что это не про него. Что уж там душой кривить – мы так привыкли. Нежелание признавать риски приводит к нежелательным последствиям.
Давайте рассмотрим безопасность подробнее, ведь «в действительности все не так, как на самом деле» (с).
1.1 Что же такое тестирование? А тестирование безопасности? А тестирование безопасности веб-приложения или веб-сервера (нужное подчеркнуть)?
Тестирование – это процесс достижения совершенства. А тестирование безопасности – процесс достижения совершенства в открытом космосе при условии, что с Вашим скафандром что-то не так 🙂 Но если вернуться на Землю, то тестирование безопасности веб-приложения – это попытка найти все те места, в которых могли допустить ошибку разработчики или просто не предусмотреть / забыть (подчеркните ваш случай).
Веб-приложение и веб-сервер неразрывно связаны. Тестирование одного без другого не даст полной картины бедствия. Тестируя защиту веб-приложения, мы ищем уязвимые места для атаки на пользователей. Тестируя защиту веб-сервера, мы ищем уязвимые места для атаки на сервер, его инфраструктуру.
1.2 Для чего все это нужно? Почему так много компаний заинтересовано в проведении тестирования безопасности?
Нужно все это в первую очередь людям: простым смертным, решившим заказать пиццу, а не отправить данные своей карты непонятно куда; простым владельцам пиццерий, не беспокоящимся, что кто-то смог бесплатно научиться заказывать пиццу через их приложение; простым разработчикам, которым не придется править код в 3 часа утра.
Как правило, небольшие организации, имеющие свой сайт и небольшой сервер с битриксом, думают, что они слишком малы для того, чтобы стать мишенью для атаки. И в этом они заблуждаются. Безусловно, вероятность таргетированной атаки на них ниже, чем на финансовых гигантов, но все-таки не равна нулю. В нынешнее время нейронных сетей и повальной автоматизации никто не будет выяснять, большой ли денежный оборот у фирмы. Главное – это количество уникальных посетителей, ведь суммарно в их карманах может оказаться больше «фишек», чем компания получает за год.
Существуют компании, которые уже взломали, и компании, которые еще не взломали. На практике это вопрос времени. Правильные компании, которые тратят на безопасность значительную часть прибыли, – это нормальный порядок вещей для всего цивилизованного мира. В нашей стране, к сожалению, пока к этому не пришли, считая, что «хата наша с краю» студент-старшекурсник вполне способен настроить одну «циску» и запретить доступ к внутренним ресурсам извне (мол, «денег нет, но вы держитесь»). Ведь мы не привыкли тратить деньги на свою безопасность: бюджет отделов по информационной безопасности (ИБ) обычных компаний только сокращается. А ведь ежегодный ущерб от атак насчитывает более 85 млрд. $. С другой стороны, многие адекватные компании (читай, иностранные) формируют собственный штат по информационной безопасности, другие многие нанимают специалистов на аутсорс, немногие запускают программы баг-баунти, где любой желающий может принять участие в поиске уязвимостей. Безусловно, все они хотят сохранить свои доходы и свою репутацию.
1.3 На что и на кого ориентировано тестирование безопасности? Кто получит выгоду от этого в первую очередь?
Конечно же, безопасность в первую очередь ориентирована на $ ☺. Кто говорит, что это не так, – нагло врет вам в лицо :).
Естественно, в первую очередь от безопасного серфа сайта выигрывает пользователь. Если нет нужды беспокоиться о том, что Ваши персональные данные могут утечь в сеть, то и доверять ресурсу Вы будете больше. А если счастлив пользователь, то счастлив и владелец веб-ресурса (и тем более он счастлив, чем меньше у него рисков потерять финансы).
2. ИЗНУТРИ
Исследование безопасности веб-ресурса – сложная и кропотливая работа, требующая внимательности, фантазии и творческого подхода. Исследователю безопасности необходимо глубокое понимание технической изнанки работы веб-приложения и веб-сервера. Каждый новый проект дает пищу для фантазии, каждый новый инструмент – просторы для творчества. Да и вообще, тестирование безопасности больше похоже на исследовательскую работу – это постоянный поиск и анализ.
2.1 Как тестирование безопасности выглядит изнутри? Чем руководствуется инженер? Как выставляет приоритеты?
Каждый новый проект требует применения новых инструментов, изучения новых технологий, поглощения множества книг и статей, которые достаточно трудно найти. Большая часть информации находится в англоязычном пространстве, что добавляет определенные трудности в освоении материала людям, языком английским не владеющим.
Если говорить о процессе тестирования безопасности, то в целом он не сильно отличается от тестирования обычного: поиск, локализация, воспроизведение, заведение, отчет. Приоритеты, безусловно, зависят от заказчика, от целей тестирования.
К сожалению, некоторые курсы по тестированию безопасности / анализу защищенности / аудиту безопасности в интернете внушают, что достаточно пройтись по веб-приложению каким-нибудь сканером безопасности – и все готово! Отчет есть, уязвимости – вот они! Что же еще вам нужно? Но не стоит быть таким наивным. Большинство уязвимостей ищется и находится именно вручную, при внимательном изучении. Они могут быть совершенно несложными, но автоматические сканеры пока еще не способны их обнаружить.
2.2 Несколько слов об OWASP TOP 10.
Классификацией векторов атак и уязвимостей занимается сообщество OWASP (Open Web Application Security Project) – международная некоммерческая организация, сосредоточенная на анализе и улучшении безопасности программного обеспечения.
OWASP (https://www.owasp.org/) составил список из 10-и самых опасных уязвимостей, которым могут быть подвержены интернет-ресурсы. Сообщество обновляет и пересматривает этот список раз в три года, поэтому он содержит актуальную информацию. Последнее обновление было сделано 2017 году («Огласите весь список, пожалуйста!» (с)):
- Внедрение кода;
- Некорректная аутентификация и управление сессией;
- Утечка чувствительных данных;
- Внедрение внешних XML– сущностей (XXE);
- Нарушение контроля доступа;
- Небезопасная конфигурация;
- Межсайтовый скриптинг;
- Небезопасная десериализация;
- Использование компонентов с известными уязвимостями;
- Отсутствие журналирования и мониторинга.
2.3 Методика тестирования. GuidLine от OWASP.
Организация OWASP дополнительно к своему списку из 10 самых опасных уязвимостей разработала методические рекомендации (практикум) по тестированию безопасности веб-приложений. В них подробно, шаг за шагом, описано, как и что необходимо тестировать, на что обратить внимание в первую очередь, а на что – во вторую. Методика носит рекомендательный характер и, конечно, никого ни к чему не обязывает (инженер, проводящий тестирование, некоторые моменты может перенести, а другие – вообще опустить), но, тем не менее, позволяет сделать максимальное покрытие для веб-приложения.
Итак, весь процесс тестирования состоит из двух этапов:
- Пассивный, во время которого тестировщик пытается понять логику приложения и «играет» с ним. Могут использоваться инструменты для сбора информации. Например, с помощью HTTP прокси можно изучить все HTTP-запросы и ответы. В конце данного этапа тестировщик должен понимать все точки входа приложения (HTTP-заголовки, параметры, куки и пр.).
- Активный. Во время данного этапа тестировщик проводит тесты в соответствии с методологией. Все тесты разбиты на одиннадцать подразделов:
- сбор информации;
- тестирование конфигурации;
- тестирование политики пользовательской безопасности;
- тестирование аутентификации;
- тестирование авторизации;
- тестирование управления сессией;
- тестирование обработки пользовательского ввода;
- обработка ошибок;
- криптография;
- тестирование бизнес-логики;
- тестирование уязвимостей на стороне пользователя.
2.4 Переход к технической стороне вопроса. Инструментарий – ручной или автоматизированный? Какой для чего?
Какие инструменты используются для анализа безопасности? Оценив объемы бедствия, следует сбежать рассмотреть существующие инструменты. Конечно же, главные Ваши аргументы против несправедливости в сетевых именах – это глаза и мозг 🙂 На самом же деле, добрые люди разработали огромный инструментарий – начиная от специализированных скриптов, «заточенных» для какой-то одной конкретной цели, и заканчивая целыми комбайнами — готовыми выжать максимальные выводы из минимума вводных. К сожалению, часто такой результат оказывается лже-срабатыванием. Как правило, инженер по тестированию при выборе инструментов основывается на приоритетах: что важнее – время или область покрытия? Современные разработчики довели автоматизацию до небывалых высот, поэтому можно смело следовать принципу Парето: 80% работы скармливать автоматизированным анализаторам, а все оставшееся «проходить руками». Но, честно говоря, результаты автоматизированных средств все равно придется изучать и проверять.
Приведем небольшой список категорий инструментов:
- сканеры веб-уязвимостей;;
- инструменты для эксплуатации уязвимостей;
- инструменты криминалистики;
- сканеры портов;
- инструменты мониторинга трафика;
- отладчики;
- руткит детекторы;
- инструменты шифрования;
- инструменты для брутфорса.
2.5 Откуда же возникают все эти уязвимости?
Из-за разгильдяйства разработчиков. Из-за невнимательности. Из-за халтуры. Из-за лени. Из-за-за…
Но чаще всего уязвимости возникают из-за неопытности. Не все разработчики представляют себе, как злоумышленник будет атаковать их продукт. Некоторые считают, что достаточно экранировать кавычку («’») в пользовательском вводе или спастись «magic_quotes» – и можно будет избежать SQL-инъекции. Отсюда и получается, что превентивные меры мы принимаем, а что делать дальше – не знаем. И WAF’ы нас не спасут.
АУТРО
В качестве заключения:
Человек – существо несовершенное. Ему свойственно ошибаться. Но каждая ошибка – это повод двигаться вперед. Люди разрабатывают информационные системы, и эти системы, подобно творцам, такие же несовершенные. Поэтому каждая ошибка, каждая уязвимость – это шаг на долгом пути к совершенству.
