Xss | это… Что такое Xss?

ТолкованиеПеревод

Xss

XSS (англ. Сross Site Sсriрting — «межсайтовый скриптинг») — тип уязвимости компьютерной системы, используется при хакерской атаке. Специфика подобных атак заключается в том, что вместо непосредственной атаки сервера, они используют уязвимый сервер в качестве средства атаки на клиента. XSS-атака обычно проводится путём конструирования специального

Иногда для термина используют сокращение «CSS», но чтобы не было путаницы с каскадными таблицами стилей, используют сокращение «XSS».

Условно XSS можно разделить на активные и пассивные:

• Пассивные XSS подразумевают, что скрипт не хранится на сервере уязвимого сайта, либо он не может автоматически выполниться в браузере жертвы. Для срабатывания пассивной XSS, требуется некое дополнительное действие, которое должен выполнить браузер жертвы (например клик по специально сформированной ссылке). Их также называют первым типом XSS.
• При активных XSS вредоносный скрипт хранится на сервере, и срабатывает в браузере жертвы, при открытии какой-либо страницы зараженного сайта. Их также называют вторым типом XSS.
• Часто в отдельный тип выделяют межсайтовый скриптинг через DOM, являющийся пассивным, но использующим уязвимости в клиентских скриптах. Его так же называют третьим или нулевым типом.^[1]

Сейчас XSS составляют около 15 % всех обнаруженных уязвимостей^[2]. Долгое время программисты не уделяли им должного внимания, считая их неопасными. Однако, это мнение ошибочно: в некоторых случаях с помощью XSS удаётся получить идентификатор сессии администратора или организовать DoS-атакy.

Содержание 1 Примеры 1.1 Отсутствие фильтрации html тегов в сообщениях пользователей 1.2 Отсутствие фильтрации атрибутов и их значений разрешённых тегов 1.3 Подмена кодировки в заголовке страницы 1. 4 Другие примеры 2 Ссылки 3 Примечания

Примеры

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

Отсутствие фильтрации html тегов в сообщениях пользователей

Некоторые форумы позволяют пользователю использовать html теги для форматирования текста. Если отсутствует должный уровень фильтрации, злонамеренный пользователь может вставить такие теги, как <script> и <iframe> так, что HTTP-Cookie пользователей и администраторов, открывших некоторую тему форума, будут отправлены хакеру, или незаметно открыть произвольную ссылку в контексте браузера пользователя.

Для защиты от этого вида атак следует удалить все теги, кроме входящих в белый список.

Отсутствие фильтрации атрибутов и их значений разрешённых тегов

Данная уязвимость, в отличие от предыдущей, не специфична для html форматирования сообщений пользователя. Наиболее ярким примером её является тег img. Хакер может указать в качестве адреса сервер, имеющий узкий интернет канал, парализуя его работу большим количеством запросов, или устроить с его помощью XSRF атаку. Также хакер может указать атрибут onmouseover и выполнить произвольный javascript код.

В качестве примера подобной уязвимости можно рассмотреть уязвимость в известном форумном движке 2002 год.^[3][4] Используя эту уязвимость, хакер может закрыть атрибут src и открыть onmouseover, вызывающий вредоносный код.

Для защиты от уязвимостей данного типа требуется жёсткая фильтрация, как названий атрибутов, так и их значений. Также следует запретить использование протоколов javascript: и data: во всех ссылках.

Подмена кодировки в заголовке страницы

Современные браузеры пытаются определить кодировку страницы на ходу и интерпретируют html в соответствии с этой кодировкой. В случае, если тег title расположен до тега meta и заполняется пользовательскими данными, хакер может вставить злонамеренный html код в UTF-7 кодировке, обойдя таким образом фильтрацию таких символов, как < и «. ^[5][6]

Для защиты от данной уязвимости следует явно указывать кодировку страницы до каких-либо пользовательских данных.

Другие примеры

Существует также возможность обхода фильтра javascript через пользовательскую flash анимацию. Подробности можно почитать на eyeonsecurity.org.^[7]

К другим необычным типам XSS атак относятся самодостаточные XSS.^[8]

Ссылки

