Межсайтовый скриптинг
Межсайтовый скриптинг ( XSS ) — это тип уязвимости безопасности , которую можно обнаружить в некоторых веб-приложениях . XSS-атаки позволяют злоумышленникам внедрять клиентские сценарии в веб-страницы, просматриваемые другими пользователями. Уязвимость межсайтового сценария может быть использована злоумышленниками для обхода средств контроля доступа , таких как политика одного и того же происхождения . Во второй половине 2007 года XSSed зафиксировал 11 253 межсайтовые уязвимости, специфичные для сайта, по сравнению с 2 134 «традиционными» уязвимостями, зарегистрированными Symantec . [1] XSS-эффекты различаются по варьируются от незначительного неудобства до значительного риска для безопасности, в зависимости от конфиденциальности данных, обрабатываемых уязвимым сайтом, и характера любых мер по снижению безопасности, реализованных сетью владельца сайта .
OWASP считает термин «межсайтовый скриптинг» неправильным . Первоначально это была атака, которая использовалась для взлома данных на сайтах, но постепенно стала включать и другие формы атак с внедрением данных. [2]
Предыстория [ править ]
Безопасность в Интернете зависит от множества механизмов, включая базовую концепцию доверия, известную как политика одного и того же происхождения . Это означает, что если контенту с одного сайта (например, https://mybank.example1.com ) предоставлено разрешение на доступ к ресурсам (например, файлам cookie и т. д.) в веб-браузере, то контенту с любого URL-адреса с тем же (1) URI схема ftp, http или https), (2) имя хоста и (например , (3) номер порта будут использовать эти разрешения. Разрешения для контента с URL-адресов, где любой из этих трех атрибутов различен, должны быть предоставлены отдельно. [3]
Атаки с использованием межсайтовых сценариев используют известные уязвимости в веб-приложениях , их серверах или подключаемых системах, на которые они полагаются. Воспользовавшись одним из них, злоумышленники подключают вредоносный контент к контенту, доставляемому со взломанного сайта. Когда полученный объединенный контент поступает в веб-браузер на стороне клиента, он весь доставляется из доверенного источника и, таким образом, работает с разрешениями, предоставленными этой системе. Находя способы внедрения вредоносных сценариев в веб-страницы, злоумышленник может получить повышенные права доступа к конфиденциальному содержимому страницы, файлам cookie сеанса и разнообразной другой информации, которую браузер хранит от имени пользователя. Атаки с использованием межсайтовых сценариев представляют собой случай внедрения кода .
Инженеры по безопасности Microsoft ввели термин «межсайтовый скриптинг» в январе 2000 года. [4] Выражение «межсайтовый скриптинг» первоначально относилось к загрузке атакованного стороннего веб-приложения с несвязанного атакуемого сайта таким образом, что выполняется фрагмент JavaScript, подготовленный злоумышленником, в контексте безопасности целевого сайта. домена (используя отраженную или непостоянную XSS-уязвимость). Определение постепенно расширялось и охватывало другие режимы внедрения кода, включая постоянные и не-JavaScript-векторы (включая ActiveX , Java , VBScript , Flash или даже HTML- скрипты), вызывая некоторую путаницу у новичков в области информационной безопасности . [5]
Об уязвимостях XSS сообщалось и они использовались с 1990-х годов. В число известных сайтов, затронутых в прошлом, входят сайты социальных сетей Twitter. [6] и Фейсбук . [7] Ошибки межсайтового скриптинга с тех пор превзошли переполнение буфера и стали самой распространенной публично сообщаемой уязвимостью безопасности. [8] По оценкам некоторых исследователей в 2007 году, до 68% веб-сайтов, вероятно, открыты для XSS-атак. [9]
Типы [ править ]
Не существует единой стандартизированной классификации ошибок межсайтового скриптинга, но большинство экспертов различают как минимум два основных типа ошибок XSS: непостоянные и постоянные . Некоторые источники далее разделяют эти две группы на традиционные (вызванные недостатками кода на стороне сервера) и DOM основанные на (в коде на стороне клиента).
Нестойкий (отраженный) [ править ]
Непостоянная . (или отраженная ) уязвимость межсайтового скриптинга на сегодняшний день является самым основным типом веб-уязвимостей [10] Эти дыры появляются, когда данные, предоставленные веб-клиентом, [11] чаще всего в параметрах HTTP-запроса (например, отправка HTML-формы), немедленно используется серверными сценариями для анализа и отображения страницы результатов для этого пользователя без надлежащей очистки содержимого. [12]
Поскольку HTML-документы имеют плоскую последовательную структуру, в которой сочетаются операторы управления, форматирование и фактическое содержимое, любые непроверенные данные, предоставленные пользователем, включенные в результирующую страницу без надлежащего кодирования HTML, могут привести к внедрению разметки. [10] [12] Классическим примером потенциального вектора является поисковая система сайта: если кто-то ищет строку, строка поиска обычно дословно отображается на странице результатов, чтобы указать, что искалось. Если этот ответ не экранирует или не отклоняет управляющие символы HTML должным образом, возникнет ошибка межсайтового сценария. [13]
Отраженная атака обычно осуществляется по электронной почте или через нейтральный веб-сайт. Приманкой является невинный на вид URL-адрес, указывающий на доверенный сайт, но содержащий вектор XSS. Если доверенный сайт уязвим для вектора, щелчок по ссылке может привести к тому, что браузер жертвы выполнит внедренный скрипт.
Постоянный (или хранимый) [ править ]
Постоянная в (или хранимая ) уязвимость XSS — это более разрушительный вариант ошибки межсайтового скриптинга: она возникает, когда данные, предоставленные злоумышленником, сохраняются сервером, а затем постоянно отображаются на «обычных» страницах, возвращаемых другим пользователям в ходе обычного просмотра без надлежащего экранирования HTML. Классическим примером этого являются онлайн-доски объявлений, где пользователям разрешено публиковать сообщения в формате HTML, чтобы их могли прочитать другие пользователи. [12]
Например, предположим, что существует сайт знакомств, участники которого просматривают профили других участников, чтобы посмотреть, интересны ли они. По соображениям конфиденциальности этот сайт скрывает настоящее имя и адрес электронной почты каждого. Они хранятся на сервере в секрете. участника Настоящее имя и адрес электронной почты отображаются в браузере только тогда, когда участник вошел в систему и он не видит никого другого.
Предположим, что злоумышленник Мэллори присоединяется к сайту и хочет выяснить настоящие имена людей, которых она видит на сайте. Для этого она пишет сценарий, предназначенный для запуска из браузеров других пользователей, когда они посещают ее профиль. Затем сценарий отправляет быстрое сообщение на собственный сервер, который собирает эту информацию.
Для этого на вопрос «Опишите свое идеальное первое свидание» Мэллори дает короткий ответ (чтобы выглядеть нормально), но текст в конце ее ответа — это ее сценарий для кражи имен и электронных писем. Если сценарий заключен внутри <script>элемент, он не будет отображаться на экране. Затем предположим, что Боб, участник сайта знакомств, зашел в профиль Мэллори, где есть ее ответ на вопрос о первом свидании. Ее сценарий автоматически запускается браузером и крадет копию настоящего имени и адреса электронной почты Боба прямо с его собственного компьютера.
Постоянные XSS-уязвимости могут быть более серьезными, чем другие типы, поскольку вредоносный сценарий злоумышленника обрабатывается автоматически, без необходимости индивидуально нацеливаться на жертв или заманивать их на сторонний веб-сайт. В частности, в случае с сайтами социальных сетей код будет дополнительно спроектирован таким образом, чтобы он мог самостоятельно распространяться между учетными записями, создавая тип клиентского червя . [14]
Методы инъекции могут сильно различаться; в некоторых случаях злоумышленнику может даже не потребоваться напрямую взаимодействовать с самой веб-функцией, чтобы воспользоваться такой дырой. Любые данные, полученные веб-приложением (по электронной почте, системные журналы, мгновенные сообщения и т. д.), которые могут контролироваться злоумышленником, могут стать вектором внедрения.
DOM Уязвимости на стороне сервера и основе на
XSS-уязвимости изначально были обнаружены в приложениях, выполнявших всю обработку данных на стороне сервера. Пользовательский ввод (включая вектор XSS) будет отправлен на сервер, а затем отправлен обратно пользователю в виде веб-страницы. Потребность в улучшении пользовательского опыта привела к популярности приложений, в которых большая часть логики представления (возможно, написанной на JavaScript ) работала на стороне клиента и извлекала данные по требованию с сервера с помощью AJAX .
Поскольку код JavaScript также обрабатывал вводимые пользователем данные и отображал их в содержимом веб-страницы, начал появляться новый подкласс отраженных XSS-атак, который назывался DOM межсайтовым скриптингом на основе . При XSS-атаке на основе DOM вредоносные данные не затрагивают веб-сервер. Скорее, это отражается в коде JavaScript, полностью на стороне клиента. [15]
Примером XSS-уязвимости на основе DOM является ошибка, обнаруженная в 2011 году в ряде плагинов jQuery . [16] Стратегии предотвращения XSS-атак на основе DOM включают меры, очень похожие на традиционные стратегии предотвращения XSS, но реализованные в коде JavaScript и содержащиеся в веб-страницах (т. е. проверка ввода и экранирование). [17] Некоторые фреймворки JavaScript имеют встроенные средства противодействия этому и другим типам атак — например, AngularJS . [18]
Самостоятельный XSS [ править ]
Self-XSS — это форма XSS-уязвимости, которая использует социальную инженерию , чтобы обманом заставить жертву выполнить вредоносный код JavaScript в своем браузере. Хотя технически это не настоящая XSS-уязвимость, поскольку она основана на социальной инженерии пользователя для выполнения кода, а не на недостатке уязвимого веб-сайта, позволяющем злоумышленнику это сделать, она по-прежнему представляет те же риски, что и обычная XSS-уязвимость, если правильно исполнено. [19]
Мутировавший XSS (mXSS) [ править ]
Мутировавший XSS происходит, когда злоумышленник внедряет что-то, что кажется безопасным, но переписывается и модифицируется браузером во время анализа разметки. Это чрезвычайно затрудняет обнаружение или очистку логики приложения веб-сайта. Примером является перебалансировка незакрытых кавычек или даже добавление кавычек к некавычным параметрам в семействе шрифтов CSS.
Профилактические меры [ править ]
Контекстное выходное кодирование/экранирование строкового ввода [ править ]
Существует несколько схем экранирования, которые можно использовать в зависимости от того, где в HTML-документе необходимо поместить ненадежную строку, включая кодирование объектов HTML, экранирование JavaScript, экранирование CSS и кодирование URL-адреса (или процентов) . [20] Большинство веб-приложений, которым не требуется принимать расширенные данные, могут использовать экранирование, чтобы в значительной степени устранить риск XSS-атак довольно простым способом.
Выполнение кодирования HTML-объектов только с пятью значащими символами XML не всегда достаточно для предотвращения многих форм XSS-атак, обычно проще использовать библиотеки кодирования безопасности. [20]
Некоторые системы веб-шаблонов понимают структуру создаваемого ими HTML-кода и автоматически выбирают подходящий кодировщик. [21] [22] [23]
Безопасная проверка ненадежного ввода HTML [ править ]
Многие операторы определенных веб-приложений (например, форумов и веб-почты) позволяют пользователям использовать ограниченный набор HTML-разметки. Принимая HTML-ввод от пользователей (скажем, <b>very</b> large), выходное кодирование (например, <b>very</b> large) будет недостаточно, поскольку вводимые пользователем данные должны отображаться браузером в формате HTML (поэтому они отображаются как « очень большие», а не «<b>очень</b> большие»). Остановить XSS-атаку при приеме HTML-ввода от пользователей в этой ситуации гораздо сложнее. Ненадежный ввод HTML должен быть пропущен через механизм очистки HTML , чтобы гарантировать, что он не содержит код XSS.
Многие проверки основаны на анализе (занесении в черный список) конкретных HTML-тегов, находящихся под угрозой, таких как тег iframe , ссылка и тег сценария.
У этого подхода есть несколько проблем: например, иногда могут быть опущены, казалось бы, безобидные теги, что при правильном использовании все равно может привести к XSS.
Другой популярный метод — исключить вводимые пользователем символы «and», однако это можно обойти, поскольку полезные данные можно скрыть с помощью обфускации .
Безопасность файлов cookie [ править ]
Помимо фильтрации контента, широко используются и другие несовершенные методы борьбы с межсайтовым скриптингом. Одним из примеров является использование дополнительных мер безопасности при аутентификации пользователей на основе файлов cookie . Многие веб-приложения используют файлы cookie сеанса для аутентификации между отдельными HTTP-запросами, а поскольку клиентские сценарии обычно имеют доступ к этим файлам cookie, простые XSS-эксплойты могут украсть эти файлы cookie. [24] Чтобы смягчить эту конкретную угрозу (но не проблему XSS в целом), многие веб-приложения привязывают файлы cookie сеанса к IP-адресу пользователя, который первоначально вошел в систему, а затем разрешают только этому IP использовать этот файл cookie. [25] Это эффективно в большинстве ситуаций (если злоумышленник использует только файл cookie), но, очевидно, не работает в ситуациях, когда злоумышленник находится за тем же NAT -адресом или веб-прокси , что и жертва, или жертва меняет свой мобильный IP-адрес. . [25]
Файл cookie только для HTTP [ править ]
Еще одно средство защиты, присутствующее в Internet Explorer (начиная с версии 6), Firefox (начиная с версии 2.0.0.5), Safari (начиная с версии 4), Opera (начиная с версии 9.5) и Google Chrome , — это флаг HttpOnly , который позволяет веб-серверу устанавливать файл cookie, недоступный для клиентских сценариев. Несмотря на свою полезность, эта функция не может ни полностью предотвратить кражу файлов cookie, ни предотвратить атаки внутри браузера. [26]
Отключение скриптов [ править ]
Хотя разработчикам Web 2.0 и Ajax требуется использование JavaScript, [27] некоторые веб-приложения написаны так, чтобы обеспечить работу без необходимости использования каких-либо клиентских сценариев. [28] Это позволяет пользователям, если они захотят, отключить сценарии в своих браузерах перед использованием приложения. Таким образом, даже потенциально вредоносные клиентские сценарии могут быть вставлены на страницу в неэкранированном виде, и пользователи не будут подвержены XSS-атакам.
Некоторые браузеры или плагины браузера можно настроить на отключение клиентских сценариев для каждого домена. Этот подход имеет ограниченную ценность, если создание сценариев разрешено по умолчанию, поскольку он блокирует плохие сайты только после того, как пользователь узнает, что они плохие, а это уже слишком поздно. Функциональность, которая по умолчанию блокирует все сценарии и внешние включения, а затем позволяет пользователю включать их для каждого домена, является более эффективной. Это было возможно в течение долгого времени в Internet Explorer (начиная с версии 4) путем настройки так называемых «Зон безопасности». [29] и в Opera (начиная с версии 9) с помощью «Настройки сайта». [30] Решением для Firefox и других Gecko браузеров на базе является надстройка NoScript с открытым исходным кодом , которая, помимо возможности включения сценариев для каждого домена, обеспечивает некоторую защиту XSS, даже если сценарии включены. [31]
Самая серьезная проблема с блокировкой всех скриптов на всех веб-сайтах по умолчанию — это существенное снижение функциональности и скорости реагирования (сценарии на стороне клиента могут выполняться намного быстрее, чем сценарии на стороне сервера, поскольку им не требуется подключение к удаленному серверу и странице или фрейму) . перезагружать не нужно). [32] Другая проблема с блокировкой скриптов заключается в том, что многие пользователи этого не понимают и не знают, как правильно защитить свои браузеры. Еще одним недостатком является то, что многие сайты не работают без сценариев на стороне клиента, что вынуждает пользователей отключать защиту этого сайта и открывает свои системы для уязвимостей. [33] Расширение NoScript для Firefox позволяет пользователям выборочно разрешать использование сценариев на одной странице и запрещать использование других сценариев на той же странице. Например, могут быть разрешены сценарии с сайта example.com, а сценарии с сайта Advertisingagency.com, пытающиеся запуститься на той же странице, могут быть запрещены. [34]
Выборочное отключение скриптов [ править ]
Политика безопасности контента [ править ]
Политика безопасности контента (CSP) позволяет HTML-документам отключать некоторые сценарии, оставляя другие включенными. [35] Браузер проверяет каждый скрипт на соответствие политике, прежде чем решить, запускать ли его. Пока политика разрешает только надежные сценарии и запрещает динамическую загрузку кода , браузер не будет запускать программы от ненадежных авторов независимо от структуры HTML-документа.
Современные политики CSP позволяют использовать одноразовые номера для пометки сценариев в HTML-документе как безопасных для запуска вместо того, чтобы полностью отделять политику от содержимого страницы. [36] [37] Пока доверенные одноразовые номера появляются только в заслуживающих доверия сценариях, браузер не будет запускать программы от ненадежных авторов. Некоторые крупные поставщики приложений сообщают об успешном развертывании политик на основе nonce. [38] [39]
Новые оборонительные технологии [ править ]
Доверенные типы [40] изменяет веб-API, чтобы проверить, что значения отмечены как доверенные. Пока программы используют только надежные значения, злоумышленник, контролирующий строковое значение JavaScript , не может вызвать XSS. Доверенные типы предназначены для проверки синими командами .
Другой подход защиты заключается в использовании автоматизированных инструментов, которые удаляют вредоносный код XSS на веб-страницах. Эти инструменты используют методы статического анализа и/или сопоставления с образцом для выявления потенциально вредоносных кодов и защиты их с помощью таких методов, как экранирование. [41]
Параметр файла cookie SameSite [ изменить ]
Если файл cookie установлен с помощью SameSite=Strictпараметр, он удаляется из всех запросов между источниками. При установке с SameSite=Lax, он удаляется из всех небезопасных запросов между источниками (то есть запросов, отличных от GET, OPTIONS и TRACE, которые имеют семантику только для чтения). [42] Эта функция реализована в Google Chrome с версии 63 и Firefox с версии 60. [43]
См. также [ править ]
- Безопасность веб-приложений
- Интернет-безопасность
- Внешний объект XML
- Безопасность браузера
- Metasploit Project , инструмент тестирования на проникновение с открытым исходным кодом, который включает тесты на XSS.
- w3af с открытым исходным кодом. — сканер безопасности веб-приложений
- DOMPurify, бесплатная библиотека кода с открытым исходным кодом от Cure53, предназначенная для снижения восприимчивости к XSS-уязвимостям на веб-сайтах.
- Междокументный обмен сообщениями
- Сэми (компьютерный червь)
- Проверка параметров
Ссылки [ править ]
- ^ «Отчет об угрозах интернет-безопасности Symantec: тенденции за июль – декабрь 2007 г. (краткое содержание)» (PDF) . Яху . Апрель 2008 г. стр. 1–3. Архивировано (PDF) из оригинала 25 июня 2008 г. Проверено 1 января 2024 г.
- ^ «Предотвращение межсайтового выполнения сценариев — серия шпаргалок OWASP» . ОВАСП . Проверено 19 марта 2003 г.
- ^ «Та же политика происхождения — Web Security. W3.org» . Проверено 4 ноября 2014 г.
- ^ «шлак» на MSDN (15 декабря 2009 г.). «С 10-летием межсайтового скриптинга!» . Проверено 9 февраля 2023 г.
16 января 2000 года следующие имена были предложены и обсуждались среди небольшой группы инженеров по безопасности Microsoft: [...] На следующий день был достигнут консенсус – Межсайтовый скриптинг.
- ^ Гроссман, Иеремия (30 июля 2006 г.). «Истоки межсайтового скриптинга (XSS)» . Проверено 15 сентября 2008 г.
- ^ Артур, Чарльз (21 сентября 2010 г.). «Пользователи Твиттера, включая Сару Браун, пострадали от злонамеренной хакерской атаки» . Хранитель . Проверено 21 сентября 2010 г.
- ^ Лейден, Джон (23 мая 2008 г.). «В Facebook обнаружена ошибка XSS» . Регистр . Проверено 28 мая 2008 г.
- ^ Кристи, Стив; Мартин, Роберт А. (22 мая 2007 г.). «Распределение типов уязвимостей в CVE (версия 1.1)» . Корпорация МИТЕР . Проверено 7 июня 2008 г.
- ^ Беринато, Скотт (1 января 2007 г.). «Раскрытие уязвимостей программного обеспечения: пугающий эффект» . ОГО . СХО Медиа . п. 7. Архивировано из оригинала 18 апреля 2008 года . Проверено 7 июня 2008 г.
- ^ Перейти обратно: а б Пако, Хоуп; Вальтер, Бен (2008). Справочник по тестированию веб-безопасности . Севастополь, Калифорния: O'Reilly Media, Inc. с. 128 . ISBN 978-0-596-51483-9 .
- ^ Хидара, Исато; Султан, Абу Бакар, Мэриленд; Зулзалил, Хазура; Адмодисастро, Новия (1 февраля 2015 г.). «Текущее состояние исследований межсайтового скриптинга (XSS) – систематический обзор литературы» . Информационные и программные технологии . 58 : 170–186. дои : 10.1016/j.infsof.2014.07.010 .
- ^ Перейти обратно: а б с «Межсайтовый скриптинг» . Консорциум по безопасности веб-приложений. 2005 . Проверено 28 мая 2008 г.
- ^ Гроссман, Иеремия; Хансен, Роберт; Фоги, Сет; Петков, Петко Д.; Рейгер, Антон (2007). XSS-атаки: использование межсайтовых сценариев и защита (аннотация) . Сингресс. стр. 70, 156. ISBN. 978-1-59749-154-9 . Проверено 28 мая 2008 г.
- ^ Вирусы и черви в Алкорн, Уэйд (27 сентября 2005 г.). «Вирус межсайтового скриптинга» . BindShell.net. Архивировано из оригинала 16 мая 2008 года . Проверено 27 мая 2008 г. и Гроссман, Иеремия (ноябрь 2020 г.). «Черви и вирусы с межсайтовым скриптингом: надвигающаяся угроза и лучшая защита» . Уайтхэт охрана. п. 20 . Проверено 6 июня 2008 г. [ постоянная мертвая ссылка ]
- ^ «XSS на основе DOM» . ОВАСП.
- ^ «Ошибка JQuery № 9521» . 2011.
- ^ «Шпаргалка по предотвращению XSS на основе DOM» . ОВАСП.
- ^ «Строгое контекстное экранирование» . Угловой.js.
- ^ «Мошенничество с Self-XSS в Facebook пытается обманом заставить пользователей взломать себя» . www.majorgeeks.com . 29 июля 2014 года . Проверено 20 сентября 2016 г.
- ^ Перейти обратно: а б Уильямс, Джефф (19 января 2009 г.). «Шпаргалка по предотвращению XSS (межсайтового скриптинга)» . ОВАСП. Архивировано из оригинала 18 марта 2017 года . Проверено 4 февраля 2010 г.
- ^ «шаблон — язык программирования Go» . golang.org . Проверено 1 мая 2019 г.
- ^ «Разработчики Google» . Разработчики Google . Проверено 1 мая 2019 г.
- ^ "доверенные-типы-плагинов-мопсов" . НПМ . Проверено 1 мая 2019 г.
- ^ Шарма, Ананд (3 февраля 2004 г.). «Предотвратите атаку с использованием межсайтовых сценариев» . ИБМ . Проверено 29 мая 2008 г.
- ^ Перейти обратно: а б «ModSecurity: Особенности: Универсальная защита PDF от XSS» . Нарушение безопасности. Архивировано из оригинала 23 марта 2008 года . Проверено 6 июня 2008 г.
- ^ «Ajax и Mashup Security» . Альянс ОпенАякс. Архивировано из оригинала 3 апреля 2008 года . Проверено 9 июня 2008 г.
- ^ О'Рейли, Тим (30 сентября 2005 г.). «Что такое Веб 2.0» . О'Рейли Медиа. стр. 4–5 . Проверено 4 июня 2008 г.
- ^ «Страница должна работать, даже если в ухудшенном виде, без JavaScript». в Заметти, Фрэнк (16 апреля 2007 г.). Практический JavaScript, сценарии DOM и проекты Ajax через Amazon Reader . Апресс. п. 36. ISBN 978-1-59059-816-0 . Проверено 4 июня 2008 г.
- ^ «Как использовать зоны безопасности в Internet Explorer» . Майкрософт. 18 декабря 2007 года . Проверено 4 июня 2008 г.
- ^ Ложь, Хокон Виум (7 февраля 2006 г.). «Обзор технологий Opera 9 2» . Программное обеспечение Опера. Архивировано из оригинала 17 мая 2008 года . Проверено 4 июня 2008 г.
- ^ «НетСкрипта» . Мозилла. 30 мая 2008 года . Проверено 4 июня 2008 г. и Могул, Рич (18 марта 2008 г.). «Следует ли пользователям Mac использовать антивирусное программное обеспечение?» . TidBITS . Издательство TidBITS . Проверено 4 июня 2008 г.
- ^ « Использование событий на стороне клиента» в Руководстве программиста DataWindow» . Сибаза. Март 2003. Архивировано из оригинала 18 июня 2008 года . Проверено 4 июня 2008 г.
- ^ 73% сайтов использовали JavaScript в конце 2006 г., в « Большинство веб-сайтов не работают» . Новости BBC . 6 декабря 2006 года . Проверено 4 июня 2008 г.
- ^ «Функции NoScript» . Проверено 7 марта 2009 г.
- ^ «Политика безопасности контента, уровень 3» . www.w3.org . Проверено 1 мая 2019 г.
- ^ «Могу ли я использовать... Таблицы поддержки HTML5, CSS3 и т. д.» . caniuse.com . Проверено 1 мая 2019 г.
- ^ «Строгий CSP — Политика безопасности контента» . csp.withgoogle.com . Проверено 1 мая 2019 г.
- ^ «Как Google использует политику безопасности контента для устранения веб-ошибок» . ЭНЕДЕЛЯ . 22 апреля 2019 г. Проверено 1 мая 2019 г.
- ^ Ахаве, Девдатта (21 сентября 2015 г.). «[CSP] Об отчетности и фильтрации» . Дропбокс . Проверено 1 января 2024 г.
- ^ «Спецификация доверенных типов незавершена» . wicg.github.io . Проверено 1 мая 2019 г.
- ^ Л.К. Шар и Х.Б.К. Тан, «Автоматическое удаление уязвимостей межсайтового скриптинга в веб-приложениях», Information and Software Technology, vol. 54, (5), стр. 467-478, 2012.
- ^ Марк, Гудвин; Майк, Уэст (6 апреля 2016 г.). «Файлы cookie того же сайта» . www.tools.ietf.org . Проверено 4 мая 2018 г.
- ^ «Могу ли я использовать... Таблицы поддержки HTML5, CSS3 и т. д.» . caniuse.com . Проверено 4 мая 2018 г.
Дальнейшее чтение [ править ]
- Маккензи, Томас. «ScriptAlert1.com — краткое объяснение межсайтовых сценариев на нескольких языках» . Проверено 24 октября 2015 г.
- «Предотвратить XSS в ASP.NET стало проще» . Запри меня | Безопасность для повседневного разработчика . 6 февраля 2015 г. Проверено 24 октября 2015 г.
- «Межсайтовый скриптинг» . Консорциум по безопасности веб-приложений . 13 октября 2005 года . Проверено 24 октября 2015 г.
Внешние ссылки [ править ]
- OWASP : XSS , Тестирование XSS , Проверка кода на XSS
- XSSed: база данных веб-сайтов, уязвимых для атак с использованием межсайтовых сценариев
