Межсайтовый скриптинг (XSS) — это кибератака, при которой хакер вставляет вредоносный код в веб-форму или URL-адрес веб-приложения. Этот вредоносный код, написанный на языке сценариев, таком как JavaScript или PHP, может сделать что угодно: от уничтожения страницы, которую вы пытаетесь загрузить, до кражи ваших паролей или других учетных данных для входа.

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

Проверьте также:

Как работает XSS-атака?

Любой может создать веб-сайт, содержащий вредоносный код. В случае атаки с использованием межсайтового скриптинга злоумышленник подстраивает все так, чтобы его код попадал на компьютер жертвы при посещении чужого веб-сайта. Отсюда и «крест» в названии. Атаки XSS достигают этого, не требуя привилегированного доступа к веб-серверу для тайного размещения кода. Вместо этого злоумышленники используют то, как работают современные веб-сайты.

Если бы кто-то попросил вас дать простое и базовое объяснение того, как работает Интернет, вы, вероятно, могли бы ответить примерно так: человек, который хочет создать веб-страницу, пишет HTML-документ и размещает его на веб-сервере; Когда пользователь хочет получить доступ к этой странице, он направляет свой браузер на адрес сервера, браузер загружает и интерпретирует HTML-код и создает копию веб-страницы пользователя.

Это описание верно, но некоторые аспекты устарели (и существуют уже более десяти лет). Во-первых, многие, если не все, веб-страницы сегодня являются динамическими, то есть они не отображают один и тот же статический HTML-код для каждого посетителя, а генерируются мгновенно из информации в базе данных сервера, когда браузер запрашивает доступ. Страница, которую браузер получает с сервера, часто зависит от информации, отправленной с запросом, — информации, которая иногда принимает форму параметров в URL-адресе, используемом для доступа к сайту. Веб-сайты состоят не только из HTML и каскадных таблиц стилей (CSS), которые описывают, как отображать текст и графику, но также содержат исполняемый код, написанный на языках сценариев, обычно JavaScript.

При атаке XSS хакер использует это взаимодействие между пользователем и веб-сайтом для выполнения вредоносного кода на компьютере пользователя. но как? Рассмотрим следующий URL-адрес:

https://www.google.com/search?q=CSO+онлайн

Введите это в адресную строку браузера, и вы увидите результаты поиска Google по запросу «CSO Online». На самом деле страница, которую вы увидите, выглядит точно так же, как если бы вы ввели «CSO Online» в строке поиска браузера или на главной странице Google. Вы заметите, среди прочего, что эта фраза появляется в нескольких местах на странице, включая строку поиска в горах:

Что, если вместо невинной и успешной фразы «CSO онлайн» этот URL-адрес содержал подобный вредоносный код JavaScript?

https://www.google.com/search?<script>doEvil()</script>

doEvil() делает здесь действительно плохую работу. Вы можете быть обеспокоены тем, что Google, вместо того, чтобы отображать «CSO Online» на странице, которую вы возвращаете с этого URL-адреса, вместо этого динамически интегрирует плохой javascript в страницу, которую вы отображаете, и что этот скрипт выполняется в вашем браузере. , вызывая беспорядок. Ваши опасения будут беспочвенными, ведь Google имеет среди своих сотрудников очень большое количество талантливых специалистов по ИТ-безопасности и внедрила корректирующие меры, о которых мы поговорим чуть позже. Однако не каждый сайт очень осторожен, и это дает вам представление о том, как работают такие атаки.

Атаки XSS

Атаки XSS делятся на несколько категорий: отраженные атаки, атаки на основе DOM и сохраненные атаки. Вот чем они отличаются:

• Рефлекторные атаки: также известные как слабые атаки, вредоносный код JavaScript отправляется из браузера жертвы в Google, а затем отражается обратно в исполняемой форме, которая никогда не сохраняется на серверах Google. Эти атаки часто являются частью фишинговой аферы, когда вредоносная ссылка маскируется под что-то более забавное и отправляется жертве по электронной почте или SMS.
• Атаки на основе DOM: это тип рефлекторной атаки, называемой объектной моделью документа, которая представляет собой стандартный API, определяющий, как браузеры создают веб-страницу из базового кода HTML или JavaScript. Большинство DOM-атак аналогичны рефлекторной атаке, описанной ранее, с тем отличием, что вредоносный код никогда не отправляется на сервер: вместо этого он передается в качестве параметра какой-либо функции JavaScript, которая выполняется в самом браузере, а это означает, что механизмы, защищающие на стороне сервера не могут защитить пользователя. Если вас интересуют подробности, у PortSwigger есть более подробное описание того, как работают DOM-атаки.
• Сохраненные атаки: в противном случае постоянные; Злоумышленник использует интерактивные функции веб-сайта для сохранения вредоносного кода на веб-сервере. В типичном примере злоумышленник оставляет комментарий к сообщению в блоге, который содержит вредоносный код JavaScript. В следующий раз, когда кто-то загрузит эту страницу, код будет выполнен.
• Уязвимость к XSS-атаке

Что делает сайт уязвимым для XSS-атаки? Надеюсь, наше обсуждение до сих пор дало некоторые указания. Если ваше веб-приложение наивно принимает пользовательский ввод, не проверяет его на наличие вредоносного исполняемого кода и использует эти данные для отображения страницы или выполнения других операций, оно уязвимо для этого типа атаки.

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

Полезные нагрузки XSS

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