• Microsoft Anti-Cross Site Scripting Library еще один способ защиты от XSS-атак
• Основные принципы XSS атаки в форумных движках.
• XSS (Cross Site Scripting) Cheat Sheet. Esp: for filter evasion

Примечания

1. ↑ http://www.securitylab.ru/analytics/275087.php
2. ↑ По данным securitylab.ru 15,37 % за второй квартал 2008 и 16,57 % за первый квартал 2008
3. ↑ http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2002-0902 (англ.)
4. ↑ http://seclists.org/bugtraq/2002/May/0243. html (англ.)
5. ↑ http://old.antichat.ru/txt/utf7/
6. ↑ http://openmya.hacker.jp/hasegawa/security/utf7cs.html (англ.)
7. ↑ http://eyeonsecurity.org/papers/flash-xss.htm (англ.)
8. ↑ http://www.securitylab.ru/analytics/274302.php

Wikimedia Foundation.
2010.

Игры ⚽ Нужно сделать НИР?

• XrossMediaBar
• Xu

Полезное

Как найти XSS уязвимость на сайте: обзор онлайн-инструментов для проверки

16840

Прочитать позже

ЧЕК-ЛИСТ: ТЕХНИЧЕСКАЯ ЧАСТЬ — АНАЛИЗ

Инструкцию одобрил SEO Classifieds Specialist в Inweb

Виктор Саркисов

XSS — это тип атаки на сайт, который сопровождается внедрением вредоносного кода. Атака может быть активной (когда ведется поиск ошибок в безопасности) и пассивной (когда для заражения нужно перейти по ссылке). Чтобы не дать злоумышленникам возможности заразить свой сайт, нужно проверить его на XSS-уязвимости.

Что такое XSS-скрипты

Аббревиатура XSS расшифровывается как Cross-Site Scripting — межсайтовый скриптинг. При данном типе атаки злоумышленник внедряет на страницу сайта вредоносный код, который будет выполняться на компьютере пользователя, открывшего данную страницу.

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

Чтобы проверить сайт на уязвимость, нужно обращаться к профессионалам. Обращение к разработчику — наиболее эффективный способ, поскольку автоматические инструменты работают шаблонно и могут пропустить что-нибудь важное. Если такой возможности нет, можете воспользоваться сканерами и плагинами.

Сканеры сайтов

Acunetix Web Security Scanner

Один из сканеров для проверки на уязвимости — Acunetix Web Security Scanner. Он предоставляет 14 дней на использование демо-версии. Далее нужно выбрать и оплатить тарифный план.

Для тестирования сайта на уязвимости необходимо зарегистрировать свой проект в системе и подтвердить аккаунт по телефону. Когда аккаунт подтвержден, вы можете создать проверку:

Сканер сайта покажет, где находятся уязвимые места, и позволит выгрузить отчет к себе на компьютер.

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

Зато, получив отчет, можно будет обратиться за помощью к программистам с готовым техническим заданием на устранение ошибок в коде.

Если ваш сайт размещен на платформе WordPress, можете установить плагин от того же создателя. Он будет действовать как дополнительный инструмент для проверки безопасности сайта, но не может стать основной мерой защиты от угроз, поскольку обновлялся последний раз в 2016 году.

XSS и SQL Injection Сканер

Еще один вариант проверки онлайн — XSS и SQL Injection Сканер, в который требуется загрузить php-файл.

Для этого скачайте php-файл из корневой папки сайта к себе на компьютер. Потом перейдите по ссылке и загрузите его для проверки. Бесплатная проверка подойдет для небольших проектов (максимальный вес файла — 5 мегабайт).

Чтобы загрузить файл с компьютера, нажмите «Другие файлы» и выберите нужный. После жмите кнопку «Сканировать». Отчет получаем на этой же странице, чуть ниже сканера.

Плагины для поиска уязвимостей

Для разных CMS существует ряд готовых решений в виде плагинов. Их количество зависит только от популярности платформы. Рассмотрим несколько вариантов на примере WordPress.

