CodeFest 2019. Сергей Белов (Mail.Ru Group) — Превращаем автотесты в тесты безопасности

16b6c87229eaf58768d25ed7b2bbbf52?s=47 CodeFest
April 05, 2019

CodeFest 2019. Сергей Белов (Mail.Ru Group) — Превращаем автотесты в тесты безопасности

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

16b6c87229eaf58768d25ed7b2bbbf52?s=128

CodeFest

April 05, 2019
Tweet

Transcript

  1. Превращаем автотесты в тесты безопасности Сергей Белов Руководитель команды продуктовой

    безопасности Mail.Ru Group
  2. CodeFest 2012 - Пентест на стероидах. Автоматизируем процесс 2014 -

    BlackBox тестирование безопасности клиент-серверного API 2016 - Расширяем инструментарий — тулзы пентестеров в разработке и тестировании 2019 - Превращаем автотесты в тесты безопасности 2
  3. Интро Ситуация: 1) У вас есть web/mobile приложение 2) Вы

    для него уже пишете автотесты 3) Но никто не тестирует безопасность Задача: Начать тестировать безопасность 3
  4. Что мы сделаем сегодня 1) Изучим 6 видов уязвимостей 2)

    Возьмем готовые автотесты 3) Превратим их в сканер безопасности (хотя бы попробуем ) 4
  5. Как происходит поиск уязвимостей? 1) Анализ приложения и бизнес логики

    2) Сбор параметров для взаимодействия (Client Side - javascript sinks & sources / Server side - HTTP) 3) Отправка неожидаемых данных, которые могут: изменить чужие данные, нарушить конфиденциальность, вызвать отказ в обслуживании 5
  6. Insecure Direct Object References (IDOR) 6

  7. IDOR Позволяет получить доступ к объектам (каким-то данным) из-за проблем

    ACL. 1) https://example.com/document/123 - документ пользователя A 2) https://example.com/document/124 - документ пользователя B Проблема возникает на моменте, когда пользователь A, узнав (подобрав) ID документа пользователя B, может получить к нему доступ (чтение/редактирование/удаление). 7
  8. IDOR Как внедрить такие проверки в автотесты? 1) После сохранения

    / добавления данных запрашивать не ID объекта в ответе, а объект другого пользователя (зашив его заранее) 2) Брать список объектов пользователя A и запрашивать их под сессией пользователя B Так же это могут быть не только объекты, а просто страницы (делаем “паука” на сбор ссылок - обходим под другой сессией) 8
  9. https://hackerone.com/reports/328337

  10. Cross Site Scripting (XSS) 10

  11. Cross Site Scripting (XSS) Злоумышленник внедряет javascript код и исполняет

    его в браузере жертвы (доступ к DOM / временным хранилищам - cookies / local storage / etc). Примеры: - Привет, <script>alert(1)</script> - Смотри фото <img src="/pic.png" onload="alert(1)"> - <script> var name = 'Username'+alert(1)+''; </script> 11
  12. Cross Site Scripting (XSS) Самые частые "опасные” символы: • "

    • ' • < • > Задача сводится к тому, чтобы матчить текущий паттерн + спецсимволы 12
  13. Cross Site Scripting (XSS) Текущий юзкейс: 1. Задать имя пользователя

    John 2. expect: john Новый юзкейс: 1. Задать имя пользователя John< 2. expect: john< 13
  14. https://hackerone.com/reports/360787

  15. SQL injection 15

  16. Обычный кейс: http://example.com/news?id=1 Где-то в базе данных: select * from

    news where id = '1' Автотест использует значение: 1 SQL injection 16
  17. SQL injection Кейс с проверкой sql injection: http://example.com/news?id=-1' or sleep(5)

    -- Где-то в базе данных: select * from news where id = '-1' or sleep(5) -- ' Автотест использует значение: -1' or sleep(5) -- Если время ответа более 5 секунд - возможно есть уязвимость 17
  18. Template injection 18

  19. Template injection Обычный кейс: testValue = John Кейс проверки template

    injection: testValue = John{{7*7}} Уязвимость есть: John49 Уязвимость нет: John{{7*7}} 19
  20. https://hackerone.com/reports/125980

  21. Время жизни токенов и сессий 21

  22. Время жизни токенов и сессий 1) Проверяем атаки "повтора" -

    берем одноразовые токены (смс код, токен для перевода денег и т.п.) и отправляем несколько раз 2) Работа с сессиями - берем cookies и: a) меняем пароль b) включаем двухфакторку c) выходим из аккаунта d) специфичные кейсы: частичная смена IP / User-Agent / страны и т.п. Проверяем, что сессия более не валидна 3) Пытаемся придумать тесткейсы на время жизни сессии 22
  23. Тестирование рейтлимитов 23

  24. Тестирование рейтлимитов Много (>100) раз повторяем запрос на действие и

    пытаемся: 1) Заспамить другого юзера (отправка приглашений на почту) 2) Возможно потратить деньги сервиса (отправка смс, звонки) 3) Вызвать отказ в обслуживании ("тяжелые" запросы - конвертация изображений и т.п.) 24
  25. Сразу учитывать все кейсы при написании автотестов + Очень эффективный

    способ - Старые автотесты никто не перепишет :) Подходы к автоматизации 25
  26. Проксирование автотестов - Модуль логирования - прокси, сохраняет все запросы

    - Модуль поиска уязвимостей - берет запросы и пытается подменить параметры. Хорошо подходит для поиска IDOR, SSRF уязвимостей Автотесты и безопасность 26
  27. Автотесты и безопасность 27 Плюсы: • Сокращение времени на изучение

    функционала • Большое покрытие • Внедрение в CI • Простое тестирование protocol specific мест
  28. Автотесты и безопасность 28 Минусы: • Не найдем логические и

    “сложные” уязвимости • Не протестируем уязвимости платформы, библиотек, фреймворков • На начальных этапах - большое количество false positive срабатываний
  29. Конкурс https://codefest.sergeybelove.ru 1 место - подписка на 3 месяца 2,

    3 место - подписка на 1 месяц 29
  30. @sergeybelove Сергей Белов Руководитель команды продуктовой безопасности Mail.Ru Group Вопросы?

    @sergeybelove sergeybelove.ru s.belov@corp.mail.ru