Все последние версии браузеров поддерживают 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. Это может быть использовано атакующим, который может использовать социальную инженерию, чтобы заставить работника компании кликнуть на ссылку, после чего атакующий очень легко получает доступ к контенту.
Своеобразная «пошаговая инструкция»:
- Сотрудник компании логинится на сайте, который не доступен через интернет.
- Интранет-сервер возвращает запрос с заголовком
Access-Control-Allow-Origin: *(Почему? Он хочет позволить другим сайтам в интранете получить доступ к данным сервера). - Сотрудник получает ссылку от злоумышленника в почтовом письме и кликает на нее.
- Сайт выглядит совершенно нормально, сотрудник не замечает ничего подозрительного. Но сайт содержит JavaScript-код, который выполняется в браузере сотрудника.
- Скрипт в фоновом режиме посылает запрос XMLHttpRequest и он также получает запрос (Почему? Потому что заголовок сервера содержит
Access-Control-Allow-Origin: *. - Яваскрипт парсит запрос и отправляет его на сервер атакующего (легко делается через XMLHttpRequest).
- Атакующий перехватывает данные, хранящиеся на внутреннем сайте компании.
Новые 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 в том, что первый не позволяет кэшировать все типы файлов, а второй — позволяет. Используя эту особенность, атакующий может украсть аутентификационные данные пользователя.
Давайте посмотрим, как атакующий может сделать это:
- Пользователь соединяется с незащищенной Wi-Fi сети в торговом центре.
- Пользователь заходит на случайный сайт.
- Атакующий отвечает на его запрос страницей, которая содержит скрытый IFrame, призванный собрать с пользователя его Facebook-логин.
- Браузер пользователя автоматически посылает запрос на авторизацию.
- С этого момент сеть контролируется атакующим, он подает пользователю страницу, которая выглядит точно как страница авторизации в Фейсбуке, с одним только дополнительным кодом.
- Этот код будет слать введенные доступы на сайт атакующего. Также, страница содержит команду закэшировать это в системе пользователя. Итак, до этого момента фактически ничего не произошло — кроме того, что страница авторизации закэшировалась в системе пользователя.
- Теперь жертва через один-два дня подключается к защищенной сети дома или в офисе и пытается авторизоваться в фейсбуке, вводя ссылку на сайт в адресной строке.
- Браузер подгружает фейковую страницу авторизации из кэша.
- Когда пользователь вводит доступы, они передаются атакующему, потому что закэшированная страница была так запрограммирована.
Заключение
Таким образом, через отравление кэша веб-приложения, атакующий может украсть доступы пользователя. Это несколько атак, которые обнаружили специалисты по безопасности. В ближайшие годы, без сомнения, появится еще больше атак, основанных на специфике HTML5.
В качестве бонуса — авторитетный комментарий нашего главного защитника информации, Алексея Федоровича:
Собственно атаки на HTML5 как таковые используются довольно редко, злоумышленники не любят усложнять сам процесс получения доступа к конфиденциальным данным, в реальности все больше лидирует обычная компрометация почтовых ящиков, с дальнейшем восстановление паролей от необходимых ресурсов на этот ящик. Ну и конечно-же самый любимый способ всех черношляп, точная копия сайта-формы авторизации (фейк), например Facebook’а или вашего собственного, расположенный на сервере злоумышленника.
А CSRF, XSS, SQLinj и т.п. начинают искать на сайтах, только тогда, когда на той стороне сидит человек с головой и не помогает социальная инженерия + когда у злоумышленника достаточно времени и технических знаний для осуществления задуманного. Если вас захотят взломать, взломают, без вариантов. Можно лишь снизить порог проникновения и на первом уровне отсеять школьников со сканерами безопасности и хактулсами. Удачи.
Оригинал статьи на Onextrapixel.
Автор: zevvssibirix