Задачей каждого из плагинов является поиск лазеек в коде сайта.
Причиной их возникновения становятся как уязвимые темы, так и отсутствие своевременного обновления шаблонов и плагинов. Также потенциально уязвимы открытые директории для разных IP — например, wp-admin. Все это можно отслеживать при помощи некоторых плагинов.

К примеру, BulletProof Security обеспечивает безопасность сайтов на WordPress, предоставляя защиту не только от XSS-атак, но и других способов внедрения вредоносного кода, кражи базы данных и т.д.

Целенаправленную проверку URL с XSS-значениями выполняет плагин Prevent XSS Vulnerability.

Целесообразнее выбрать один плагин, который будет полностью отвечать за безопасность сайта, и не нагружать систему разными дополнениями, которые могут конфликтовать между собой и потерять эффективность.

Заключение

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

Защита от XSS-атак — обязательное условие успешного проекта. Недооценив его, вы рискуете потерять клиентов, сайт и репутацию в интернете.

Для проверки на наличие уязвимостей эффективнее всего обратиться к разработчику, который осуществит проверку самостоятельно и сможет выявить не только шаблонные ошибки.

Если же ваш бюджет этого не позволяет, можно просканировать сайт с помощью онлайн-сервисов. Они предоставят данные об уязвимых местах шаблонного характера. В этих целях можно использовать Acunetix Web Security Scanner, XSS Injection Сканер или аналоги.

Кроме того, для большинства CMS существуют готовые решения безопасности в виде плагинов. На WordPress есть расширения и для проверки, и для усиления защиты от XSS.

«Список задач» — готовый to-do лист, который поможет вести учет
о выполнении работ по конкретному проекту. Инструмент содержит готовые шаблоны с обширным списком параметров по развитию проекта, к которым также можно добавлять собственные пункты.

Начать работу со «Списком задач»

Serpstat — набор инструментов для поискового маркетинга!

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

Набор инструментов для экономии времени на выполнение SEO-задач.

7 дней бесплатно

Оцените статью по 5-бальной шкале

3.27 из 5 на основе 11 оценок

Нашли ошибку? Выделите её и нажмите Ctrl + Enter, чтобы сообщить нам.

Используйте лучшие SEO инструменты

Подбор ключевых слов

Поиск ключевых слов – раскройте неиспользованный потенциал вашего сайта

Возможности Serpstat

Возможности Serpstat – комплексное решение для эффективного продвижения вебсайтов

Кластеризация ключевых слов

Кластеризация ключевых слов автоматически обработает до 50 000 запросов в несколько кликов

SEO аудит страницы

Проанализируйте уровень оптимизации документа используя SЕО аудит страницы

Рекомендуемые статьи

How-to

Denys Kondak

Как проанализировать SEO-стратегию на старте проекта

How-to

Denys Kondak

Как оценить трафиковый потенциал сайта

How-to

Denys Kondak

Как SEO-оптимизировать страницы пагинации

Кейсы, лайфхаки, исследования и полезные статьи

Не успеваешь следить за новостями? Не беда! Наш любимый редактор подберет материалы, которые точно помогут в работе. Только полезные статьи, реальные кейсы и новости Serpstat раз в неделю. Присоединяйся к уютному комьюнити 🙂

Нажимая кнопку, ты соглашаешься с нашей политикой конфиденциальности.

Поделитесь статьей с вашими друзьями

Вы уверены?

Спасибо, мы сохранили ваши новые настройки рассылок.

Сообщить об ошибке

Отменить

В чем хранится XSS (межсайтовый скриптинг)? Учебник и примеры

Твиттер

WhatsApp

Фейсбук

Реддит

LinkedIn

Электронная почта

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

Что хранится в межсайтовых сценариях?

Сохраненный межсайтовый скриптинг (также известный как вторичный или постоянный XSS) возникает, когда приложение получает данные из ненадежного источника и включает эти данные в свои более поздние HTTP-ответы небезопасным способом.

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

POST/сообщение/комментарий HTTP/1.1
Хост: уязвимый-website.com
Длина содержимого: 100
postId=3&comment=Этот+сообщение+было+чрезвычайно+полезным.&name=Carlos+Montoya&email=carlos%40normal-user.net

После отправки этого комментария любой пользователь, посетивший сообщение в блоге, получит в ответе приложения следующее:

