Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Как начать тестировать безопасность уже сегодня

270 views

Published on

https://www.youtube.com/watch?v=JbtIoA3k5zA

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Как начать тестировать безопасность уже сегодня

  1. 1. Как начать тестировать безопасность уже сегодня Сергей Белов Mail.Ru Group QA MeetUp - 6 июля, Нижний Новгород
  2. 2. Intro Ситуация: 1) У вас есть web приложение 2) Вы для него уже пишете автотесты 3) Но никто не тестирует безопасность Задача: Начать тестировать безопасность :)
  3. 3. Как вообще происходит поиск уязвимостей? 1) Анализ приложения и бизнес логики 2) Сбор параметров для взаимодействия (Client Side - javascript sinks & sources / Server side - HTTP) 3) Отправка неожидаемых данных, которые могут: изменить чужие данные, нарушить конфиденциальность, вызвать отказ в обслуживании
  4. 4. Что мы сделаем сегодня 1) Изучим 6 видов уязвимостей 2) Возьмем готовые автотесты 3) Превратим их в сканер безопасности
  5. 5. Insecure Direct Object References (IDOR)
  6. 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. 7. Как внедрить такие проверки в автотесты? 1) После сохранения / добавления данных запрашивать не ID объекта в ответе, а объект другого пользователя (заранее его захардкодив) 2) Брать список объектов пользователя A и запрашивать их под сессией (кукой) пользователя B Так же это могут быть не только объекты, а просто страницы (делаем “паука” на сбор ссылок - обходим под другой сессией) Insecure Direct Object References (IDOR)
  8. 8. Cross Site Scripting (XSS)
  9. 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. 10. Cross Site Scripting (XSS) Самые частые "опасные” символы: ● " ● ' ● < ● > Задача сводится к тому, чтобы матчить текущий паттерн + спецсимволы
  11. 11. Cross Site Scripting (XSS) Текущий юзкейс: 1. Задать имя пользователя John 2. expect: john Новый юзкейс: 1. Задать имя пользователя John< 2. expect: john<
  12. 12. SQL injection
  13. 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 секунд - возможно есть уязвимость
  14. 14. Template injection
  15. 15. Обычный кейс: testValue = John Кейс проверки template injection: testValue = John{{7*7}} Уязвимость есть: John49 Уязвимость нет: John{{7*7}} Template injection
  16. 16. Время жизни токенов и сессий
  17. 17. 1) Проверяем атаки "повтора" - берем одноразовые токены (смс код, токен для перевода денег и т.п.) и отправляем несколько раз 2) Работа с сессиями - берем cookies и: a) меняем пароль b) включаем двухфакторку c) выходим из аккаунта d) специфичные кейсы: частичная смена IP / User-Agent / страны и т.п. Проверяем, что сессия более не валидна 3) Пытаемся придумать тесткейсы на время жизни сессии Время жизни токенов и сессий
  18. 18. Тестирование рейтлимитов
  19. 19. Много (>100) раз повторяем запрос на действие и пытаемся: 1) Заспамить другого юзера (отправка приглашений на почту) 2) Возможно потратить деньги сервиса (отправка смс, звонки) 3) Вызвать отказ в обслуживании ("тяжелые" запросы - конвертация изображений и т.п.) Тестирование рейтлимитов
  20. 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 Автотесты и безопасность
  21. 21. Тестируйте безопасность! @sergeybelove s.belov@corp.mail.ru

×