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

Безопасность 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 показывает диаграмму последовательности, которая илюстрирует рукопожатие протокола веб-сокетов.

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

  1. ПА запрашивает HTML-страницу по протоколу HTTP через стандартный GET-запрос.
  2. Сервер отвечает HTML-страницей, содержащей Javascript, который инициирует переключение на протокол Web Socket.
  3. ПА посылает запрос "переключения ПА".
  4. Сервер отвечает сообщением об успешном переключении протокола.

Подробности процедуры рукопожатия можно найти в разделе 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 Диаграмма последовательности: рукопожатие протокола веб-сокетов.

  1. [Предусловия: ПА уже разрешил доменное имя malicious.csnc.ch через систему доменных имен (DNS) и установил с malicious.csnc.ch TCP/IP-соединение, которое выделено на рисунке внешней красной рамкой.
  2. ПА запрашивает с malicious.csnc.ch ресурс, содержащий JavaScript-код.
  3. JavaScript-код делает HTTP-запрос перехода на веб-сокеты. Прозрачный прокси не понимает запрос перехода на веб-сокеты и направляет его на malicious.csnc.ch. Malicious.csnc.ch понимает и обрабатывает этот запрос, и, в результате, между ПА и malicious.csnc.ch устанавливается соединение по протоколу веб-сокетов (выделено на рисунке внутренней синей рамкой).
  4. ПА делает запрос к 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.

Тени в интернете всегда следят за вами

Станьте невидимкой – подключайтесь к нашему каналу.