Атаки HTML5: что нужно знать

в 10:48, , рубрики: Блог компании Сибирикс

Атаки HTML5: что нужно знать

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

HTML5-атаки

Атаки на CORS (Cross origin resourse sharing) — получение реверсивного шелл-кода

Чтобы отвечать растущим потребностям разработчиков делать высококачественные сайты, HTML5 ослабил внимание к некоторым ограничениям, которые ранее провозглашались концепцией SOP (same origin policy). Концепция имеет простые правила: скрипты, запускаемые на сайте, имеют доступ к методам и свойствам этого сайта, но не имеют такового к страницам другого сайта (SOP как таковое есть обширная отдельная тема, рекомендуем ознакомиться перед дальнейшим чтением).

Теперь HTML5 нарушает эти ограничения.

Например, AJAX-запросы могут выполняться между разными доменами. SOP ограничивает доступ JavaScript к контенту веб-страниц, предписывая обязательное условие: JavaScript и сам контент находятся на одном домене. Без такого ограничения, вредоносный веб-сайт может запускать яваскрипт, который подгружает персональную информацию с других сайтов, используя сохраненные аутентификационные данные пользователей, и возвращает информацию атакующему. Итак, HTML5 сделал возможным получение данных с других доменов с помощью JavaScript.

Так, в то время, как xyz.com разрешает получать данные, abc.com может сделать аякс-запрос к xyz.com и прочитать ответ. Эта особенность используется для туннелирования HTTP-трафика кросс-доменным вызовом.

AJAX вызывает и создает браузерный эквивалент реверсивного шелла с помощью простого инструмента «Shell of of the future». Инструмент основан на концепции, что если атакующий в состоянии найти утечку кросс-доменного запроса, он может использовать начинку JavaScript (убедив пользователя нажать на ссылку) и его скрипт уйдет выполняться на сервер атакующего через кросс-доменный запрос. Используя эту брешь в будущем, атакующий может просматривать сессии жертвы с помощью туннелирования его запросов через браузер жертвы.

Важный вопрос: как сессия жертвы отображается для атакующего?

Это возможно, потому что скрипт, запускаемый браузером пользователя, начинает обращаться к сайту атакующего через Cross Origin Resource (без HTML5 это было бы невозможно). Таким образом атакующий просто туннелирует свой запрос через браузер жертвы.

Кража CSRF-токенов

С HTML5 стало возможным красть CSRF-токены — если токен идет через URL (например, GET-запрос), пользуясь ранее названными правилами CORS. Атакующий может произвести инъекцию в CSRF-начинку на странице, использующей кросс-доменные запросы, после чего создается запрос на целевой сайт, без оповещения об этом пользователя. Обратите внимание, что для CORS должен быть добавлен дополнительный HTTP-заголовок, называемый origin. Смена значения атрибута withCredentials на true позволит угнать куки вместе с запросом. Заголовок сервера в таком случае должен быть Access-Control-Allow-Origin: *. Вместо звездочки можно указать адрес конкретного домена или доменов, которым разрешено получить ответ. Если оставить звездочку — разрешение будет распространяться на все домены.

Пользователь и подозревать не будет, что происходит в фоновом режиме. Таким образом, HTML5 позволяет красть CSRF-токены и выполнять операции без ведома пользователя.

Доступ к внутренним серверам

Многие коммерческие организации имеют внутренние сайты, которые используются для внутренних нужд бизнеса. Фактически это интранет-приложения, недоступные через интернет. Так как таких приложений существует множество, они должны как-то взаимодействовать друг с другом. И, в спешке, большинство разработчиков просто добавляют уже известный нам заголовок Access-Control-Allow-Origin: * и включают CORS. Это может быть использовано атакующим, который может использовать социальную инженерию, чтобы заставить работника компании кликнуть на ссылку, после чего атакующий очень легко получает доступ к контенту.

