Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Но я же не тестирую безопасность! Тестирование безопасности Web-сервисов для чайников – часть 2
27.07.2018 10:43

Автор: Кейт Паулк

Оригинал статьи: http://dojo.ministryoftesting.com/lessons/but-i-m-not-a-security-tester-security-testing-on-the-web-for-the-rest-of-us

Перевод: Ольга Алифанова

Ваша первая сессия с Fiddler

Для начала минимизируйте все, что может затруднить вам просмотр. Закройте все, что стучится в сеть, кроме одной вкладки одного браузера. Я выбираю IE из-за приятного плагина, а затем запускаю Fiddler.

Перейдите во вкладку «Фильтры» (Filters) и разрешите фильтрацию, а затем убедитесь, что отображается только трафик из вашего избранного браузера. В теории запущен должен быть только этот единственный браузерный процесс, но некоторые из них, особенно в 64-битных системах, запускают несколько процессов. Это еще одна причина выбирать IE. Кликните на чек-боксе, да и все. Готово. Вы видите только трафик IE.

Если веб-приложение, с которым вы работаете, не имеет настроенного SSL в тест-окружении, не включайте расшифровку SSL. Fiddler работает как прокси-сервер для всего веб-трафика, поэтому он может и будет разрывать все, что разговаривает с Интернетом. Это разрушение намного более… интересно, если вы тестируете что-то, приходящее через SSL. Fiddler создает самостоятельно подписанный сертификат, который заставляет появиться все возможные предупреждения браузера о контенте, не заслуживающем доверия (тяжелее быть более очевидным, чем «НЕ ДОВЕРЯЙТЕ», но я уверена, кто-нибудь справится с более жутким алертом). Вы обнаружите, что не можете никуда попасть из-за бесконечных предупреждений безопасности. Это одна из причин, по которой профи рекомендуют работать на виртуальной машине. Возня с Интернет-профилем вашей виртуальной системы не повлияет на вашу обычную систему.

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


Все вкладки во вкладках Request data и Response data содержат полезную информацию в зависимости от того, на что вы смотрите. Сейчас обратите внимание на вкладку WebForms во вкладке Request.

Скрытые поля, поля cookie и все, что вы заполнили, как на ладони. Это один из способов посмотреть на эскалацию привилегий (тип нарушения безопасности, когда пользователь может заставить приложение сделать то, на что у него нет прав – к примеру, комментатор блога может редактировать чьи-нибудь посты).

В первую очередь перейдите во вкладку Composeк в верхнем ряду вкладок. Эту вкладку я использую чаще всего, помимо Inspectors. Перетащите подсвеченный запрос, который вы исследуете, во вкладку Composer. Появится текст запроса, ожидающий ваших изменений.

Теперь вы можете редактировать любое поле тела запроса, и что угодно в строке запроса. Или можно заменить cookie на любую другую, записанную во время просмотра. Или удалить ее совсем. Если вы тестируете что-то, что не может быть сделано, если вы не авторизованы, и у вас есть cookie аутентификации – попытайтесь удалить ее в Composer и подтвердить.

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

Что еще можно сделать

  • Посмотрите, что произойдет, если вы добавите в GET что-нибудь вроде этих строк:
    • <script>alert(document.cookie);</script>
    • %3Cscript%3Ealert(document.cookie)%3B%3C%2Fscript%3E
    • (Это упрощенные примеры, но если ваша команда не особенно опытна в области безопасного кода, они могут сработать. Это значит, что кто угодно может сделать поп-ап с подсказкой пароля, позволяющий собирать имена и пароли пользователей).
    • Последуйте примеру XKCD с little Bobby Tables в любом из полей формы.

Что вы можете найти

