Небезопасный AppCache

AppCache безопасность

Механизм AppCache позволяет веб-приложениям кешировать ресурсы в локальном хранилище вашего браузера. Это дает им возможность взаимодействовать с вами даже в автономном режиме. Но когда через AppCache кешируются кросс-доменные ресурсы, возникает серьезный риск утечки конфиденциальных данных. Давайте разберемся, как и почему это происходит.

Еще по теме: Самые популярные эксплойт-паки

Cross-Origin Resource Status Identification Attack

Суть Cross-Origin Resource Status Identification Attack заключается в идентификации статуса кросс-доменных ресурсов посредством злоупотребления манифестом AppCache: URL существует, редирект, ошибка.

Cross-Origin Resource Status Identification Attack схож с CSRF. Выполняя Cross-Origin Resource Status Identification Attack, злодей стремится заполучить твою конфиденциальную информацию, косвенно хранящуюся в браузере. Для этого ему нужно, чтобы вы посетили его сайт, страницы которого слегка вредоносны.

Пример манифеста AppCache
Пример манифеста AppCache

И когда я говорю «слегка», я имею в виду, что они практически безобидны. На них нет и намека на эксплоиты, которые могли бы помочь злоумышленнику заполучить контроль над вашим браузером. Но эти слегка зараженные страницы содержат вполне допустимые теги HTML и скрипты для инклудинга кросс-доменного контента. Идентифицировать злонамеренное поведение такого вредоносного сайта возможно, но очень сложно.

Механизм CORS используется в современных браузерах и позволяет предоставлять веб-странице доступ к ресурсам другого домена.

Чем опасен Cross-Origin Resource Status Identification

Злодей может использовать базовую версию Cross-Origin Resource Status Identification Attack, чтобы определить, сохранен ли в вашем браузере логин и пароль веб-приложения. Часто, когда вы заходите на свою личную страницу, то или иное приложение делает условный редирект: если в браузере нет логина и пароля, то происходит редирект на страницу залогинивания, а если есть, то не происходит.

Вот несколько популярных сайтов, которые работают по такому принципу.

Личная страница Условный редирект
https://www.amazon.com/gp/wallet?ie=UTF8&ref_=ya_wallet https://www.amazon.com/ap/signin?…
http://my.ebay.com/ws/eBayISAPI.dll?MyeBay https://signin.ebay.com/ws/eBayISAPI.dll?SignIn…
https://instagram.com/accounts/edit/ https://instagram.com/accounts/login/?next=/accounts/edit/
https://sourceforge.net/projects/filezilla/reviews/new https://sourceforge.net/account/login.php?return_to=…
http://www.tumblr.com/dashboard https://www.tmblr.com/login?redirect_to=/dashboard
http://wordpress.com/post/ http://wordpress.com/wp-login.php?redirect_to=…
https://www.yelp.com/profile_bio https://www.yelp.com/login?retun_url=/profile_bio
http://www.youtube.com/feed/subscriptions https://accounts.google.com/ServiceLogin?…

Если в браузере есть логин и пароль для конкретного веб-приложения, то процедура кеширования соответствующего URL проходит успешно, потому что редирект не выполняется. Если же логина и пароля нет, то процедура кеширования завершается неудачей. Поэтому, наблюдая за тем, где процедура AppCache оканчивается успехом, а где неудачей, хакер может узнать, для каких веб-приложений в вашем браузере логин и пароль сохранены, а для каких нет. Благодаря этому он может узнать, есть ли у вас доступ к приватным страницам конкретных компаний, университетов, социальных сообществ.

Кроме того, зондируя адреса URL вроде тех, что представлены ниже, посторонний человек может установить вашу личность — если ваш идентификатор присутствует в его списке.

  • https://bitbucket.org/account/user/<user-id>
  • https://github.com/<user-id>//settings
  • http://stackovertlow.com/users/edit/<user-id>
  • http://twitpic.com/media/edit/Location/<photo-id>
  • http://<blog-id>.wordpress.com/wp-admin
  • https://ndss2015.ccs.neu.edu/paper/<paper-no>

Злоумышленик может определить сферы ваших предпочтений, наблюдая за тем, на кого вы подписаны в социальных сетях и в каких группах вы состоите. Рассмотрим напоследок такие популярные платформы, как Tumblr и Flickr.

Когда ваш браузер, находясь под Cross-Origin Resource Status Identification Attack, посещает http://www.tumblr.com/follow/<blog-id>, злоумышленик узнает, подписаны ли вы на блог с идентификатором <blog-id>. Каким образом? Отслеживая факт редиректа. Если вы подписаны на этот блог, ваш браузер сделает редирект на http://www.tumbler.com/unfollow/<blog-id> и, соответственно, процесс AppCache завершится неудачей.