Своеобразная «пошаговая инструкция»:

  1. Сотрудник компании логинится на сайте, который не доступен через интернет.
  2. Интранет-сервер возвращает запрос с заголовком Access-Control-Allow-Origin: * (Почему? Он хочет позволить другим сайтам в интранете получить доступ к данным сервера).
  3. Сотрудник получает ссылку от злоумышленника в почтовом письме и кликает на нее.
  4. Сайт выглядит совершенно нормально, сотрудник не замечает ничего подозрительного. Но сайт содержит JavaScript-код, который выполняется в браузере сотрудника.
  5. Скрипт в фоновом режиме посылает запрос XMLHttpRequest и он также получает запрос (Почему? Потому что заголовок сервера содержит Access-Control-Allow-Origin: *.
  6. Яваскрипт парсит запрос и отправляет его на сервер атакующего (легко делается через XMLHttpRequest).
  7. Атакующий перехватывает данные, хранящиеся на внутреннем сайте компании.

Новые XSS HTML5 векторы

Разработчики всегда любят делать собственные кастомные фильтры для того, чтобы блокировать XSS-атаки. Большинство из них заносят в черный список такие символы, как <img, <script и так далее. HTML5 вводит множество новых тегов для поддержки мультимедиа и динамической загрузки аудио/видео. Новые теги, атрибуты и события могут, при должном старании, стать потенциальными векторами обхода XSS-фильтров. Ниже несколько возможных векторов, которые были собраны с различных ресурсов:

List of XSS vectors for HTML5
<video><source onerror="javascript:alert(1)">
<video onerror="javascript:alert(1)"><source>
<audio onerror="javascript:alert(1)"><source>
<input autofocus onfocus=alert(1)>
<select autofocus onfocus=alert(1)>
<textarea autofocus onfocus=alert(1)>
<keygen autofocus onfocus=alert(1)>
<button form=test onformchange=alert(2)>X
<form><button formaction="javascript:alert(1)">

Отравление кэша офлайновых веб-приложений

Кэш офлайновых HTML-приложений используется большинством браузеров — Google Chrome, Mozilla, Opera, Safari и так далее. Так, приложение может кэшировать контент для того, чтобы сделать его доступным офлайн. Главная проблема такого кэша — это его уязвимость к классу атак под названием «отравление кэша». Если JS-файл конкретного сайта отравил атакующий — он может очень легко заполучить пользовательский аккаунт. Главное различие между нормальным кэшем и кэшем приложения на HTML5 в том, что первый не позволяет кэшировать все типы файлов, а второй — позволяет. Используя эту особенность, атакующий может украсть аутентификационные данные пользователя.

Давайте посмотрим, как атакующий может сделать это:

  1. Пользователь соединяется с незащищенной Wi-Fi сети в торговом центре.
  2. Пользователь заходит на случайный сайт.
  3. Атакующий отвечает на его запрос страницей, которая содержит скрытый IFrame, призванный собрать с пользователя его Facebook-логин.
  4. Браузер пользователя автоматически посылает запрос на авторизацию.
  5. С этого момент сеть контролируется атакующим, он подает пользователю страницу, которая выглядит точно как страница авторизации в Фейсбуке, с одним только дополнительным кодом.
  6. Этот код будет слать введенные доступы на сайт атакующего. Также, страница содержит команду закэшировать это в системе пользователя. Итак, до этого момента фактически ничего не произошло — кроме того, что страница авторизации закэшировалась в системе пользователя.
  7. Теперь жертва через один-два дня подключается к защищенной сети дома или в офисе и пытается авторизоваться в фейсбуке, вводя ссылку на сайт в адресной строке.
  8. Браузер подгружает фейковую страницу авторизации из кэша.
  9. Когда пользователь вводит доступы, они передаются атакующему, потому что закэшированная страница была так запрограммирована.

Заключение

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

В качестве бонуса — авторитетный комментарий нашего главного защитника информации, Алексея Федоровича:

avatarСобственно атаки на HTML5 как таковые используются довольно редко, злоумышленники не любят усложнять сам процесс получения доступа к конфиденциальным данным, в реальности все больше лидирует обычная компрометация почтовых ящиков, с дальнейшем восстановление паролей от необходимых ресурсов на этот ящик. Ну и конечно-же самый любимый способ всех черношляп, точная копия сайта-формы авторизации (фейк), например Facebook’а или вашего собственного, расположенный на сервере злоумышленника.

А CSRF, XSS, SQLinj и т.п. начинают искать на сайтах, только тогда, когда на той стороне сидит человек с головой и не помогает социальная инженерия + когда у злоумышленника достаточно времени и технических знаний для осуществления задуманного. Если вас захотят взломать, взломают, без вариантов. Можно лишь снизить порог проникновения и на первом уровне отсеять школьников со сканерами безопасности и хактулсами. Удачи.

Оригинал статьи на Onextrapixel.

Автор: zevvssibirix

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js