Книга: Безопасность веб-приложений. Исчерпывающий гид для начинающих разработчиков
Назад: Тестирование приложения
Дальше: Динамическое тестирование безопасности приложений (DAST)

Инструменты разработчика

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

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

СОВЕТ. Используя инструменты разработчика, всегда следует проверять, есть ли «скрытые поля» и содержатся ли в них конфиденциальные данные. Если это так, исправьте данную проблему или сообщите о ней. В скрытые поля никогда не следует помещать ценные либо конфиденциальные данные.

Веб-прокси

Мы уже затрагивали тему веб-прокси. Они находятся между браузером и веб-приложением, отслеживая обмен данными между браузером (фронтенд) и сервером (бэкенд приложения). Однако мы не упомянули о том, что веб-прокси являются прекрасным инструментом для ручного тестирования безопасности.

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

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

При использовании веб-прокси можно проверить приложение на разнообразные известные уязвимости – например, инъекционные или XSS. Поместив атаку непосредственно в веб-прокси и отправив запрос, можно узнать о ее успешности исходя из поведения приложения. Необходимо изучить все возможные входы в приложение при работе с веб-прокси.

ВНИМАНИЕ. В идеале при тестовой атаке на веб-приложение нужно проверить его на уязвимости, не причинив ему какого-либо вреда. Например, при тестировании на XSS-уязвимость можно вызвать всплывающее окно сообщения или украсть cookie либо сессию пользователя. При тестировании на слепую SQL-инъекцию можно послать базе данных команду перехода в сон с таймером, а затем засечь время ответа, чтобы проверить, выполнит ли она ее. Оба этих примера используют возможную уязвимость, но не наносят ущерба и не раскрывают потенциально важные данные. Некоторые клиенты захотят большего: например, получить данные из базы данных как доказательство, что их можно прочитать. В таком случае, прежде чем действовать, следует убедиться в том, что их устраивает такое глубокое погружение в приложение.

Веб-прокси также показывает все API, к которым обращается веб-приложение. Их тоже следует изучить, чтобы подтвердить их безопасность, поскольку от них зависит приложение. Используя веб-прокси, можно напрямую взаимодействовать с API, минуя фронтенд. При первом изменении значения в запросах можно попытаться подсчитать все страницы и функции веб-сайта или API. Например, у нас есть API под названием «Сотрудники» с возможностью вызова функции «Заголовок». Может быть, стоит попытаться вызвать функцию «Адрес», чтобы узнать, существует ли она? Опять же, следует изучить и протестировать все возможные входы для каждого API.

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

Фаззинг

Фа́ззинг (англ. fuzzing) – техника тестирования программного обеспечения, часто автоматическая или полуавтоматическая, заключающаяся в передаче приложению на вход неправильных, неожиданных или случайных данных. Предметом интереса являются падения и зависания, нарушения внутренней логики и проверок в коде приложения, утечки памяти, вызванные такими данными на входе.

Википедия


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

Представьте, что в приложении есть поле ввода и вы вводите в него букву «а», затем нажимаете кнопку «Отправить». Приложение действует определенным (ожидаемым) образом. Затем вы вводите «aa», и снова получается удовлетворительный результат. Затем следуют 100, 200, 1000, 10 000 символов и т. д. После всех этих действий вы отправляете теги <script>, одинарные кавычки и шелл-код и смотрите, примет ли приложение эти вводные данные или станет работать по-другому. С помощью инструмента фаззинга можно добавить больше потоков и поместить его в фоновый режим, чтобы ускорить данный процесс.

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

Фаззинг можно применять к любому входу в приложение, включая URL-параметры (API), поля ввода, файлы и папки, cookie, заголовки, обнаружение скрытых полей, а также к HTTP-методам.

Назад: Тестирование приложения
Дальше: Динамическое тестирование безопасности приложений (DAST)