Internet Explorer изменил эту страницу, чтобы предотвратить выполнение межсайтовых сценариев

Обновлено: 21.11.2024

Команда Internet Explorer приложила значительные усилия, чтобы сделать Internet Explorer 8 Beta 2 самой безопасной версией на сегодняшний день.

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

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

Угрозы веб-приложений

Фильтр XSS

XSS-атаки стали наиболее распространенным классом программных уязвимостей.

Новый XSS-фильтр работает как компонент Internet Explorer 8 Beta 2 и обеспечивает просмотр всех запросов и ответов, проходящих через браузер. Когда эвристика фильтра обнаруживает сценарий, отправленный в межсайтовом запросе, он идентифицирует и нейтрализует сценарий, если он впоследствии воспроизводится в ответе сервера в формате HTML.

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

Рис. 1. Панель информации уведомляет пользователей, когда XSS-фильтр изменяет страницу.

Безопасные мэшапы

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

Чтобы помочь разработчикам создавать более безопасные гибридные приложения, в Internet Explorer 8 Beta 2 включена поддержка функции обмена сообщениями между документами HTML 5. Новый вызов postMessage позволяет IFRAME обмениваться данными более безопасно, сохраняя при этом изоляцию DOM. Фреймы, взаимодействующие через postMessage, не получают прямого доступа к DOM, а могут отправлять друг другу только строковые сообщения. Каждое сообщение четко определяет его источник, а параметр varTargetUri помогает гарантировать, что сообщения не будут отправлены по ошибке.

Несмотря на то, что HTML 5 Cross-Document Messaging и XDomainRequest помогают создавать безопасные гибридные приложения, серьезная угроза сохраняется. При использовании любого из методов строковые данные, полученные из стороннего фрейма или сервера, могут содержать вредоносный скрипт. Если вызывающая страница вслепую вставит строку в свою DOM, произойдет атака путем внедрения скрипта. Чтобы помочь устранить эту угрозу, можно использовать две новые технологии в сочетании с этими механизмами междоменной связи для смягчения атак с внедрением скриптов.

Безопасные мэшапы: очистка HTML

Internet Explorer 8 Beta 2 предоставляет новый метод для объекта окна с именем toStaticHTML . Когда этой функции передается строка HTML, все потенциально исполняемые конструкции скрипта удаляются перед возвратом строки. Внутри эта функция основана на тех же технологиях, что и упомянутая ранее библиотека Microsoft Anti-Cross Site Scripting Library на стороне сервера. Так, например, вы можете использовать toStaticHTML, чтобы убедиться, что HTML, полученный от вызова postMessage HTML 5, не может выполнять сценарий, но может использовать преимущества базового форматирования:

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

Безопасные мэшапы: очистка JSON

Обозначение объектов JavaScript (JSON) — это упрощенная строковая сериализация объекта JavaScript, которая часто используется для передачи данных между компонентами мэшапа. К сожалению, многие гибридные приложения используют JSON небезопасно, полагаясь на метод JavaScript eval для «оживления» строк JSON обратно в объекты JavaScript, потенциально выполняя функции скрипта в процессе. Разработчики, заботящиеся о безопасности, вместо этого используют анализатор JSON, чтобы гарантировать, что объект JSON не содержит исполняемый скрипт, но это снижает производительность. Internet Explorer 8 Beta 2 реализует предложение ECMAScript 3.1 для встроенных функций обработки JSON (в котором используется API json2.js Дугласа Крокфорда).

DEP/NX помогает предотвратить атаки, предотвращая запуск кода в памяти, помеченной как неисполняемая.

Метод JSON.stringify принимает объект скрипта и возвращает строку JSON, а метод JSON.Метод parse принимает строку и безопасно восстанавливает ее в объект JavaScript. Новые нативные методы JSON основаны на том же коде, который используется самим обработчиком сценариев, и, таким образом, значительно повысили производительность по сравнению с ненативными реализациями.