Открытый проект по безопасности веб-приложений ((OWASP) поддерживает список десяти самых распространенных веб-уязвимостей. Сейчас они принимают предложения для списка 2016 года, но список 2013 года все еще полезен. Хакеры целятся в легкие мишени, поэтому убедитесь, что в плане этих уязвимостей вы защищены. Сейчас я пробегусь по некоторым уязвимостям из списка, чтобы показать, как можно использовать Fiddler, тестируя их.

OWASP Top 10 - #1: Инъекция

Инъекция заставляет сайт запускать код, который заложили вы, вместо собственного кода или вместе с собственным кодом. Она не просто так идет в списке первым номером. Кто угодно может это сделать, для этого не нужно особых навыков, а разрушения она может принести колоссальные.

Вкладка Composer в Fiddler позволяет проверять несколько типов инъекций, редактируя запросы, которые вы уже отправили, и менять значения полей или строк запросов. Большой список противных запросов на GitHub – неплохое место для старта, потому что он группирует строки по мере того, какой ущерб они могут нанести.

OWASP Top 10 - #2: Сломанная аутентификация и менеджмент сессий

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

Проверить это через Fiddler до смешного просто. При запущенном Fiddler авторизуйтесь в приложении, сделайте что-нибудь, что требует авторизации, затем выйдите из системы. Выберите момент, который требовал авторизации, кликните правой кнопкой и выберите Replay.

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

OWASP Top 10 - #3: Кросс-сайтовые сценарии (XSS)

Кросс-сайтовые сценарии, или XSS – возможно, самая распространенная уязвимость сайтов согласно базе данных OWASP. XSS просто заставляет сайт запускать Javascript, заложенный атакующим. Это один из способов выкрасть данные пользователей. Если они могут заставить сервер запустить Javascript, открывающий диалоговое окно повторного ввода логина и пароля, они могут заставить это окно отправить логин и пароль им на почту, пока вы, жертва, думаете, что сайт просто перестраховывается.

Для проверки этой уязвимости, как и для проверки любой инъекции, можно использовать Fiddler. Используйте что угодно в секции Script Injection из Большого список противных запросов (используйте blns.txt и начните с 268 строки) и посмотрите, что будет. Если вы увидите всплывающее окно Javascript – вы нашли XSS-уязвимость.


OWASP Top 10 - #7: Отсутствующий контроль доступа уровня функции

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

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

  1. Войдите как администратор, сделайте что-нибудь, что может сделать только администратор. Убедитесь, что изменения сохранены, и проверьте, что они применены, перед выходом из системы. Fiddler запишет информацию о вашей сессии.
  2. Теперь зайдите обычным пользователем, или походите по системе. Все, что вам на самом деле нужно – получить cookie обычного пользователя через Fiddler. Вам может понадобиться вход в систему для получения такой cookie, зависит от приложения.
  3. Теперь начинается веселуха. Перетащите форму администратора во вкладку Composer. Так вы увидите все отправленные поля. Вы хотите изменить данные формы, что-то очевидное – например, имя.
  4. Теперь перейдите в Inspector и выберите последний запрос обычного пользователя. Скопируйте cookie вашего обычного пользователя из вкладки Raw, и замените cookie в запросе Composer. Все готово к отправке!
  5. Отправьте ваш поддельный запрос из Composer, чтобы сохранить измененные данные в системе. Если сохранение правильно работает с авторизацией, изменений не будет. Получите вы ошибку или нет – зависит от приложения, главное, сохранятся ли данные. Если это произошло –ура! Вы нашли уязвимость, которая требует исправления.

Как рассказать разработчикам о своей находке

Я видела разные реакции – от «О нет, это надо исправить!» до «Как ты посмела технически вмешиваться в мой код!» - от разработчиков. Как сказать им, что в коде проблема? Зачастую это «не их код», потому что каждая система накапливает легаси-проблемы в процессе использования, но кто-то должен ее поддерживать, и де-факто за код отвечают разработчики. Многое тут зависит от того, насколько хороши вы как команда, насколько велика проблема, и сколько работы требуется, чтобы ее поправить.

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

На самом деле это не проблема!

Фраза, известная также, как «никто никогда так не сделает» и «что за хренью ты тут маешься?» Да, мы также известны, как «никто», потому что только что сделали «так».

Вам придется доказывать, что проблема присутствует, если вы получили такую реакцию, поэтому первый шаг – воспроизведение проблемы. Если придется, сделайте это несколько раз, под наблюдением разработчиков. Если они не могут посмотреть, то запись экрана сработает (для этого можно воспользоваться Jing).

Отсылки к OWASP top 10 и Information Security Stack Exchange тоже помогают.

Держите в уме, что на самом деле это действительно может быть не проблемой. Вы работаете на тестовом сайте, у которого есть уязвимости, о которых вы не в курсе, потому что сайт сделан более открытым для тест-задач. Это еще одна причина отправиться на Information Security Stack Exchange – есть шансы, что кто-то уже сделал то, что сделали вы, нашел то, что нашли вы, и имеет на руках решение или доказательство, что это не проблема (или проблема).

Это не произойдет на проде, потому что SSL

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

Я не хакер

Настал ваш звездный час для сопротивления. «Ну так и я не хакер, и если Я могу это сделать, хакер тем более сможет!»

Теперь что?

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

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

Ссылки и инструментарий для дальнейшего изучения

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

Сайты для информации и изучения

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

Information Security Stack Exchange – Тут вы найдете множество полезной информации. Ищите ответы на свои вопросы, и вы будете вознаграждены глубокими познаниями, найдя ответ. Или просто изучите информацию по тегу, который привлек ваше внимание. Здесь можно найти практически все, касающееся безопасности информации.

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

Troy Hunt's site – Трой Хант ведет отличный блог по безопасности с множеством дополнительной информации для тех, кому она необходима.

PCI Security Standards – Если вы тестируете приложение, принимающее кредитные карты, то этот сайт – ваш главный помощник.

Bill Sempf's site – Блог Билла Семпфа населен множеством ссылок на полезные ресурсы. Он также содержит интересные и доступные статьи об инструментах.

Инструменты для тестировщика

The Big List of Naughty Strings – Содержит отличную коллекцию строк, вызывающих проблемы в различных окружениях. Использовать с осторожностью, но использовать обязательно.

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

Fiddler – Мой личный друг для большей части тестирование на проникновение. Я получаю от него больше информации, чем от инструментов разработчика в браузере, и у меня больше контроля над данными, которыми я манипулирую.

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

Notepad++ - Это мой любимый текстовый редактор. К нему есть куча плагинов, включая шифровку/дешифровку URL, подсветку синтаксиса кода (которая делает чтение кода очень простым), и автоформатирование HTML и XML для простоты чтения.

Обсудить в форуме