1. Как начать тестировать безопасность уже
сегодня
Сергей Белов
Mail.Ru Group
QA MeetUp - 6 июля, Нижний Новгород
2. Intro
Ситуация:
1) У вас есть web приложение
2) Вы для него уже пишете автотесты
3) Но никто не тестирует безопасность
Задача:
Начать тестировать безопасность :)
3. Как вообще происходит поиск уязвимостей?
1) Анализ приложения и бизнес логики
2) Сбор параметров для взаимодействия (Client Side - javascript sinks &
sources / Server side - HTTP)
3) Отправка неожидаемых данных, которые могут: изменить чужие данные,
нарушить конфиденциальность, вызвать отказ в обслуживании
4. Что мы сделаем сегодня
1) Изучим 6 видов уязвимостей
2) Возьмем готовые автотесты
3) Превратим их в сканер безопасности
6. Insecure Direct Object References (IDOR)
Позволяет получить доступ к объектам (каким-то данным) из-за проблем
ACL.
1) https://example.com/document/123 - документ пользователя A
2) https://example.com/document/124 - документ пользователя B
Проблема возникает на моменте, когда пользователь A, узнав
(подобрав) ID документа пользователя B, может получить к нему доступ
(чтение/редактирование/удаление).
7. Как внедрить такие проверки в автотесты?
1) После сохранения / добавления данных запрашивать не ID объекта в
ответе, а объект другого пользователя (заранее его захардкодив)
2) Брать список объектов пользователя A и запрашивать их под сессией
(кукой) пользователя B
Так же это могут быть не только объекты, а просто страницы (делаем
“паука” на сбор ссылок - обходим под другой сессией)
Insecure Direct Object References (IDOR)
9. 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>
10. Cross Site Scripting (XSS)
Самые частые "опасные” символы:
● "
● '
● <
● >
Задача сводится к тому, чтобы матчить текущий паттерн + спецсимволы
11. Cross Site Scripting (XSS)
Текущий юзкейс:
1. Задать имя пользователя John
2. expect: john
Новый юзкейс:
1. Задать имя пользователя John<
2. expect: john<
13. SQL injection
Обычный кейс:
http://example.com/news?id=1(select * from news where id = '1')
Автотест подставляет: 1
Кейс с проверкой 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. 1) Проверяем атаки "повтора" - берем одноразовые токены (смс код, токен
для перевода денег и т.п.) и отправляем несколько раз
2) Работа с сессиями - берем cookies и:
a) меняем пароль
b) включаем двухфакторку
c) выходим из аккаунта
d) специфичные кейсы: частичная смена IP / User-Agent / страны и т.п.
Проверяем, что сессия более не валидна
3) Пытаемся придумать тесткейсы на время жизни сессии
Время жизни токенов и сессий
19. Много (>100) раз повторяем запрос на действие и пытаемся:
1) Заспамить другого юзера (отправка приглашений на почту)
2) Возможно потратить деньги сервиса (отправка смс, звонки)
3) Вызвать отказ в обслуживании ("тяжелые" запросы - конвертация
изображений и т.п.)
Тестирование рейтлимитов
20. Плюсы:
● Сокращение времени на изучение функционала
● Большое покрытие
● Внедрение в CI
● Простое тестирование protocol specific мест
Минусы:
● Не найдем логические и “сложные” уязвимости
● Не протестируем уязвимости платформы, библиотек, фреймворков
● На начальных этапах - большое количество false positive срабатываний
Security Testing Web Applications throughout Automated Software Tests (2006) -
https://www.owasp.org/images/9/99/AutomatedSecurityTestingofWebApplications-StephendeVries.pdf
Автотесты и безопасность