CC BY
59
Иващенко А.В., Орлов А.Ю. ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ ПРИ РЕАЛИЗАЦИИ ОНЛАЙН БРАУЗЕРА
Аннотация: В статье рассмотрены основные аспекты реализации онлайн браузера - новой парадигмы
совместной навигации по сети Интернет. Перечислены основные узкие места в безопасности, вызванные использованием метода проксирования просматриваемых страниц, а также пути, позволяющие повысить безопасность использования онлайн браузера.
Одной из наиболее современных тенденций развития сети Интернет является широкое использование социальных сетей для объединения пользователей по интересам. Хорошо известны такие ресурсы как, как Flickr, Youtube, LiveJournal, LinkedIn, Facebook, а также их отечественные аналоги Яндекс.Фотки, RuTube, ВКонтекте и многие другие. Сами по себе социальные сети являются частным случаем другого, давно исследуемого феномена - виртуальных сообществ - который существует в контексте разнообразных телекоммуникационных технологий, однако наибольшее развитие получает в сети Интернет.
В 2008 году ожидается появление новых социальных сервисов и пользователей, увлеченных web 2.0 [1]. Несмотря на появление mashup'ов, призванных связать множественные социальные сети [2, 3], актуальной остается проблема интеграции информации из множества социальных сервисов, в которых зарегистрировать пользователь в одной, легкодоступной системе. Вместе с этим весьма популярно в сети Интернет новое увлечение «продвинутой» молодежи: совместная навигация по сети [4]. Эта концепция включает в себя возможности:
видеть, на каких страницах находятся друзья пользователя;
видеть, какую активность они совершают на этих страницах (если система поддерживает), например, когда они комментируют блок страницы;
возможность «приклеиться» и следовать в процессе навигации за другом;
и, конечно же, в реальном времени общаться с друзьями голосом (посредством VoIP) или в системе чата.
Концепция совместной навигации реализуется путем использования новых социальных браузеров [5] или установкой дополнительной функциональности (плагинов) к обычным браузерам [6]. В качестве альтернативы этому подходу выступают онлайн браузеры [7, 8]. Фактически онлайн браузер является кроссплат-
форменным Интернет приложением, являющимся «браузером внутри браузера». Одним из таких онлайн браузеров является система Browzmi [7] , которая может быть использована и для организации и управления виртуальными сообществами сети Интернет (см. рис. 1).
Система Browzmi позволяет пользователям сети просматривать различные сайты: для этого есть своя адресная строка и кнопки управления навигацией, а также панель поиска. Слева сгруппированы персональные для пользователя виджеты под общим названием My Stuff. Расположенные справа виджеты сгруппированы под общим названием More Stuff: они так или иначе связаны с просматриваемой страницей (комментарии о текущей странице, фотографии по тематике просматриваемой страницы и т.п.).
Рассмотрим особенности реализации онлайн браузера и связанные с ними задачи обеспечения безопасности. Для построения онлайн браузера требуется решить задачу отслеживания страницы, на которой находится пользователь. Это позволяет строить сервисы «вокруг» процесса навигации. Анализ доступных средств (HTML, CSS, JavaScript) приводит к выводу, что самым простым и эффективным механизмом является загрузка запрашиваемой страницу в независимый фрейм - элемент IFRAME страницы приложения.
К сожалению, ограничения браузера не позволяют скриптам на странице приложения обращаться к странице (в том числе только для получения ее локации), загруженной с другого домена. Для решения этой проблемы все отображаемые в системе страницы пропускаются через специальный http прокси сервис, являющийся также частью онлайн браузера. Соответственно, введена следующая структура доменов: зарегистрирован базовый домен второго уровня browzmi.com;
интерфейс системы загружается с поддомена www.browzmi.com. В процессе загрузки выполняется скрипт, который выставляет активный домен страницы (свойство document.domain) в browzmi.com;
все просматриваемые страницы грузятся с поддомена go.browzmi.com в html элемент iframe, входящий в страницу интерфейса. Именно этот элемент является областью просмотра страниц для пользователя. Настоящий адрес загруженных страниц выглядит следующим образом:
http://go.browzmi.com/www.google.com/ig/, исходный адрес загружаемой страницы записан в виде пути на proxy домене. В обязанности проксирующего сервиса входит добавление в код страницы элемента script, приводящего домен документа к домену верхнего уровня (browzmi.com).
После приведения эффективных доменов на обеих страницах к одному значению код на них получает доступ друг к другу. Но в обязанности прокси сервера входят и другие задачи:
Модификация всех ссылок и адресов элементов FORM, встречаемых на странице. Все они должны загружать страницы с сервера go.browzmi.com, для того чтобы, пройдя по ссылке, пользователь продолжал видеть URL страницы в интерфейсе онлайн браузера и мог совершать со страницей контекстные действия.
Ссылки на картинки и flash объекты, встречаемые на странице, модифицируются на абсолютные. Это снижает ненужную нагрузку по трафику с прокси сервиса и позволяет использовать domain balancing механизмы, заложенные создателями сайтов для параллельной и быстрой загрузки ресурсов, требуемых страницей.
Все элементы SCRIPT, STYLE, LINK, входящие в страницы, тоже модифицируются. Система вынуждена модифицировать Javascript и CSS, пропуская их через свой сервер.
Внутри CSS меняются все ссылки на внешние картинки (оформленные в виде url(link-to-image)).
К Javascript применяются характерные для конкретной страницы поправки. Они восстанавливают функциональность ссылок, генерируемых внутри скрипта.
Для корректной работы XMLHttpResponse объекта внутри браузера Firefox после модификации свойства document.domain [9] создан объект-оболочка, эмулирующий XHR вызовы.
Рассмотрим практические аспекты проблем безопасности при реализации онлайн браузера.
С целью ограничения доступа незарегистрированных пользователей к сервису проксирования система авторизации проверяет наличие специальной сессионной cookie, присылаемой браузером пользователя. Область видимости данной cookie установлена в .browzmi.com. Соответственно, браузер пользователя посылает ее и при запросах как к www. поддомену, так и к go. поддомену.
Перечислим возможные уязвимости нашего подхода:
Скрипт на загружаемой странице может пытаться детектировать факт загрузки внутри онлайн-браузера и препятствовать этому.
Атакующий скрипт после открытия доступа к родительскому фрейму приложения может менять его внешний вид, встраивать вредоносный код в код приложения.
Атакующий скрипт может прочитать авторизационные сессионные cookie пользователя и послать на свой сайт посредством технологии AJAX. После этого атакующая сторона сможет зайти в систему под видом атакованного пользователя.
Рис. 2. Схема работы онлайн браузера
При просмотре страниц по протоколу HTTPS прокси сервис в целях простоты реализации не транслирует оригинальный сертификат в браузер пользователя, а показывает свой сертификат. Таким образом, пользователь, единожды приняв сертификат онлайн браузера, более не видит сообщение от своего браузера о навигации на очередной сайт, защищенный своим сертификатом.
Для показа информации о странице в системе (в основном для реализации сервиса присутствия) на сервер посылается значение элемента TITLE просматриваемого URL. В случае если в заголовке страницы находится приватная информация (этим грешат страницы просмотра личных сообщений внутри социальной сети Facebook), эта информация будет видна другим пользователям.
Для предотвращения возможных атак и прочих уязвимостей в приложении реализованы следующие меры:
Кроме основной сессионной cookie, отправляемой как на www., так и на go. поддомены введена ещё одна, ограниченная по области видимости доменом www.browzmi.com. Авторизация доступа к основному приложению производится, соответственно, только при наличии в запросе обоих сессионных cookie записей. Т.е. имея обычную сессионную cookie, которую атакующий сайт может несложно узнать (с применением технологии AJAX прочитать на клиентской стороне свойство document.cookie) , он не сможет получить доступ к основной функциональности приложения.
Так как открыт доступ к взаимодействию между страницей приложения и страницей, прошедшей proxy сервер, атакующий сайт может выполнить скрипт и прочитать значение дополнительной сессионной cookie, прочитав свойство document.cookie родительского фрейма. Для предотвращения такого несанкционированного доступа, а также устранения возможности видоизменять вид приложения атакующим скриптом предлагается применить pull-метод со стороны приложения. Суть его в том, что свойство document.domain, открывающее доступ к общению между фреймами, будет переводиться в значение родительского домена
только в моменты времени, когда код приложения хочет получить доступ к странице, находящейся внутри
элемента IFRAME. Все остальное время значение этого свойства будет равно полному доменному имени,
что исключает возможность доступа к приложению из атакующего скрипта. Учитывая однопоточную модель
исполнения скриптов в браузере, не предусматривающую программных прерываний, такой метод можно считать надежным.
В передовых браузерах уже сейчас можно встретить реализацию будущего стандарта - метода postMessage [10]. Его использование позволяет избежать выставления единого доменного имени для страницы приложения и просматриваемой страницы, а использовать более естественную парадигму посылки и приема сообщений [11].
Так как все скрипты просматриваемых страниц тоже проходят через proxy сервис, встает задача обнаружения и удаления вредоносного кода перед передачей его на клиента. Для решения этой задачи следует
привлекать технологии антивирусных средств по детектированию сигнатур вредоносного кода и его эвристическому анализу.
Пользователям не рекомендуется осуществлять операции с кредитными карточками, пользоваться услугами интернет-банкинга и подобными сервисами внутри онлайн браузера.
Введена система исключений, указывающих, для каких страниц не следует передавать и хранить заголовок внутри системы.
Рассмотренные особенности олайн браузера, а именно сервиса проксирования содержимого просматриваемых страниц, позволяют реализовать платформу для организации совместной навигации пользователей Интернет и обеспечить поддержку виртуальных сообществ.
ЛИТЕРАТУРА
1. Социальные сети начинают взрослеть?! (http://habrahabr.ru/blog/pure_content/327 50.html)
2. Mashup (web application hybrid)
(http://en.wikipedia.org/wiki/Mashup_%2 8web_application_hybrid%2 9)
3. Mahalo - единый центр социальных сетей и сервисов (http://stimur.habrahabr.ru/blog/3 4 87 5.html)
4. Me.dium Takes Social Surfing to the Next Level (http://mashable.com/2 0 07/0 4/15/medium/)
5. Flock Browser - The Social Web Browser (http://flock.com/)
6. Me.dium: discover new sites and surf with your friends in a new social browsing environment. (http://www.me.dium.com/)
7. Browzmi Beta (http://www.browzmi.com/)
8. Krozilo - Your personal browser (http://krozilo.com/)
9. XMLHttpRequest.responseXML permission denied if document.domain set
(https://bugzilla.mozilla.org/show_bug.cgi?id=326337)
10. Cross-Window Messaging (http://ejohn.org/blog/cross-window-messaging/)
11. DOM:window.postMessage (http://developer.mozilla.org/en/docs/DOM:window.postMessage)
