Sergey Gordeychik, Application Security in real word
- 3. Регулятивные требования PCI DSS Требования к наличию защитных механизмов (аутентификация, разграничение доступа, шифрование) Требования к качеству реализации (отсутствие уязвимостей OWASP top 10) Отдельный стандарт для платежных систем PA DSS 152 ФЗ «О персональных данных» В рамках «Четырехкнижия» выдвигаются требования к защитным механизмам Идентификация и аутентификация пользователей Управление доступом на уровне прикладных сущностей Регистрация событий на уровне прикладных сущностей Сертификация и аттестация В Риме веди себя как римлянин
- 7. Пример : атака на Heartland Payment Systems «США против Гонзалеса и сообщников»
- 8. Сценарий Изучив компании из « Top 500 », обнаружили уязвимости класса SQL Injection на Web- серверах трех из них С помощью SQL- инъекции получили контроль над несколькими серверами, установили руткиты Получили доступ к ключевым компонентам инфраструктуры, установили сниферы Арендовали Web- серверы в 6 регионах, на которые автоматически закачивались данные магнитной полосы и PIN- блоки Схема действовала с октября 2006 г. по май 2008 г. Было скомпрометировано 130,000,000 карт. Несмотря на предупреждения о возможном фроде, HPS признала утечку и оповестила клиентов только в январе 2009 Это самая масштабная утечка, по ее итогам HPS была «задним числом» признана не соответствующей PCI DSS
- 9. PR, MC & Business Демонстрация серьезного отношения к заказчику Удержание рынка Выход на новые рынки
- 10. PR, MC & Business NetCraft Market Share for Top Servers Авторитетная аналитическая компания призывает всех незамедлительно отказаться от использования веб-серверов Microsoft. В них столько ошибок, что это представляет реальную опасность 25 сентября 2001 года, 15:45 | Текст: К. Т.
- 11. Just for FUN Как правило, занимаются «чужой» безопасностью Исследователи, Аудиторы / пентестеры Злобные хакеры dud3 1'm g0nn@ +0 HaX0r J00r s1+E! MuH@Ha!
- 13. Безопасное Web- приложение Все очень, очень и очень тривиально… Проектирование Разработка Поддержка
- 14. Проектирование Две задачи Выбор необходимых функций безопасности (защитных механизмов) Проектирование функций безопасности с учетом требований безопасности Классический пример – ГОСТ /ISO 15408 (Common Criteria) Часть 2. Функциональные требования безопасности Часть 3. Требования доверия к безопасности
- 15. Проектирование - Учет требований безопасности Наличие функций безопасности Нужна ли мне аутентификация… … протоколирование… … разграничение доступа… Отсутствие функций безопасности может являться уязвимостью OWASP top 10 (2004) A8 2004 Insecure Storage WASC WSTCv2 Insufficient Authentication Insufficient Authorization
- 16. Проектирование - Источники Отраслевые / государственные и международные стандарты PCI DSS PA DSS 152 «ФЗ» - «Четырехкнижие» … … Таксономии и классификации OWASP top 10 (2004) WASC WSTCv2 CWE
- 17. OWASP TOP 10 A1 - Cross Site Scripting (XSS) A2 - Injection Flaws A3 - Malicious File Execution A4 - Insecure Direct Object Reference A5 - Cross Site Request Forgery (CSRF) A6 - Information Leakage and Improper Error Handling A7 - Broken Authentication and Session Management A8 - Insecure Cryptographic Storage A9 - Insecure Communications A10 - Failure to Restrict URL Access http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project Больше ориентирован на разработку
- 18. Web Application Security Consortium WSTCv2 http://projects.webappsec.org/Threat-Classification-Working http://www.webappsec.org/projects/threat/ Две группы: уязвимости и атаки. Наиболее полное описание проблем безопасности Web- приложений
- 19. Common Weakness Enumeration http://cwe.mitre.org/ Исчерпывающее описание уязвимостей и атак Различные взгляды на данные – для разработчиков, исследователей…
- 20. Разработка – реализация требований безопасности Наиболее распространенный источник проблем Недостаточная информированность разработчиков Ошибки Недостаточное тестирование Как решать? Внедрение Secure SDLC Тестирование, тестирование, тестирование
- 21. Разработка – Тестирование OWASP Application Security Verification Standards (ASVS) http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project На практике: Сканеры Черный ящик /Pentest Белый ящик
- 23. Поддержка – поддержание защищенного состояния Whitehat Security Фактическое устранение уязвимостей
- 24. Поддержка – уязвимости после «запуска» приложения Заказчик А что это такое? Договор на поддержку включает устранение уязвимостей? Кто вообще писал этот код? Разработчик Это не уязвимость! Что это за письмо? Шантаж?!
- 25. Поддержка – вовлеченные стороны Разработчик Получает информацию об уязвимостях Планирует устранение Устраняет Информирует заказчиков Исследователь Обнаруживает уязвимости Информирует разработчика / заказчика Помогает устранять Заказчик (Владелец / Пользователь) Ждет милости ? Включаем Web Application Firewall
- 26. Устранение уязвимостей – попытки формализации “ Full Disclosure Policy (RFPolicy) v2.0”, Rain Forest Puppy http://www.wiretrip.net/rfp/policy.html Steven M. Christey and Chris Wysopal. “Responsible Vulnerability Disclosure Process (Internet-Draft RFC).” http://www.vulnwatch.org/papers/draft-christey-wysopal-vuln-disclosure-00.txt Organization for Internet Safety. “Guidelines for Security Vulnerability Reporting and Response, Version 2.0.” http://www.oisafety.com/guidelines/secresp.html NIAC, “Vulnerability Disclosure Framework”, http://www.dhs.gov/interweb/assetlibrary/vdwgreport.pdf