В репозитории Payloadbox на GitHub есть огромный список шаблонов полезной нагрузки XSS. Если вы знакомы с JavaScript, его просмотр может дать вам представление о том, как злоумышленники XSS выполняют свою грязную работу. Однако атака XSS выходит за рамки вырезания и вставки полезной нагрузки в URL-адрес: злоумышленнику необходимо понимать конкретные функции и уязвимости веб-приложения, которое он хочет использовать, чтобы спланировать атаку. Если вы хотите копнуть глубже и увидеть некоторые примеры XSS-атак, посетите веб-сайт OWASP XSS, чтобы подробно изучить код скрипта, демонстрирующий XSS-атаку.

Защита и предотвращение XSS

Если вы создаете или поддерживаете веб-приложение или интерактивный веб-сайт, есть три основных метода, которые вы должны учитывать при разработке, чтобы избежать потенциальных атак с использованием межсайтовых сценариев.

• Стерилизация входных данных. Очевидный ответ для предотвращения передачи вредоносного кода в качестве входных данных и возврата пользователю — просто не принимать код сценария в качестве входных данных. Вы обязательно должны фильтровать свой ввод с учетом этого, но это легче сказать, чем сделать; Небольшие фрагменты исполняемого кода могут проскользнуть через фильтры. Одним из способов решения этой проблемы является использование белого списка вместо черного списка. Например, вместо того, чтобы пытаться написать фильтр, который будет блокировать весь вредоносный код, загружаемый в веб-форму, вы должны написать свое приложение, чтобы принимать данные в определенное время Форматы (номера телефонов, адреса электронной почты и т. д.) только тогда, когда это то, что вы хотите.
• Побег с выхода. Это решение проблемы с другой стороны. Если веб-приложение отправляет пользовательский ввод обратно на веб-страницу, эти данные должны быть отфильтрованы, чтобы гарантировать, что они не станут исполняемыми на этой странице. Если пользователь вводит теги HTML в качестве входных данных, приложение должно использовать переопределенные символы, чтобы эти теги отображались в виде текста на странице результатов, а не интегрировались с HTML самой страницы.
• Стандартная политика безопасности контента (CSP). CSP использует подход «белого списка» за пределами ввода текста в область сценариев: веб-приложение должно выполнять только тот код, который пользователь указал как безопасный. У Google есть отличные ресурсы по внедрению CSP.

XSS-тест

Тестирование уязвимостей для XSS-атак — важный аспект обеспечения безопасности веб-приложения. У OWASP есть ресурсы, подробно описывающие, как можно тестировать приложения, чтобы избежать DOM-атак или обратного межсайтового скриптинга. Если вы ищете лист XSS, OWASP также предлагает вам документ с кодом атаки XSS, который можно использовать для обхода некоторых защитных фильтров XSS; Это окажется неоценимым в тестах на проникновение, которые вы можете выполнять в своих собственных системах.

XSS и CSRF

Вы можете слышать, что CSRF используется в том же контексте, что и XSS. Это сокращение от Cross-Site Request Forgery, атаки, похожей на XSS, нацеленной на браузер пользователя. Основное отличие состоит в том, что CSRF использует аутентифицированный сеанс для пользователя (возможно, они вошли в свою банковскую учетную запись), в то время как XSS не нуждается в аутентифицированном сеансе, чтобы быть эффективным.

Допустим, пользователь одновременно авторизовался в Твиттере и интернет-банке и нажимает на ссылку Твиттера, которая выглядит так:

http://www.yourbank.com/sendmoney,do?from=you&to=attacker&amount=5000

В зависимости от того, как ваш банк управляет токенами сеанса и используемого вами браузера, они могут внезапно стать намного хуже. XSS — более опасный вектор атаки, но важно защищаться как от XSS, так и от CSRF. OWASP подготовил информационный лист о мерах защиты от CSRF.

Недавние и печально известные XSS-атаки

Одна из старейших и самых известных атак с использованием межсайтовых сценариев произошла в 2005 году, когда предприимчивый пользователь MySpace Сэмми Камкар понял, что может ввести в свой профиль код JavaScript, который будет автоматически аутентифицировать любого, кто посещает сайт, а также скопировать этот код в профили ваших новые друзья, Благодаря этому каждый, кто посещает эти страницы, также будет его другом. (Сценарий позаботился о том, чтобы каждый из новых друзей Камкара попал в «восьмерку» — боимся это понять, там нужно было быть, но поверьте, это имело значение.) В течение 24 часов он завел более миллиона друзей и вынудил MySpace на короткое время закрыть весь сайт.

Оказывается, так называемый саамский червь в основном безвреден. Однако другие раздражали больше:

• На протяжении многих лет у Ebay были XSS-уязвимости, которые позволяли хакерам красть учетные данные пользователя.

• Злоумышленники XSS смогли украсть V-Bucks у игроков Fortnite в 2019 году.

• В 2018 году хакерская группа Magecart атаковала British Airways с помощью XSS-атаки, похитив сотни тысяч учетных записей пользователей.

И сегодня межсайтовый скриптинг остается серьезной угрозой. По состоянию на 2021 год уязвимости XSS были обнаружены в почтовой платформе Zimbra, Wordpress и платформе управления ИТ с открытым исходным кодом Nagios. Имейте в виду, что хакеры обычно не используют методы атаки изолированно: межсайтовые сценарии являются компонентом недавно обнаруженной сложной формы атаки с использованием подстановочных знаков TLS, известной как ALPACA. Чтобы избежать опасных угроз, обязательно закройте XSS-уязвимости.

Источник: ОГО