Если результирующий объект содержит строки, предназначенные для внедрения в модель DOM, для предотвращения внедрения скрипта можно использовать ранее описанную функцию toStaticHTML.

В листинге 1 используется очистка как JSON, так и HTML для предотвращения внедрения скрипта, даже если служба погоды возвращает вредоносный ответ, содержащий скрипт:

Листинг 1. Использование очистки JSON и HTML для предотвращения внедрения скриптов

Изменения в обработке MIME

Каждый тип файла, доставленного с веб-сервера, имеет связанный с ним тип MIME (также называемый «типом содержимого»), описывающий характер содержимого (например, изображение, текст, приложение и т. д.).

Для борьбы с этой угрозой мы внесли ряд изменений в код определения MIME-типа Internet Explorer 8 Beta 2.

Обработка MIME: ограничение изображений

Во-первых, Internet Explorer 8 (бета-версия 2) предотвращает преобразование файлов с типами контента image/* в HTML+script. Даже если файл содержит сценарий, если сервер объявляет, что это изображение, IE не будет запускать встроенный сценарий. Это изменение смягчает вектор атаки, связанный с обменом изображениями, без изменения кода со стороны сервера. Мы смогли внести это изменение по умолчанию с минимальным влиянием на совместимость только потому, что серверы редко намеренно отправляют HTML или скрипты с типом содержимого image/*.

Обработка MIME: блокировка прослушивания

В Internet Explorer 7 текст интерпретируется как HTML, как показано на рис. 2. В Internet Explorer 8 Beta 2 благодаря параметру nosniff страница отображается как обычный текст, как показано на рис. 3.

Рисунок 2. Анализ MIME приводит к тому, что эта страница отображается как HTML.
Рис. 3. Когда сервер отказывается от прослушивания MIME, страница отображается как обычный текст.

Параметр nosniff позволяет серверам контролировать MIME-сниффинг, позволяя серверам, на которых размещается ненадежный контент, надежно контролировать интерпретацию этого контента IE, помогая предотвратить атаки с внедрением скриптов.

Обработка MIME: принудительное сохранение

Наконец, для веб-приложений, которым необходимо обслуживать ненадежные HTML-файлы, мы представили механизм, помогающий предотвратить угрозу безопасности вашего сайта со стороны ненадежного содержимого. Когда новый заголовок X-Download-Options присутствует со значением noopen , Internet Explorer запрещает пользователю напрямую открывать загружаемый файл; вместо этого они должны сначала сохранить файл локально. Когда локально сохраненный файл позже открывается, он больше не выполняется в контексте безопасности вашего сайта, что помогает предотвратить внедрение скриптов.

В совокупности новые API-интерфейсы междоменной связи, API-интерфейсы очистки контента и улучшения анализа MIME позволяют создавать значительно более безопасные веб-приложения.

Угрозы компьютерам пользователей

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

ActiveX для каждого сайта — это защитный механизм, помогающий предотвратить злонамеренное переназначение элементов управления

В Internet Explorer 7 были сделаны значительные инвестиции в эту область, включая защищенный режим, поддержку ActiveX и блокировку зон. В ответ на усиление защиты самого браузера злоумышленники все больше внимания уделяют взлому уязвимых надстроек браузера. В Internet Explorer 8 (бета-версия 2) мы внесли ряд изменений, направленных на повышение безопасности надстроек, сокращение уязвимой зоны и улучшение взаимодействия с разработчиками и пользователями.

Предотвращение выполнения данных (DEP/NX)

В Internet Explorer 7 в Windows Vista появился параметр Панели управления Интернетом, который по умолчанию не используется по умолчанию: «Включить защиту памяти, чтобы предотвратить онлайн-атаки». Этот параметр также называется предотвращением выполнения данных (DEP) или запретом на выполнение (NX).

Мы включили этот параметр по умолчанию для Internet Explorer 8 Beta 2 в Windows Server 2008, Windows Vista с пакетом обновления 1 (SP1) и Windows XP с пакетом обновления 3 (SP3).

DEP/NX помогает предотвратить атаки, предотвращая выполнение кода в памяти, помеченной как неисполняемая. DEP/NX в сочетании с другими технологиями, такими как рандомизация адресного пространства (ASLR), усложняют злоумышленникам использование определенных типов уязвимостей, связанных с памятью, таких как переполнение буфера. Лучше всего то, что защита распространяется как на Internet Explorer, так и на загружаемые им надстройки. Для обеспечения этой защиты не требуется никаких дополнительных действий пользователя, и не вводятся новые подсказки.

Для Internet Explorer 7 DEP/NX был отключен по умолчанию из соображений совместимости.Несколько популярных дополнений были несовместимы с DEP/NX и аварийно завершали работу, когда Internet Explorer загружал их с включенным DEP/NX. Наиболее распространенной проблемой было то, что эти надстройки были созданы с использованием более старой версии библиотеки ATL. До версии 7.1 SP1 в ATL использовался динамически генерируемый код, что было несовместимо с DEP/NX.

Несмотря на то, что разработчики многих популярных надстроек с тех пор выпустили обновленные расширения, совместимые с DEP/NX, некоторые надстройки могут не обновляться до выхода Internet Explorer 8 Beta 2. К счастью, в Windows Server 2008 и последние пакеты обновлений Windows были добавлены новые API-интерфейсы DEP/NX, которые позволяют использовать DEP/NX, сохраняя при этом совместимость со старыми версиями ATL. Эти новые API позволяют Internet Explorer подключаться к DEP/NX, не вызывая сбоев надстроек, созданных с помощью более старых версий ATL.

Локальные администраторы могут управлять DEP/NX, запустив Internet Explorer от имени администратора и сняв флажок "Инструменты" > "Свойства обозревателя" > "Дополнительно" > "Включить защиту памяти для предотвращения онлайн-атак".

Вы можете увидеть, какие процессы защищены DEP/NX, на вкладке «Процессы» диспетчера задач Windows Vista; в более ранних версиях Windows вы можете использовать Process Explorer. В любом случае убедитесь, что флажок «Предотвращение выполнения данных» установлен в меню «Вид» > «Выбрать столбцы».

Если вы создаете надстройки для Internet Explorer, вы можете обеспечить плавное обновление пользователей до Internet Explorer 8 Beta 2, выполнив следующие действия:

ActiveX для каждого сайта

Ключевым средством сокращения уязвимостей, которое мы сделали для Internet Explorer 8 Beta 2, является «ActiveX для каждого сайта», защитный механизм, помогающий предотвратить злонамеренное переназначение элементов управления.

Когда пользователь переходит на веб-сайт, содержащий элемент управления ActiveX, Internet Explorer 8 (бета-версия 2) выполняет ряд проверок, в том числе определяет, где разрешен запуск элемента управления.

Если элемент управления установлен, но ему не разрешено работать на конкретном веб-сайте, появляется информационная панель (рис. 4), в которой пользователю задается вопрос, следует ли разрешить запуск элемента управления на текущем веб-сайте.

Рисунок 4. Информационная панель ActiveX для каждого сайта позволяет пользователям выбирать, где надстройка может запускаться.

Конечные пользователи могут изменять свои настройки ActiveX для каждого сайта с помощью диалогового окна "Управление надстройками". ИТ-специалисты, администрирующие систему компьютеров, на которых работает Internet Explorer 8 Beta 2, могут предварительно настроить разрешенные элементы управления и связанные с ними домены. Такие параметры можно настроить с помощью групповой политики.

Если ваш элемент управления ActiveX предназначен для использования только на вашем веб-сайте и вы не хотите разрешать переопределение пользователем, вам следует использовать шаблон Microsoft SiteLock ATL, чтобы предотвратить использование вашего элемента управления на других веб-сайтах. Использование шаблона SiteLock гарантирует, что ваш элемент управления не может быть злонамеренно использован другими веб-сайтами.

Если элемент управления ActiveX соответствует требованиям для помещения себя в список PreApproved и сделал это, перечислив CLSID элемента управления в следующем разделе реестра, то ограничение ActiveX для каждого сайта не применяется к этому элементу управления.

Запрос протокола приложения

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

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

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

Чтобы гарантировать, что пользователь по-прежнему контролирует работу в Интернете, Internet Explorer 8 (бета-версия 2) теперь будет выводить запрос перед запуском протоколов приложений, как показано на рис. 5.

Рис. 5. Internet Explorer теперь выдает запрос перед запуском обработчиков протоколов приложений.

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

Обзор защищенного режима

Защищенный режим, представленный в Internet Explorer 7 в Windows Vista, помогает снизить серьезность угроз как для Internet Explorer, так и для расширений, работающих в Internet Explorer, помогая предотвратить автоматическую установку вредоносного кода даже при наличии уязвимостей в программном обеспечении (рис. 6). . Для Internet Explorer 8 Beta 2 мы внесли ряд улучшений API в защищенный режим, чтобы упростить разработчикам надстроек управление экземплярами браузера в защищенном режиме и взаимодействие с ними.

Рис. 6. В Internet Explorer 7 появилась архитектура защищенного режима, которая помогает предотвратить автоматическую установку вредоносного кода.

Улучшения защищенного режима: событие NewProcess

К сожалению, когда приложению необходимо программно запускать, взаимодействовать и поддерживать процесс Internet Explorer 7 в защищенном режиме, оно не может легко сделать это. Когда программа вызывает CoCreateInstance Internet Explorer, COM-сервер Internet Explorer запускается с уровнем целостности программы. Если клиентское приложение предоставляет URL-адрес для навигации, сервер Internet Explorer перенаправит навигацию в процесс Internet Explorer в защищенном режиме, и впоследствии никакая информация не будет возвращена управляющему клиентскому приложению. Указатель интерфейса клиента перестает функционировать, и клиент больше не может взаимодействовать с фактическим процессом Internet Explorer, выполняющим навигацию (рис. 7).

Рис. 7. Перенаправление переходов в защищенный режим затрудняет мониторинг экземпляров Internet Explorer.

Архитектура Internet Explorer 8 Beta 2 решает эту проблему благодаря недавно добавленному событию NewProcess в интерфейсе DWebBrowserEvents2.

Это событие запускается перед перенаправлением в экземпляр защищенного режима. Это позволяет клиентскому приложению отслеживать новый экземпляр с помощью указателя pWB2 или может отменить навигацию, установив для параметра Cancel значение VARIANT_TRUE .

Усовершенствования защищенного режима: совместное использование файлов cookie

Защищенный режим отключен в зоне интрасети

Для повышения производительности и снижения риска совместимости приложений для организаций, использующих сайты для бизнеса на основе ActiveX, зона интрасети будет работать вне защищенного режима в Internet Explorer 8 Beta 2.

В Internet Explorer 7 защищенный режим был включен в зоне интрасети только для удобства пользователей. При входе в защищенный режим или выходе из него Internet Explorer 7 был вынужден создать новый процесс и, следовательно, новое окно, что серьезно раздражало пользователей. Слабосвязанная архитектура Internet Explorer 8 Beta 2 (рис. 8) позволяет размещать вкладки защищенного режима и незащищенного режима в одном окне браузера, устраняя необходимость запуска нового окна. Разумеется, пользователи Internet Explorer 8 Beta 2 и администраторы домена могут при желании повторно включить защищенный режим для зоны интрасети.

Рис. 8. Новая модель процесса Internet Explorer 8 Beta 2.

Контроль загрузки файлов

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

Чтобы блокировать атаки, основанные на «краже» нажатий клавиш, чтобы тайно заставить пользователя ввести путь к локальному файлу в элемент управления (который позже тайно отправляется), поле редактирования «Путь к файлу» теперь доступно только для чтения (рис. 9). Пользователь должен явно выбрать файл для загрузки в диалоговом окне «Обзор файлов».

Рис. 9. Поле редактирования File Upload Control теперь доступно только для чтения.

Кроме того, для URLAction «Включить путь к локальному каталогу при загрузке файлов» для зоны Интернета установлено значение «Отключить». Это изменение предотвращает утечку потенциально конфиденциальной информации о локальной файловой системе в Интернет. Например, вместо того, чтобы отправлять полный путь:

Internet Explorer 8 Beta 2 теперь будет отправлять только имя файла

Заключение

Безопасность — это основная характеристика надежного просмотра, и Internet Explorer 8 (бета-версия 2) содержит значительные улучшения, отвечающие меняющейся среде веб-безопасности. Команда Internet Explorer работает над тем, чтобы помочь защитить пользователей и предоставить новые способы повышения безопасности веб-приложений.

Internet Explorer 8 Beta 2 теперь выдает запрос перед запуском протоколов приложений.

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

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

Определение происхождения

Два URL-адреса имеют одинаковое происхождение, если протокол, порт (если указан) и хост одинаковы для обоих. Вы можете увидеть это как «кортеж схемы/хоста/порта» или просто «кортеж». («Кортеж» — это набор элементов, которые вместе составляют единое целое — общая форма для двойного/тройного/четверного/пятерного/и т. д.)

Унаследованное происхождение

Сценарии, выполняемые со страниц с URL-адресом about:blank или javascript:, наследуют источник документа, содержащего этот URL-адрес, поскольку эти типы URL-адресов не содержат информации об исходном сервере.

Например, about:blank часто используется в качестве URL-адреса новых пустых всплывающих окон, в которые родительский скрипт записывает содержимое (например, с помощью механизма Window.open()). Если это всплывающее окно также содержит JavaScript, этот скрипт унаследует то же происхождение, что и скрипт, который его создал.

данные: URL-адреса получают новый, пустой контекст безопасности.

Исключения в Internet Explorer

У Internet Explorer есть два основных исключения из политики одного и того же источника:

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

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

Происхождение файла

Современные браузеры обычно рассматривают источник файлов, загруженных с использованием схемы file:///, как непрозрачный источник. Это означает, что если файл включает в себя другие файлы из той же папки (скажем), считается, что они не происходят из одного и того же источника и могут вызывать ошибки CORS.

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

Изменение источника

Предупреждение. Описанный здесь подход (с использованием установщика document.domain) устарел, поскольку он подрывает защиту безопасности, обеспечиваемую той же политикой источника, и усложняет модель источника в браузерах, что приводит к проблемам совместимости и ошибкам безопасности.

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

Номер порта проверяется браузером отдельно. Любой вызов document.domain , включая document.domain = document.domain , приводит к тому, что номер порта заменяется значением null . Следовательно, нельзя заставить company.com:8080 общаться с company.com, установив только document.domain = "company.com" в первом. Он должен быть установлен в обоих, чтобы их номера портов были нулевыми.

У этого механизма есть некоторые ограничения. Например, будет сгенерировано исключение DOMException " SecurityError ", если включена политика Feature-Policy домена документа или документ находится в изолированной программной среде, и изменение источника таким образом не влияет на проверки источника, используемые многими веб-API (например, localStorage). , indexedDB , BroadcastChannel , SharedWorker ). Более полный список случаев сбоев можно найти в Document.domain > Сбои.

Примечание. При использовании document.domain, чтобы разрешить поддомену доступ к своему родительскому домену, вам необходимо установить для document.domain одно и то же значение как в родительском домене, так и в поддомене. Это необходимо, даже если это возвращает исходное значение родительского домена. Если этого не сделать, могут возникнуть ошибки разрешения.

Доступ к сети из разных источников

Вот несколько примеров ресурсов, которые могут быть встроены из разных источников:

JavaScript с расширением . Сведения об ошибках синтаксиса доступны только для скриптов того же происхождения.
Применен CSS
Изображения, отображаемые с помощью .
Медиафайлы, воспроизводимые и .
Внешние ресурсы, встроенные в и .
Шрифты, примененные с помощью @font-face . В одних браузерах разрешены шрифты разных источников, в других требуется шрифты одного происхождения.
Все, что встроено в . Сайты могут использовать заголовок X-Frame-Options для предотвращения фрейминга из разных источников.

Как разрешить доступ из разных источников

Как заблокировать доступ из разных источников

Чтобы предотвратить запись из разных источников, проверьте токен, который невозможно угадать, в запросе, известный как токен межсайтовой подделки запроса (CSRF). Вы должны предотвратить перекрестное чтение страниц, для которых требуется этот токен.
Чтобы предотвратить чтение ресурса из другого источника, убедитесь, что он не является встраиваемым. Часто необходимо предотвратить встраивание, потому что встраивание ресурса всегда приводит к утечке некоторой информации о нем.
Чтобы предотвратить встраивание из разных источников, убедитесь, что ваш ресурс не может быть интерпретирован как один из форматов для встраивания, перечисленных выше. Браузеры могут не учитывать заголовок Content-Type. Например, если вы указываете . Сведения об ошибках синтаксиса доступны только для сценариев того же происхождения. \n
Применен CSS
Изображения, отображаемые с помощью . \n
Медиафайлы, воспроизводимые и . \n
Внешние ресурсы, встроенные в и . \n
Шрифты, примененные с помощью @font-face . Некоторые браузеры разрешают шрифты из разных источников, другие требуют того же происхождения. \n
Все, что встроено в . Сайты могут использовать заголовок X-Frame-Options для предотвращения кадрирования из разных источников. \n

Чтобы предотвратить запись из разных источников, проверьте токен, который невозможно угадать, в запросе, известный как токен межсайтовой подделки запроса (CSRF). Вы должны предотвратить перекрестное чтение страниц, для которых требуется этот токен. \n
Чтобы предотвратить чтение ресурса из другого источника, убедитесь, что он не является встраиваемым. Часто необходимо предотвратить встраивание, потому что встраивание ресурса всегда приводит к утечке некоторой информации о нем. \n
Чтобы предотвратить встраивание из разных источников, убедитесь, что ваш ресурс не может быть интерпретирован как один из форматов для встраивания, перечисленных выше. Браузеры могут не учитывать заголовок Content-Type. Например, если указать

Межсайтовый скриптинг (XSS) — это атака путем внедрения кода на стороне клиента. Злоумышленник стремится выполнить вредоносные сценарии в веб-браузере жертвы, включив вредоносный код в законную веб-страницу или веб-приложение. Фактическая атака происходит, когда жертва посещает веб-страницу или веб-приложение, выполняющее вредоносный код. Веб-страница или веб-приложение становятся средством доставки вредоносного сценария в браузер пользователя. Уязвимыми средствами, которые обычно используются для атак с использованием межсайтовых сценариев, являются форумы, доски объявлений и веб-страницы, на которых разрешены комментарии.

Веб-страница или веб-приложение уязвимы для XSS, если они используют несанитизированный пользовательский ввод в создаваемых выходных данных. Затем этот пользовательский ввод должен быть проанализирован браузером жертвы. Атаки XSS возможны в VBScript, ActiveX, Flash и даже CSS. Тем не менее, они наиболее распространены в JavaScript, в первую очередь потому, что JavaScript является основой для большинства операций просмотра.

«Разве межсайтовый скриптинг — не проблема пользователя?»

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

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

Что злоумышленник может сделать с помощью JavaScript?

Уязвимости XSS воспринимаются как менее опасные, чем, например, уязвимости SQL Injection. Последствия возможности запускать JavaScript на веб-странице поначалу могут не показаться ужасными. Большинство веб-браузеров запускают JavaScript в очень строго контролируемой среде. JavaScript имеет ограниченный доступ к операционной системе пользователя и его файлам. Однако JavaScript по-прежнему может быть опасен, если его неправильно использовать как часть вредоносного контента:

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

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

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

Типичная XSS-атака состоит из двух этапов:

Чтобы запустить вредоносный код JavaScript в браузере жертвы, злоумышленник должен сначала найти способ внедрить вредоносный код (полезную нагрузку) на веб-страницу, которую посещает жертва.
После этого жертва должна посетить веб-страницу с вредоносным кодом. Если атака направлена на конкретных жертв, злоумышленник может использовать социальную инженерию и/или фишинг, чтобы отправить жертве вредоносный URL.

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

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

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

Веб-сервер предоставляет следующий HTML-код пользователям, посещающим эту веб-страницу:

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

Кража файлов cookie с помощью XSS

События JavaScript

Атрибуты событий JavaScript, такие как onload и onerror, можно использовать во многих различных тегах. Это очень популярный вектор атаки XSS.

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

Некоторые браузеры выполняют JavaScript, указанный в атрибутах.

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

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

Тег можно использовать для включения сценария с внешнего сайта.

Уязвим ли ваш веб-сайт или веб-приложение для межсайтового скриптинга

Уязвимости межсайтового скриптинга — одна из наиболее распространенных уязвимостей веб-приложений. Организация OWASP (Открытый проект безопасности веб-приложений) перечисляет уязвимости XSS в своем документе OWASP Top 10 2017 как вторую наиболее распространенную проблему.

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

Как предотвратить XSS

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

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

Как предотвратить межсайтовый скриптинг (XSS) — общие советы

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

Предупреждение о межсайтовых сценариях в Internet Explorer 8 и Fabasoft eGov-Suite 8.0 SP1

Обзор

С обновлением Internet Explorer, развернутым Центром обновления Windows, был обновлен фильтр межсайтовых сценариев (XSS-фильтр) Internet Explorer. Если это обновление установлено на клиенте, Fabasoft eGov-Suite не работает должным образом.

Информация

Когда вы работаете в Fabasoft eGov-Suite / Fabasoft Folio с помощью Microsoft Internet Explorer и открывается новое окно (например, при редактировании объекта), вы получаете предупреждение на информационной панели браузера, Internet Explorer изменил эту страницу на предотвратить потенциальную атаку с использованием межсайтовых сценариев. Для получения дополнительной информации нажмите здесь. . Окно, которое вы открыли, остается пустым.

Затронутые системы

Наши текущие тесты и отзывы наших клиентов подтверждают это поведение по крайней мере для следующей конфигурации:

Fabasoft eGov-Suite 8.0 SP1 или Fabasoft Folio 2009 с
Microsoft Internet Explorer 8 и Microsoft Internet Explorer 9 и
Установлено обновление Microsoft MS11-099 (выпущено 13 ноября 2011 г.)

ОБНОВЛЕНИЕ: Fabasoft может проверить, что такое поведение также может возникать с текущими установками Fabasoft Folio 2011 и Fabasoft Folio 2012, если VAPP открываются в новом окне (вместо технологии наложения). Эта проблема исправлена в летнем выпуске Fabasoft Folio 2012.

Решение

Решение 1

В зоне Internet Explorer "Локальная интрасеть" XSS-фильтр отключен по умолчанию. Если вы запускаете Fabasoft eGov-Suite в зоне «Надежные сайты», переместите URL-адрес в зону «Локальная интрасеть». Это позволит избежать такого поведения.

Этот параметр может быть развернут политикой домена.

Примечание. Убедитесь, что XSS-фильтр отключен в зоне "Локальная интрасеть". Если это не так, используйте решение 2.

Решение 2

Используйте этот обходной путь, чтобы отключить фильтр XSS для используемой зоны безопасности в Internet Explorer и повторно включить функциональные возможности Fabasoft eGov-Suite:

Откройте Microsoft Internet Explorer
Откройте "Свойства обозревателя"
Перейдите на вкладку "Безопасность".
Выберите зону, в которой находится ваша установка Fabasoft eGov-Suite (обычно это «Местная интрасеть» или «Надежные сайты»), и нажмите «Пользовательский уровень».
Установите для параметра "Включить фильтр XSS" в области "Сценарии" значение "Отключить".