Аналогично можно узнать, в каких группах вы состоите на Flickr. Если вы пройдете по URL http://www.flickr.com/groups_leave.gne?id=<group-id>, хакер узнает, являетесь ли вы членом группы с идентификатором <group-id>. Если нет, ваш браузер сделает редирект на http://www.fiickr.com/groups/<group-id>, а если да, то редирект не произойдет.

Уникальные особенности

  1. Cross-Origin Resource Status Identification Attack может извлекать вашу конфиденциальную информацию без использования вредоносных скриптов, плагинов и CSS. Атака реализуется при помощи простейшего документа HTML, в манифесте AppCache которого указывается зондируемый URL. Cross-Origin Resource Status Identification Attack успешно преодолевает традиционные средства безопасности, вроде NoScript, поскольку отключение подозрительных скриптов и плагинов ей не препятствует.
  2. Cross-Origin Resource Status Identification Attack может одновременно идентифицировать статус сразу нескольких адресов URL. Это для злоумышленника очень важно. Потому что он всегда стремится выведать ваши секреты как можно быстрее, поскольку знает, что вы, скорее всего, не задержитесь на его странице надолго. Традиционные атаки подобного рода основаны на таймингах, поэтому не могут одновременно зондировать сразу несколько URL. Параллельные запросы HTTP и HTTPS приводят к ошибкам синхронизации. Атака Cross-Origin Resource Status Identification функционирует, не полагаясь на тайминг, и поэтому может параллельно зондировать сразу несколько URL.
  3. Также эта атака может отслеживать редиректы. Традиционные атаки подобного рода, основанные на таймингах, такой возможности не имеют, поскольку для зондирования статуса URL опираются на теги вроде <img>, <script> и <link>, которые совершают редирект прозрачно для пользователя.

Почитать подробнее о таймингах можно тут, тут и тут.

Модификации базовой атаки

Атака с использованием скрипта

Если, обрабатывая список адресов URL, перечисленных в манифесте AppCache, ваш браузер встречает хотя бы один некешируемый, он генерирует событие error. Так злоумышленник узнает, есть ли среди этих URL хотя бы один некешируемый: если скрипт дождался этого события — как минимум один такой URL есть.

Скрипт для зондирования кешируемости URL
Скрипт для зондирования кешируемости URL
В AppCache не кешируются следующие три типа URL: недействительные, динамические, с редиректами.

Атака без использования скрипта

  1. Когда вы заходите через браузер на вредоносную страницу, которая злонамерилась провести против вас атаку Cross-Origin Resource Status Identification, страница фиксирует информацию о вашем браузере.
  2. Ваш браузер скачивает манифест AppCache и извлекает из него URL.
  3. Далее ваш браузер пытается получить доступ к этому URL.
  4. Если обращение к этому URL увенчалось успехом, ваше браузер повторно скачивает манифест, чтобы проверить, не было ли изменений.
Последовательность шагов для действительного URL
Последовательность шагов для действительного URL

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

Последовательность шагов для недействительного URL
Последовательность шагов для недействительного URL

На основе различий на этом четвертом шаге злодей делает вывод, может ли ваш браузер кешировать URL, указанный в манифесте.

Параллельная атака по нескольким URL

Поскольку атака Cross-Origin Resource Status Identification Attack не зависит от таймингов, как традиционные атаки подобного рода, злоумышленник может одновременно зондировать сразу несколько URL, используя для этого несколько веб-страниц и манифестов AppCache, находящихся в нескольких тегах <iframe>.

Параллельная атака по нескольким URL
Параллельная атака по нескольким URL

Главная страница атаки attack_all.php содержит несколько скрытых тегов <iframe>, каждый из которых указывает на страницу субатаки attack_each.php. Обратите внимание, целевые адреса URL здесь передаются через GET.

attack_all.php
attack_all.php
attack_each.php
attack_each.php

Каждая страница субатаки объявляет свой собственный манифест — manifest.php.

manifest.php
manifest.php

Наконец, каждый из этих манифестов указывает в разделе CACHE тот самый URL, который надо зондировать.

Скорость атаки зависит от браузера. В Chrome, Internet Explorer и Opera она выполняется довольно резво, поскольку в них манифесты AppCache обрабатываются параллельно. Тогда как Firefox обрабатывает манифесты последовательно. Например, на компьютере средней конфигурации параллельная атака на двести страниц занимает в браузерах Chrome и Opera 0,11 секунды, в Internet Explorer — 0,27 секунды, в Firefox — 0,95 секунды.

Выводы

Теперь вы знаете, как при помощи AppCache злоумышленник может извлекать вашу конфиденциальную информацию, косвенно хранящуюся в браузере. Лишить его такой возможности очень непросто. Радует только то, что механизм AppCache со временем постепенно утрачивает свою популярность.

Еще по теме: Как работает DNS over HTTPS и нужен ли он вам?

ВКонтакте
OK
Telegram
WhatsApp
Viber

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *