Анализ защищенности Web-приложений, выявление уязвимостей в реальных условияхDmitry Evteev
Уязвимости и атаки на Web-приложения, общепринятые классификации уязвимостей. Ошибки, допускаемые разработчиками при создании клиентской и серверной частей Web-приложения, их возможные последствия и методы выявления и устранения. Примеры из практики. Обзор специализированных средств защиты Web-приложений: Web Application Firewall (WAF). Стоит ли полагаться на WAF?
Методология выявления уязвимостей в Web-приложениях, в частности, с использованием различных средств автоматического анализа.
Тестирование аварий. Андрей Губа. Highload++ 2015odnoklassniki.ru
В 2013 году случилась самая большая авария в истории Одноклассников: в течение трёх дней проект был целиком, а потом частично, неработоспособен. После того, как мы устранили последствия аварии, к нам пришел бизнес со следующим вопросом: какие проблемы видит технический отдел компании и какие варианты защиты может предложить. Сходу мы выделили три основных — взлом хакерами, DDoS-атаки и аварии. Взломы — не в плоскости конференции Highload, про DDoS-атаки — наоборот, рассказывают довольно часто. Поэтому в этом докладе мы поговорим именно про аварии.
Отказ диска или сервера мы давно не считаем аварией — у нас несколько тысяч серверов, и подобные сбои происходят по нескольку раз в день. Среди выделенных нами серьезных отказов — отказ канала связи до дата-центра, сбои электричества, перегрузка какой-то из подсистем, вызванная ростом какой-то активности (в т.ч. эксперименты), ошибка программиста/инженера и другие.
По каждому из перечисленных направлений мы проанализировали риски и провели ряд работ на портале, позволивший нашей системе успешно функционировать в условиях перечисленных выше проблем. Как и в программировании, мы решили, что тестирование — это отличный способ выявлять проблемы на ранних стадиях и ликвидировать их минимальными средствами. В презентации мы расскажем о том, как мы защищаемся от каждой из перечисленных выше угроз и сфокусируемся на техниках эмуляции аварийных ситуаций.
Cis critical security controls. контроль 3 безопасная конфигурация устройствTeymur Kheirkhabarov
3-ий контроль из набора мер CIS Critical Security Controls 6-ой версии - что это такое, зачем это нужно, как реализовать и контролировать. Пример реализации на базе решений Kaspersky, MaxPatrol и Request Tracker. Пример использования Request Tracker для учёта информационных активов.
ЄВГЕНІЙ ТОЛЧИНСКИЙ «Як manual QA може протестувати проект з боку security» QA...QADay
Kyiv Quality Assurance Day 2019
ЄВГЕНІЙ ТОЛЧИНСКИЙ
«Як manual QA може протестувати проект з боку security»
Телеграм канал: wwww.t.me/goqameetup
Фейсбук сторінці: www.fb.com/goqaevent
Сайт: www.kyiv.qaday.org
Доклад посвящен задаче сравнения эффективности сканеров веб-приложений в части обнаружения уязвимостей класса SQL Injection. В докладе будет изложена методика построения тестового покрытия, описана процедура проведения тестирования и анализа результатов. Будут приведены результаты тестирования таких известных сканеров, как sqlMap, skipfish, wapiti и acunetix.
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2957.html
Расскажем о нашем опыте разработки модуля межсетевого экрана для MySQL с использованием генератора парсеров ANTLR и языка Kotlin.
Подробно рассмотрим следующие вопросы:
— когда и почему целесообразно использовать ANTLR;
— особенности разработки ANTLR-грамматики для MySQL;
— сравнение производительности рантаймов для ANTLR в рамках задачи синтаксического анализа MySQL (C#, Java, Kotlin, Go, Python, PyPy, C++);
— вспомогательные DSL;
— микросервисная архитектура модуля экранирования SQL;
— полученные результаты.
This document discusses exploiting vulnerabilities related to HTTP host header tampering. It notes that tampering with the host header can lead to issues like password reset poisoning, cache poisoning, and cross-site scripting. It provides examples of how normal host header usage can be tampered with, including by spoofing the header to direct traffic to malicious sites. The document also lists some potential victims of host header attacks, like Drupal, Django and Joomla, and recommends developers check settings to restrict allowed hosts. It proposes methods for bruteforcing subdomains and host headers to find vulnerabilities.
This document discusses security issues with Samsung Smart TVs from 2008-2014. It finds that the Smart TVs run apps in an insecure manner: 1) Apps can access and steal files from other apps due to lack of sandboxing. 2) Bugs like XSS have high impact as apps can access low-level device APIs. 3) Apps do not properly secure secret data due to using an insecure file:// protocol. The document encourages developers to design apps with security in mind and users to only install trusted apps.
The document discusses various techniques for hacking APIs, including bypassing restrictions, parameter tampering, ZIP bombs, JavaScript attacks, cryptographic attacks like length extension and request hijacking, and XML injection attacks. It provides examples of specific API vulnerabilities and recommends thoroughly testing APIs for issues like these by evaluating logic, restrictions, specific file types and encodings, and ensuring proper validation of inputs.
The document profiles Sergey Belov and discusses his background as a pentester, writer, and bug bounty hunter. It then outlines some potential ways Nginx could be used for MitM/phishing attacks, including modifying requests through reverse proxies and DNS rebinding to target internal resources. The document cautions that additional steps like DNS poisoning would be needed and that the techniques carry instability risks and should be removed from security reports.
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
Автотесты и безопасность