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

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

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