Это сообщение было очень полезным.

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

В запросе злоумышленника этот комментарий будет закодирован в URL как:

комментарий=%3Cscript%3E%2F*%2BBad%2Bstuff%2Bhere. ..%2B*%2F%3C%2Fscript%3E

Любой пользователь, посетивший сообщение в блоге, теперь получит в ответе приложения следующее:

Сценарий, предоставленный злоумышленником, затем будет выполняться в браузере пользователя-жертвы в контексте его сеанса с приложением.

ЛАБОРАТОРИЯ

УЧЕНИК
Сохраненный XSS в HTML-контексте без кодирования

Влияние сохраненных XSS-атак

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

С точки зрения возможности использования, ключевое различие между отраженным и сохраненным XSS заключается в том, что сохраненная уязвимость XSS позволяет проводить атаки, которые являются автономными внутри самого приложения. Злоумышленнику не нужно искать внешний способ побудить других пользователей сделать конкретный запрос, содержащий их эксплойт. Скорее, злоумышленник помещает свой эксплойт в само приложение и просто ждет, пока пользователи не столкнутся с ним.

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

Подробнее

Использование уязвимостей межсайтового скриптинга

Сохранение XSS в различных контекстах

Существует множество различных разновидностей хранимых межсайтовых сценариев. Расположение сохраненных данных в ответе приложения определяет, какой тип полезной нагрузки требуется для его использования, а также может повлиять на влияние уязвимости.

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

Подробнее

Контексты межсайтового скриптинга

Как найти и протестировать сохраненные XSS-уязвимости

Многие сохраненные XSS-уязвимости можно найти с помощью веб-сканера уязвимостей Burp Suite.

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

Точки входа в обработку заявки включают:

• Параметры или другие данные в строке запроса URL и тексте сообщения.
• Путь к файлу URL.
• Заголовки HTTP-запросов, которые могут быть неприменимы в отношении отраженного XSS.
• Любые внеполосные маршруты, по которым злоумышленник может доставить данные в приложение. Существующие маршруты полностью зависят от функциональности, реализуемой приложением: приложение веб-почты будет обрабатывать данные, полученные в электронных письмах; приложение, отображающее ленту Twitter, может обрабатывать данные, содержащиеся в сторонних твитах; а агрегатор новостей будет включать данные с других веб-сайтов.

Точки выхода для сохраненных XSS-атак — это все возможные ответы HTTP, которые возвращаются любому пользователю приложения в любой ситуации.

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

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

Чтобы всесторонне идентифицировать связи между точками входа и выхода, потребуется протестировать каждую перестановку отдельно, передать определенное значение в точку входа, перейти непосредственно к точке выхода и определить, появляется ли значение там. Однако этот подход нецелесообразен в приложении, содержащем более нескольких страниц.

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

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

Что такое межсайтовый скриптинг (XSS)? Определение и предотвращение

Межсайтовый скриптинг (XSS) — это атака на безопасность путем внедрения кода, нацеленная на веб-приложения, которая доставляет вредоносные клиентские сценарии в веб-браузер пользователя для выполнения. Цели не подвергаются прямым атакам, скорее уязвимые веб-сайты и веб-приложения используются для выполнения атак с использованием межсайтовых сценариев, когда пользователи взаимодействуют с этими сайтами/приложениями.

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

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

Узнайте больше о 7 распространенных типах кибератак.

Влияние межсайтового скриптинга

Когда веб-страница скомпрометирована с помощью межсайтового скриптинга, может быстро возникнуть ряд проблем. Возможные проблемы включают, но не ограничиваются:

• Раскрытие конфиденциальных пользовательских данных
• Злоумышленники захватывают онлайн-аккаунты и выдают себя за пользователей
• Вандализм в отношении представления содержимого веб-сайта
• Загрузка вредоносных «троянских программ»
• Перенаправление веб-страниц в опасные места

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

Неудачный пример межсайтового скриптинга произошел во время курортного сезона 2018 г., когда появилось вредоносное ПО для скимминга кредитных карт под названием «Magecart». впервые такое масштабное нападение произошло. Информация о кредитной карте пользователя, вероятно, была загружена на сервер, контролируемый злоумышленником, и потенциально продана или использована для мошеннических покупок.

