Межсайтовый скриптинг (XSS) — это кибератака, при которой хакер вводит вредоносный код в веб-форму или URL-адрес веб-приложения. Этот вредоносный код, написанный на языке сценариев, таком как JavaScript или PHP, может делать что угодно: от вандализма на веб-сайте, который вы пытаетесь загрузить, до кражи ваших паролей или других учетных данных для входа.
XSS использует важный аспект современной сети, а именно то, что большинство веб-сайтов создаются «на лету» при загрузке страниц, иногда путем выполнения кода в самом браузере. Это может затруднить предотвращение таких атак.
Как работает XSS
Любой может создать веб-сайт, содержащий вредоносный код. При атаке с использованием межсайтовых сценариев злоумышленник настраивает все таким образом, чтобы его код попадал на компьютер жертвы, когда жертва получает доступ кто-то еще’сайт. Отсюда и «крест» в названии. XSS-атакам удается осуществить это без необходимости получать привилегированный доступ к веб-серверу, чтобы тайно внедрить на него код. Вместо этого злоумышленники используют преимущества современных веб-страниц.
Если бы кто-то попросил вас дать базовое, начальное объяснение сети, вы, вероятно, ответили бы примерно так: человек, который хочет создать веб-страницу, пишет HTML-документ, который он загружает на веб-сервер; когда пользователь хочет получить доступ к этой странице, он указывает в своем браузере адрес сервера, и браузер загружает код HTML и интерпретирует его, чтобы создать версию веб-страницы для пользователя.
В этом описании нет ничего неправильного, но есть аспекты, которые устарели (и устарели уже десять лет или даже больше). Во-первых, многие, если не все веб-страницы, теперь являются динамическими, т. е. они не показывают один и тот же статический HTML-код каждому посетителю, а создаются «на лету» на основе информации, содержащейся в базе данных сервера, когда браузер запрашивает доступ. . То, какую страницу браузер возвращает с сервера, часто зависит от информации, которую он отправляет вместе со своим запросом, — информации, которая иногда принимает форму параметров в URL-адресе, используемом для доступа к сайту. И веб-сайты состоят не только из HTML и каскадных таблиц стилей (CSS), описывающих, как должны отображаться текст и графика; они также включают исполняемый код, написанный на языках сценариев, обычно JavaScript. Такое смешение данных, представления и исполняемого кода является своего рода «первородным грехом» веб-безопасности.
При атаке XSS хакер использует взаимодействие между пользователем и веб-сайтом, чтобы получить вредоносный код для выполнения на компьютере пользователя. Но как? Рассмотрим следующий URL-адрес:
https://www.google.com/seek?q=CSO+on-line
Вставьте это в адресную строку браузера, и вы увидите результаты поиска Google по запросу «CSO On-line». На самом деле страница, которую вы увидите, выглядит точно так же, как если бы вы набрали «CSO On-line» в строке поиска браузера или на главной странице Google.com. Помимо прочего, вы заметите, что фраза появляется в нескольких местах на странице, в том числе в строке поиска вверху:
ОГОА что, если вместо невинной и полезной фразы «CSO онлайн» этот URL-адрес содержал вредоносный код JavaScript, подобный этому?
https://www.google.com/seek?<script>doEvil()</script>
doEvil() здесь заменяет действительно неприятную функциональность. Вы можете беспокоиться о том, что Google вместо того, чтобы отображать «CSO On-line» на странице, которую он возвращает с этого URL-адреса, вместо этого включит этот вредоносный JavaScript в веб-страницу, которую он динамически отображает, и этот сценарий затем будет выполняться в браузере, сея хаос. Ваше беспокойство было бы необоснованным, потому что в штате Google немало талантливых профессионалов в области ИТ-безопасности, и компания внедрила меры по смягчению последствий, которые мы обсудим чуть позже. Но не каждый сайт так осторожен, и это дает вам представление о том, как могут работать эти атаки.
XSS-атаки
Атаки XSS делятся на несколько категорий: отраженные атаки, атаки на основе DOM и сохраненные атаки. Вот чем они отличаются:
Отраженные атаки: Описанная выше атака будет называться отражение или непостоянный атаки, потому что вредоносный JavaScript был отправлен из веб-браузера жертвы в Google, а затем отражен обратно в исполняемой форме и никогда не сохраняется на серверах Google. Эти атаки часто являются частью фишинговой аферы, когда вредоносная ссылка маскируется под что-то более приятное и отправляется жертве по электронной почте или в текстовом сообщении.
Атаки на основе DOM: Это разновидность отраженной атаки, названная в честь объектной модели документа, стандартизированного API, определяющего, как браузеры создают веб-страницу из базового кода HTML или JavaScript. Большинство атак на основе DOM похожи на только что описанную отраженную атаку, за исключением того, что вредоносный код никогда не отправляется на сервер: вместо этого он передается в качестве параметра некоторой функции JavaScript, которая выполняется в самом браузере, что означает, что сервер- боковая защита не может защитить пользователя. PortSwigger более подробно рассматривает, как работают атаки на основе DOM, если вас интересуют подробности.
Сохраненные атаки: Последний основной тип атаки XSS — это хранится или настойчивый атака, и это несколько проще, хотя и довольно опасно. При хранимой атаке злоумышленнику удается использовать интерактивные функции сайта для хранения некоторого вредоносного кода на веб-сервере. В типичном примере злоумышленник может оставить комментарий к сообщению в блоге, содержащее вредоносный код JavaScript. В следующий раз, когда кто-нибудь загрузит эту страницу, код будет выполнен.
XSS-уязвимость
Что делает сайт уязвимым для XSS-атаки? Надеюсь, наше обсуждение дало вам подсказку. Если ваше веб-приложение наивно принимает пользовательский ввод, не проверяет его на наличие потенциально вредоносного исполняемого кода и использует этот ввод для отображения веб-страницы или выполнения других операций, оно уязвимо для такого рода атак.
И ставки высоки. Важным аспектом безопасности браузера является то, что известно как политика того же происхождения, что указывает на то, что сценарий, выполняемый на одной странице, может получить доступ к данным на второй странице только в том случае, если две страницы имеют общий источник (определяется как комбинация схемы URI, имени хоста и номера порта). Но если вредоносный JavaScript может выполняться в браузере, пока жертва обращается к веб-сайту, браузер позволит этому JavaScript получить доступ к данным с других страниц, которые имеют общий источник с уязвимой страницей. Этот JavaScript может получить доступ к файлам cookie и другой ограниченной информации о сеансе, что является хорошим рецептом для взлома онлайн-аккаунтов жертв.
Полезные нагрузки XSS
На языке вредоносных программ полезная нагрузка это исполняемый код, который выполняет действия, которые хочет выполнить злоумышленник. В XSS-атаке полезной нагрузкой является код скрипта, который злоумышленнику удается заставить выполнить браузер жертвы.
Репозиторий payloadbox на GitHub содержит огромный список примеров полезной нагрузки XSS. Если вы знаете JavaScript, их просмотр может дать вам представление о том, как злоумышленники XSS выполняют свою грязную работу. Однако атака XSS выходит далеко за рамки вырезания и вставки полезной нагрузки в URL-адрес: злоумышленнику необходимо понимать конкретные функции и уязвимости веб-приложения, которое он пытается скомпрометировать, чтобы спланировать свою атаку. Если вы хотите пойти глубже и увидеть некоторые примеры XSS-атак, загляните на XSS-страницу OWASP, где подробно описан код скрипта, иллюстрирующий XSS-атаку.
Защита и предотвращение XSS
Если вы создаете или используете веб-приложение или интерактивный веб-сайт, есть три основных метода, которые вы должны интегрировать в дизайн, чтобы смягчить потенциальные атаки с использованием межсайтовых сценариев.
- Санитарная обработка ввода. Очевидным ответом на предотвращение передачи вредоносного кода сценария в качестве входных данных и его отражения пользователю является, в первую очередь, просто не принимать код сценария в качестве входных данных. Вы определенно должны фильтровать ввод с учетом этого, но это легче сказать, чем сделать; искусно созданные фрагменты исполняемого кода можно пропускать через фильтры. Один из способов справиться с этим — использовать белый, а не черный список. Например, вместо того, чтобы пытаться написать фильтр, который блокирует ввод всего вредоносного кода в веб-форму, напишите свое приложение так, чтобы оно принимало данные только из указанные форматы (номера телефонов, адреса электронной почты и т. д.), если это то, что вы ожидаете.
- Исчезновение вывода. Это решает проблему с другой стороны. Если ваше веб-приложение отправляет данные, введенные пользователем, обратно на веб-страницу, эти данные следует отфильтровать, чтобы убедиться, что они не станут исполняемым кодом на этой веб-странице. Если пользователь вводит код тегов HTML в качестве входных данных, ваше приложение должно использовать escape-символы, чтобы эти теги отображались в виде текста на результирующей странице, а не интегрировались в сам HTML-код страницы.
- Стандарт политики безопасности контента (CSP). CSP использует подход белого списка не только для ввода текста, но и для выполнения сценариев: ваше веб-приложение должно когда-либо выполнять только тот код, который вы указали как безопасный. У Google есть отличные ресурсы по внедрению CSP.
XSS-тест
Тестирование на XSS-уязвимости — важный аспект обеспечения безопасности вашего веб-приложения. У OWASP есть ресурсы, в которых подробно рассказывается о том, как вы можете протестировать свои приложения на уязвимость к атакам на основе DOM или отраженным межсайтовым сценариям. Если вы ищете XSS-шпаргалка, OWASP также предоставил вам документ, полный кода для XSS-атак, который можно использовать для обхода определенных защитных фильтров XSS; они окажутся бесценными для любого тестирования на проникновение, которое вы можете проводить против своих собственных систем.
XSS против CSRF
Вы могли слышать, что CSRF используется в том же контексте, что и XSS. Это означает подделка межсайтовых запросов, которая, как и XSS, нацелена на браузер пользователя. Основное отличие состоит в том, что CSRF использует аутентифицированный сеанс пользователя (возможно, они вошли в свой банковский счет), в то время как XSS не нуждается в аутентифицированном сеансе, чтобы быть эффективным.
Допустим, вы вошли в Twitter и онлайн-банкинг одновременно и нажали на ссылку Twitter, которая выглядела так:
http://www.yourbank.com/sendmoney,do?from=you&to=attacker&quantity=5000
В зависимости от того, как ваш банк управляет токенами сеанса и какой браузер вы используете, вы можете стать на пять тысяч беднее. XSS — более опасный вектор атаки, но важно защищаться как от XSS, так и от CSRF. OWASP также имеет шпаргалку по защитным мерам безопасности CSRF.
Недавние и известные XSS-атаки
Одна из самых ранних и самых известных атак с использованием межсайтового скриптинга произошла в 2005 году, когда предприимчивый пользователь MySpace Сэми Камкар выяснил, что он может вставить код JavaScript в свой профиль, который автоматически подружится со всеми, кто посещает страницу, а также скопирует этот код. в профили его новых друзей, чтобы каждый, кто посетил те страницы также подружился с ним. (Сценарий позаботился о том, чтобы каждый из новых друзей Камкара включил его в свою «лучшую восьмерку», и мы боимся, что вам действительно нужно было быть там в то время, чтобы понять, но поверьте нам, когда мы говорим, что это важно. ) В течение 24 часов он завел более миллиона друзей и вынудил MySpace ненадолго отключить весь свой сайт.
Так называемый червь Samy оказался в основном безвредным. Но другие были гораздо более тревожными:
И межсайтовый скриптинг остается серьезной угрозой сегодня. С 2021 года XSS-уязвимости были обнаружены в почтовой платформе Zimbra, WordPress и платформе управления ИТ с открытым исходным кодом Nagios. И помните, хакеры, как правило, не используют методы атаки изолированно: например, межсайтовый скриптинг является одним из компонентов сложной и недавно обнаруженной формы атаки с использованием подстановочных сертификатов TLS, называемой ALPACA. Вы должны убедиться, что ваши XSS-уязвимости закрыты, чтобы предотвратить большие риски.
© 2022 IDG Communications, Inc.
https://cyberxhack.org/