Типы атак с использованием межсайтовых сценариев

Атаки с использованием межсайтовых сценариев обычно относятся к одному из следующих типов.

• Отраженный XSS
• Постоянный XSS
• XSS на основе домена

Отраженный XSS

Отраженная XSS-атака включает в себя уязвимый веб-сайт, принимающий данные (т. е. вредоносный скрипт), отправленные собственным веб-браузером цели для атаки цели. Поскольку вредоносный скрипт отправляется самим клиентом и не хранится на уязвимом сервере, этот тип атаки также называют «непостоянным».

Простой пример отраженной атаки XSS может заключаться в том, что злоумышленник создает URL-адрес, который передает небольшой вредоносный скрипт в качестве параметра запроса на веб-сайт, страница поиска которого уязвима для XSS:

http://vulnerable- веб-сайт.com/search?search_term=»»

Затем злоумышленнику необходимо, чтобы цели посещали этот URL-адрес из своих веб-браузеров. Этого можно добиться, отправив электронное письмо, содержащее URL-адрес (с разумной причиной, чтобы заставить пользователя щелкнуть по нему), или опубликовав URL-адрес на общедоступном, неуязвимом веб-сайте, чтобы цели могли щелкнуть.

Когда цель щелкает ссылку, уязвимый сайт принимает параметр запроса «search_term», ожидая, что это значение представляет собой то, что цель хочет найти на сайте уязвимый-website.com, когда на самом деле значение является вредоносным сценарий.

Затем страница поиска, как и большинство страниц поиска веб-сайтов, когда пользователь что-то ищет, отображает «Поиск . ..», но поскольку уязвимый сайт не очистил значение search_term, вредоносный сценарий вводится на веб-страницу, которую загружает целевой браузер, а затем выполняется целевым браузером.

Постоянная XSS

Как следует из названия, постоянная XSS-атака сохраняется/постоянно сохраняется на самом уязвимом сервере. В отличие от отраженной атаки, когда вредоносный скрипт отправляется целью, пользователи уязвимого веб-сайта или веб-приложения могут быть атакованы во время их обычного взаимодействия с уязвимым сайтом/приложением.

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

Как видите, ключевым отличием отраженных и постоянных XSS-атак является то, что постоянные XSS-атаки рассматривают всех пользователей уязвимого сайта/приложения в качестве целей для атаки.

XSS на основе DOM

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

Простой пример атаки XSS на основе DOM может включать ту же настройку для приведенного выше примера отраженного сценария XSS. Злоумышленник создает URL-адрес с вредоносным скриптом в качестве «search_term» и запрашивает его у потенциальных целей.

Когда цель щелкает URL-адрес, ее браузер загружает страницу поиска по сайту и уязвимые клиентские сценарии обработки. Хотя «seach_term» по-прежнему предоставляется серверной части сайта в качестве параметра запроса для обработки, сам сайт не создает веб-страницу с внедренным вредоносным скриптом.

Вместо этого уязвимые клиентские сценарии сайта предназначены для локальной (в браузере цели) динамической замены значения условия поиска (т. е. вредоносного сценария) на отображаемой странице поиска цели, в результате чего браузер цели загружает и выполняет сценарий злоумышленника.

XSS-атаки на основе DOM подчеркивают тот факт, что XSS-уязвимости не ограничиваются серверным программным обеспечением.

Как предотвратить атаки с использованием межсайтовых сценариев

При наличии нескольких вариантов атак с использованием межсайтовых сценариев организациям необходимо знать, как надлежащим образом защитить себя и предотвратить будущие проблемы. За веб-сайтами становится все труднее строго следить, чем когда-либо прежде, из-за того, насколько они усложняются. Частота атак, вероятно, будет продолжать расти с течением времени.

Следующие рекомендации могут помочь защитить ваших пользователей от XSS-атак:

Дезинфекция пользовательского ввода:

• Проверить, чтобы перехватить потенциально вредоносный пользовательский ввод.
  

  This entry was posted in Популярное