Jump to content

Межсайтовые утечки

Это хорошая статья. Нажмите здесь для получения дополнительной информации.

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

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

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

До 2017 года защита от межсайтовых утечек считалась сложной задачей. Это произошло потому, что многие проблемы утечки информации, используемые в ходе атак с межсайтовой утечкой, были присущи способу работы веб-сайтов. Большинство средств защиты от атак этого класса были введены после 2017 года в виде расширений протокола передачи гипертекста (HTTP). Эти расширения позволяют веб-сайтам давать браузеру указание запрещать или комментировать определенные виды запросов с отслеживанием состояния, поступающих с других веб-сайтов. Один из наиболее успешных подходов, реализованных браузерами, — это файлы cookie SameSite . Файлы cookie SameSite позволяют веб-сайтам устанавливать директиву, которая запрещает другим веб-сайтам доступ и отправку конфиденциальных файлов cookie. Другая защита включает использование заголовков HTTP для ограничения того, какие веб-сайты могут встраивать определенный сайт. Разделение кэша также служит защитой от межсайтовых утечек, не позволяя другим веб-сайтам использовать веб-кеш для кражи данных.

Предыстория [ править ]

Веб-приложения (веб-приложения) состоят из двух основных компонентов: веб-браузера и одного или нескольких веб-серверов . Браузер обычно взаимодействует с серверами через протокол передачи гипертекста (HTTP) и соединения WebSocket для доставки веб-приложения. [примечание 1] Определенные части веб-приложения должны реагировать на ввод пользователя или другую логику на стороне клиента; это делается путем рендеринга HTML или CSS или выполнения JavaScript в процессе создания веб-сайта. [2] Часто эти взаимодействия с пользователем требуют, чтобы веб-приложение выполняло несколько запросов к серверу в течение длительных периодов времени. Чтобы отслеживать такие запросы, веб-приложения часто используют постоянный идентификатор, привязанный к конкретному пользователю через его текущий сеанс или учетную запись пользователя. [3] Эта учетная запись или сеанс будет иметь определенные идентифицируемые атрибуты, такие как возраст или уровень доступа, отражающие предыдущие взаимодействия пользователя с веб-приложением. Если эти идентифицируемые атрибуты будут раскрыты другим веб-сайтам, они могут деанонимизировать пользователя. [4]

В идеальном сценарии взаимодействие с пользователем и связь с веб-сервером должны осуществляться таким образом, чтобы никакие два веб-приложения не могли мешать друг другу. Однако из-за различных вариантов дизайна, принятых в первые годы существования Интернета, веб-приложения могут регулярно взаимодействовать друг с другом. [5] Чтобы предотвратить злоупотребление таким поведением, веб-браузеры создали набор правил, называемых политикой одного и того же происхождения . Политика одного и того же происхождения предусматривает, что разрешены только определенные взаимодействия между двумя веб-приложениями. [6] [7] Например, политика одного и того же происхождения не позволяет веб-приложению произвольно входить в контекст выполнения другого веб-приложения и взаимодействовать с ним. [8] Однако веб-приложение может встраивать контент из других веб-приложений с помощью фреймов или отправлять запросы к сторонним сайтам через запросы между источниками. [9] Примечательно, однако, что политика одного и того же источника не позволяет другим веб-приложениям напрямую читать содержимое этих запросов из разных источников, если это явно не разрешено через структуру совместного использования ресурсов между источниками (CORS). [10]

Межсайтовые утечки позволяют злоумышленникам получить информацию, несмотря на ограничения, налагаемые политикой одного и того же источника. Межсайтовые утечки используют проблемы утечки информации ( побочные каналы ), которые исторически присутствовали в браузерах. Используя утечки, злоумышленник может выполнить код, чтобы получить информацию о текущем состоянии другого контекста выполнения с помощью запросов между источниками или путем внедрения веб-приложения жертвы в атакующее веб-приложение. [11] Затем злоумышленник может получить доступ к информации о предыдущих взаимодействиях пользователя с веб-приложением. [12]

Механизм [ править ]

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

Чтобы осуществить атаку с межсайтовой утечкой, злоумышленник должен сначала изучить, как веб-сайт взаимодействует с пользователями. Им необходимо определить конкретный URL-адрес , который генерирует различные ответы протокола передачи гипертекста (HTTP) на основе прошлых действий пользователя на сайте. [15] [16] Например, если злоумышленник пытается атаковать Gmail , он может попытаться найти URL-адрес поиска, который возвращает другой ответ HTTP в зависимости от того, сколько результатов поиска найдено по определенному поисковому запросу в электронных письмах пользователя. [17] Как только злоумышленник найдет определенный URL-адрес, он может разместить веб-сайт и провести фишинг или иным образом заманить ничего не подозревающих пользователей на веб-сайт. Как только жертва оказывается на веб-сайте злоумышленника, злоумышленник может использовать различные методы внедрения, чтобы инициировать HTTP-запросы между источниками к URL-адресу, указанному злоумышленником. [18] Однако, поскольку злоумышленник находится на другом веб-сайте, политика того же источника, установленная веб-браузером, не позволит злоумышленнику напрямую прочитать любую часть ответа, отправленного уязвимым веб-сайтом. [примечание 2] [19]

Чтобы обойти этот барьер безопасности, злоумышленник может использовать методы утечки информации из браузера, чтобы различать тонкие различия между различными ответами. Методы утечки информации в браузере — это фрагменты JavaScript , CSS или HTML , которые используют давние проблемы утечки информации ( побочные каналы ) в веб-браузере для выявления конкретных характеристик HTTP-ответа. [15] [16] В случае с Gmail злоумышленник может использовать JavaScript, чтобы определить, сколько времени потребуется браузеру для анализа HTTP-ответа, возвращаемого результатом поиска. Если время, затраченное на анализ ответа, возвращаемого конечной точкой, было небольшим, злоумышленник мог сделать вывод, что по его запросу нет результатов поиска. Альтернативно, если сайт занимал больше времени, злоумышленник мог сделать вывод, что было возвращено несколько результатов поиска. [17] Злоумышленник может впоследствии использовать информацию, полученную в результате этих утечек информации, для кражи конфиденциальной информации, которую можно использовать для отслеживания и деанонимизации жертвы. [18] В случае с Gmail злоумышленник может отправить запрос к конечной точке поиска с помощью запроса и впоследствии измерить время, которое потребовалось запросу, чтобы выяснить, есть ли у пользователя какие-либо электронные письма, содержащие определенную строку запроса. [примечание 3] Если обработка ответа занимает очень мало времени, злоумышленник может предположить, что результаты поиска не были возвращены. И наоборот, если обработка ответа занимает много времени, злоумышленник делает вывод, что было возвращено много результатов поиска. Сделав несколько запросов, злоумышленник может получить значительную информацию о текущем состоянии приложения-жертвы, потенциально раскрывая личную информацию пользователя, помогая запускать изощренные спам-атаки и фишинговые атаки. [20]

Хотя каждый метод инициирования запроса между источниками к URL-адресу на веб-странице можно комбинировать с любым методом утечки данных из браузера, на практике это не работает, поскольку существуют зависимости между различными методами включения и утечками браузера. Некоторые методы утечки информации в браузере для достижения успеха требуют специальных методов включения. [21] Например, если метод утечки браузера основан на проверке атрибутов CSS, таких как ширина и высота элемента, метод включения должен использовать элемент HTML со свойством ширины и высоты, например элемент изображения, который изменяется при Запрос -origin возвращает недопустимое изображение или изображение другого размера. [22] [23]

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

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

<  html   lang  =  "en"  >  <  body  >  <  h2  >  Результаты поиска  </  h2  >  {% для результата в результатах %}    <  div   class  =  "result"  >        <  img   src  =  "//cdn.com/result-icon.png"   />  {% result.description %}    </div>  { %  }  endfor %  </  тело  >  </  html  > 

Этот код представляет собой шаблон для отображения результатов поиска на веб-странице. Он просматривает коллекцию результатов, предоставленных серверной частью HTTP-сервера , и отображает каждый результат вместе с его описанием внутри структурированного элемента div рядом со значком, загруженным с другого веб-сайта. Базовое приложение аутентифицирует пользователя на основе файлов cookie , прикрепленных к запросу, и выполняет текстовый поиск личной информации пользователя, используя строку, указанную в параметре GET. значок, загруженный из сети доставки контента (CDN). Для каждого возвращаемого результата рядом с результатом отображается [13] [24]

Эта простая функция уязвима для атаки перекрестной утечки, как показано в следующем фрагменте JavaScript . [13]

let   icon_url   =   'https://cdn.com/result-icon.png'  ;  iframe  .  src   =   'https://service.com/?q=пароль'  ;  iframe  .  onload   =   async   ()   =>   {       const   start   =   Performance  .  сейчас  ();       дождаться   получения  (  icon_url  );       константная   продолжительность   =   производительность  .  сейчас  ()    начать  ;       if   (  длительность   <   5  )   // загружаем ресурс из           консоли  кэша .  log  (  'Запрос дал результаты'  );       еще           консоль  .  log  (  'Нет результатов по параметру запроса'  );  }; 

Этот фрагмент JavaScript, который можно внедрить в веб-приложение, контролируемое злоумышленником, загружает веб-приложение жертвы внутри iframe, ожидает загрузки документа и впоследствии запрашивает значок из CDN. Злоумышленник может определить, был ли значок кэширован, определив время его возврата. Поскольку значок будет кэшироваться только тогда и только тогда, когда приложение-жертва вернет хотя бы один результат, злоумышленник может определить, вернуло ли приложение-жертва какие-либо результаты для данного запроса. [23] [24] [25]

История [ править ]

О межсайтовых утечках известно с 2000 года; [26] В исследовательских работах того же года, опубликованных в Университете Пердью, описывается теоретическая атака, в которой используется HTTP-кеш для компрометации конфиденциальности привычек пользователя в Интернете. [27] В 2007 году Эндрю Бортц и Дэн Боне из Стэнфордского университета опубликовали официальный документ с подробным описанием атаки, в которой использовалась информация о времени для определения размера межсайтовых ответов. [28] В 2015 году исследователи из Университета Бар-Илан описали атаку с межсайтовым поиском, в которой использовались аналогичные методы утечки информации, но использовалась техника, в которой входные данные обрабатывались для увеличения размера ответов, что приводило к пропорциональному увеличению времени, затрачиваемого на генерацию. ответы, тем самым увеличивая точность атаки. [29]

Независимые исследователи безопасности опубликовали сообщения в блогах, описывающие атаки с межсайтовой утечкой информации против реальных приложений. В 2009 году Крис Эванс описал атаку на Yahoo! Почта , с помощью которой вредоносный сайт может искать в почтовом ящике пользователя конфиденциальную информацию. [30] В 2018 году Луан Эррара описал эксплойт безопасности, который позволил им получить данные о деликатных проблемах безопасности с помощью функции поиска системы отслеживания ошибок Google Monorail, которая активно используется такими проектами с открытым исходным кодом , как Chromium , Angle и Skia Graphics Engine . [31] [32] В 2019 году Терьянк, польский исследователь безопасности, опубликовал сообщение в блоге, описывающее атаку с межсайтовым поиском, которая позволила им украсть конфиденциальную информацию пользователей из громких продуктов Google. [11] [25]

В рамках повышенного внимания к решению проблем безопасности, которые зависят от неправильного использования давних функций веб-платформы, Google запустил XSLeaks Wiki в 2020 году, пытаясь создать базу данных открытых знаний, а также анализировать и собирать информацию о межсайтовых утечках. атаки. [30] [33] [34]

С 2020 года академическое сообщество по безопасности проявляет некоторый интерес к стандартизации классификации этих атак. В 2020 году Судходанан и др. были одними из первых, кто систематически обобщил предыдущую работу по устранению межсайтовых утечек и разработал инструмент под названием BASTA-COSI, который можно использовать для обнаружения утечек URL-адресов. [34] [35] В 2021 году Книттель и др. предложил новую формальную модель для оценки и характеристики межсайтовых утечек, позволяющую исследователям находить новые утечки, затрагивающие несколько браузеров. [34] [36] В 2022 году Ван Гётем и др. оценил доступные на данный момент средства защиты от этих атак и расширил существующую модель, включив в нее состояние компонентов браузера. [34] [16] В 2023 году статья, опубликованная Rautenstrauch et al. систематизация предыдущих исследований межсайтовых утечек была удостоена награды «Выдающаяся статья» на симпозиуме IEEE по безопасности и конфиденциальности . [37]

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

Межсайтовые утечки включают в себя весьма разнообразный спектр атак. [38] для которых не существует установленной единой классификации. [39] Однако несколько источников обычно классифицировали эти атаки по методам утечки информации, использованным во время атаки. [21] По состоянию на 2021 год Исследователи выявили более 38 методов утечки данных, нацеленных на компоненты браузера. [13] Новые методы обычно обнаруживаются из-за изменений в API-интерфейсах веб-платформы , которые представляют собой интерфейсы JavaScript, которые позволяют веб-сайтам запрашивать у браузера конкретную информацию. [40] Хотя большинство этих методов подразумевают непосредственное обнаружение изменений состояния веб-приложения-жертвы, некоторые атаки также используют изменения в общих компонентах браузера для косвенного сбора информации о веб-приложении-жертве. [21]

Временные атаки [ править ]

Атаки по времени основаны на способности определять время конкретных событий по нескольким ответам. [41] Они были обнаружены исследователями из Стэнфордского университета в 2007 году, что сделало их одним из старейших известных типов атак с межсайтовой утечкой. [28]

Первоначально использовался только для различения времени, необходимого HTTP-запросу для разрешения ответа. [28] исследования, проведенные после 2007 года, продемонстрировали использование этого метода утечки для обнаружения других различий между состояниями веб-приложений. В 2017 году Вила и др. показали, что атаки по времени могут определить время выполнения между источниками во встроенных контекстах. Это стало возможным благодаря отсутствию функций изоляции сайта в современных браузерах, что позволяло атакующему веб-сайту замедляться и усиливать разницу во времени, вызванную различиями в объеме выполняемого JavaScript при отправке событий в веб-приложение-жертву. [42] [43]

В 2021 году Книттель и др. показал API производительности [примечание 4] может привести к утечке информации о наличии или отсутствии перенаправлений в ответах. Это стало возможным из-за ошибки в Performance API, из-за которой количество времени, отображаемое пользователю, было отрицательным при возникновении перенаправления. Google Chrome впоследствии исправил эту ошибку. [45] В 2023 году Снайдер и др. показали, что временные атаки могут использоваться для проведения групповых атак, в ходе которых веб-сайты могут блокировать общие ресурсы, исчерпав свою глобальную квоту. Заставив веб-приложение-жертву выполнять JavaScript, который использовал эти общие ресурсы, а затем замерив время, которое заняло это выполнение, исследователи смогли раскрыть информацию о состоянии веб-приложения. [46]

События ошибок [ править ]

События ошибок — это метод утечки, который позволяет злоумышленнику различать множественные ответы путем регистрации обработчиков событий ошибок и прослушивания событий через них. Благодаря своей универсальности и способности к утечке широкого спектра информации, события ошибок считаются классическим вектором межсайтовой утечки. [47]

Одним из наиболее распространенных случаев использования событий ошибок при атаках с межсайтовой утечкой является определение ответов HTTP путем подключения обработчиков событий. onload и onerror обработчики событий в элемент HTML и ожидание возникновения определенных событий ошибок. Отсутствие событий ошибок указывает на отсутствие ошибок HTTP. Напротив, если обработчик onerror запускается с определенным событием ошибки, злоумышленник может использовать эту информацию, чтобы различать типы HTTP-контента, коды состояния и ошибки типов мультимедиа. [48] В 2019 году исследователи из Технического университета Дармштадта показали, что эту технику можно использовать для проведения целевой деанонимизационной атаки на пользователей популярных веб-сервисов, таких как Dropbox , Google Docs и GitHub , которые позволяют пользователям обмениваться произвольным контентом друг с другом. [49] [50]

С 2019 года расширены возможности событий ошибок. В 2020 году Янк и др. показано, установив режим перенаправления для запроса на выборку manual, веб-сайт может привести к утечке информации о том, является ли конкретный URL-адрес перенаправлением. [51] [43] Примерно в то же время Джон Масас и Луан Эррара показали, что, злоупотребляя ограничениями, связанными с URL-адресами, злоумышленник может вызвать события ошибки, которые могут быть использованы для утечки информации о перенаправлении URL-адресов. [52] В 2021 году Книттель и др. отображал события ошибок, генерируемые проверкой целостности подресурса, механизм, который используется для подтверждения того, что подресурс, загружаемый веб-сайтом, не был изменен или скомпрометирован, также может использоваться для угадывания необработанного содержимого HTTP-ответа и для утечка длины содержимого ответа. [53] [54]

Атаки по таймингу кэша [ править ]

Атаки с использованием тайминга кэша основаны на возможности определить попадания и промахи в общих кэшах на веб-платформе. [55] Один из первых случаев атаки с использованием тайминга кэша включал в себя выполнение запроса к странице между источниками и последующее исследование существования ресурсов, загруженных запросом, в общем HTTP- и DNS- кэше. Документ, описывающий атаку, был написан исследователями из Университета Пердью в 2000 году и описывает способность атаки раскрыть большую часть истории просмотров пользователя путем выборочной проверки, были ли загружены уникальные для веб-страницы ресурсы. [56] [55] [57]

Эта атака становится все более изощренной, позволяя утечку других типов информации. В 2014 году Цзя и др. показал, что эта атака может определить географическое местоположение человека, измеряя время, необходимое для загрузки локализованного домена группы международных веб-сайтов. [55] [58] [59] В 2015 году Ван Гётем и др. Как показано, используя недавно представленный кеш приложения , веб-сайт может дать указание браузеру игнорировать и переопределить любую директиву кеширования, отправленную веб-сайтом-жертвой. В документе также показано, что веб-сайт может получить информацию о размере кэшированного ответа, определив время доступа к кэшу. [60] [61]

Глобальные ограничения [ править ]

Глобальные ограничения, также известные как атаки группы пула, не зависят напрямую от состояния веб-приложения-жертвы. Эта межсайтовая утечка была впервые обнаружена Knittel et al. в 2020 году, а затем расширен Snyder et al. в 2023 году. [46] Атака с целью злоупотребления глобальными операционными системами или аппаратными ограничениями, приводящая к истощению общих ресурсов. [62] Глобальные ограничения, которыми можно злоупотреблять, включают количество необработанных сокет- соединений, которые можно зарегистрировать, и количество сервис-воркеров , которые можно зарегистрировать. Злоумышленник может сделать вывод о состоянии веб-сайта-жертвы, выполнив действие, которое запускает эти глобальные ограничения, и сравнив любые различия в поведении браузера, когда то же действие выполняется без загрузки веб-сайта-жертвы. [63] Поскольку для этих типов атак обычно также требуются временные побочные каналы , они также считаются временными атаками. [46]

Другие методы [ править ]

В 2019 году Гарет Хейес обнаружил, что, установив для хеша URL-адреса веб-сайта определенное значение и впоследствии определив, произошла ли потеря фокуса на текущей веб-странице, злоумышленник может определить наличие и положение элементов на веб-сайте-жертве. [64] В 2020 году Книттель и др. показало, что злоумышленник может получить утечку независимо от того, Cross-Origin-Opener-Policy заголовок был установлен путем получения ссылки на window объект веб-сайта-жертвы путем создания фрейма веб-сайта или создания всплывающего окна веб-сайта-жертвы. Используя тот же метод получения ссылок на окна, злоумышленник также может подсчитать количество кадров, которые веб-сайт жертвы прошел через window.length свойство. [45] [65]

Несмотря на то, что продолжают появляться новые методы, старые методы выполнения межсайтовых утечек устарели из-за изменений в спецификациях Консорциума Всемирной паутины (W3C) и обновлений браузеров. В декабре 2020 года Apple обновила механизм интеллектуального предотвращения отслеживания (ITP) в своем браузере сделав Safari , различные методы межсайтовой утечки, которые исследователи из Google обнаружили неэффективными. [66] [67] [68] Аналогичным образом, широкое внедрение разделения кэша во всех основных браузерах в 2020 году снизило эффективность атак с использованием тайминга кэша. [69]

Защита [ править ]

Несмотря на то, что о них известно с 2000 года, большинство средств защиты от межсайтовых утечек были введены после 2017 года. [70] До внедрения этих средств защиты веб-сайты могли защититься от межсайтовых утечек, гарантируя, что один и тот же ответ будет возвращен для всех состояний приложения, лишая злоумышленника возможности дифференцировать запросы. Этот подход был неосуществим для любого нетривиального веб-сайта. Второй подход заключался в создании URL-адресов, специфичных для сеанса, которые не работали бы вне сеанса пользователя. Этот подход ограничивает совместное использование ссылок и поэтому невозможен и непрактичен. [26] [71]

Большинство современных средств защиты от межсайтовых утечек — это расширения протокола HTTP, которые либо предотвращают изменение состояния, либо делают запросы между источниками без сохранения состояния , либо полностью изолируют общие ресурсы из нескольких источников. [69]

Изоляция общих ресурсов [ править ]

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

Одним из самых ранних и самых известных методов межсайтовых утечек было использование HTTP-кеша — подхода, основанного на запросе к кешу браузера уникальных ресурсов, которые мог загрузить веб-сайт жертвы. Измерив время, необходимое запросу из разных источников для обнаружения атакующего веб-сайта, можно определить, кэширован ли ресурс, и, если да, то состояние приложения-жертвы. [24] [72] По состоянию на октябрь 2020 г. , большинство браузеров реализовали разделение кэша HTTP, что резко снижает эффективность этого подхода. [73] Разделение кэша HTTP работает путем многократного ввода каждого кэшированного запроса в зависимости от того, какой веб-сайт запросил ресурс. Это означает, что если веб-сайт загружает и кэширует ресурс, кэшированный запрос связан с уникальным ключом, сгенерированным в результате объединения URL-адреса ресурса и URL-адреса запрашивающего веб-сайта. Если другой веб-сайт попытается получить доступ к тому же ресурсу, запрос будет рассматриваться как промах в кэше, если только этот веб-сайт ранее не кэшировал идентичный запрос. Это не позволяет атакующему веб-сайту определить, кэширован ли ресурс веб-сайтом-жертвой. [74] [75] [76]

Другая, более ориентированная на разработчиков функция, которая позволяет изолировать контексты выполнения, включает в себя Cross-Origin-Opener-Policy (COOP), который изначально был добавлен для решения проблем Spectre в браузере. [77] [78] Это оказалось полезным для предотвращения утечек между сайтами, поскольку, если заголовок установлен с same-origin директивы как часть ответа, браузер запретит веб-сайтам с перекрестным происхождением сохранять ссылку на защищаемый веб-сайт, когда он открывается со сторонней страницы. [79] [80] [81]

В рамках усилий по уменьшению межсайтовых утечек разработчики браузеров Chrome , Brave , Microsoft Edge , Firefox и Safari реализовали разделение хранилища, [82] позволяя всем общим ресурсам, используемым каждым веб-сайтом, быть многоключевыми, что значительно сокращает количество методов включения, которые могут определить состояние веб-приложения. [83]

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

Атаки с межсайтовой утечкой зависят от способности вредоносной веб-страницы получать ответы из разных источников от приложения-жертвы. Предотвращая получение вредоносным приложением ответов из разных источников, пользователь больше не подвергается опасности утечки изменений состояния. [84] Этот подход можно увидеть в таких средствах защиты, как устаревший X-Frame-Options заголовок и новее frame-ancestors Директива в заголовках Content-Security Policy , которая позволяет приложению-жертве указать, какие веб-сайты могут включать ее в качестве встроенного фрейма. [85] Если приложение-жертва запрещает встраивание веб-сайта в ненадежные контексты, вредоносное приложение больше не может отслеживать ответ на запросы из разных источников, отправленные приложению-жертве с использованием метода встроенного фрейма. [86] [87]

Аналогичный подход используется в механизме блокировки ресурсов Cross-Origin (CORB) и Cross-Origin-Resource-Policy (CORP) заголовок , который позволяет успешно выполнить запрос между источниками, но блокирует загрузку контента на сторонних веб-сайтах, если существует несоответствие между ожидаемым типом контента и тем, который был получен. [88] Эта функция изначально была представлена ​​как часть серии мер по устранению уязвимости Spectre. [89] но он оказался полезным для предотвращения утечек из разных источников, поскольку блокирует получение ответа вредоносной веб-страницей и, таким образом, определение изменений состояния. [86] [90] [91]

Создание запросов между источниками без сохранения состояния [ править ]

Одним из наиболее эффективных подходов к уменьшению межсайтовых утечек является использование SameSite параметр в файлах cookie . После установки на Lax или Strict, этот параметр запрещает браузеру отправлять файлы cookie в большинстве сторонних запросов, что фактически делает запрос без сохранения состояния. [примечание 5] [91] Принятие Same-Site однако файлы cookie работают медленно, поскольку требуют изменений в работе многих специализированных веб-серверов, таких как поставщики аутентификации. [93] В 2020 году создатели браузера Chrome объявили, что включат SameSite=Lax как состояние по умолчанию для файлов cookie на всех платформах. [94] [95] Несмотря на это, все еще встречаются случаи, когда SameSite=Lax файлы cookie не соблюдаются, например файлы Chrome LAX+POST смягчение последствий, которое позволяет сайту с перекрестным происхождением использовать SameSite=Lax cookie в запросе тогда и только тогда, когда запрос отправляется во время навигации по странице и происходит в течение двух минут после установки cookie. [92] Это привело к обходным путям и обходным путям против SameSite=Lax ограничение, которое все еще допускает возникновение межсайтовых утечек. [96] [97]

Получить заголовки метаданных, которые включают в себя Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-User и Sec-Fetch-Dest Заголовок, который предоставляет информацию о домене, инициировавшем запрос, сведения об инициировании запроса и пункте назначения запроса соответственно защищающемуся веб-серверу, также использовался для смягчения атак с утечкой данных между сайтами. [98] Эти заголовки позволяют веб-серверу различать законные сторонние запросы с одного и того же сайта и вредоносные запросы из разных источников. Различая эти запросы, сервер может отправлять ответ без сохранения состояния на вредоносные сторонние запросы и ответ с сохранением состояния на обычные запросы того же сайта. [99] Чтобы предотвратить неправомерное использование этих заголовков, веб-приложению не разрешается устанавливать эти заголовки, которые должны устанавливаться только браузером. [100] [75]

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

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

Примечания [ править ]

  1. ^ Хотя существуют и другие возможные способы взаимодействия между веб-браузерами и веб-серверами (например, протокол WebRTC ), в контексте межсайтовых утечек важными считаются только взаимодействия HTTP и соединения WebSocket. [1] В оставшейся части статьи предполагается, что взаимодействие HTTP и соединение WebSocket — это единственные два способа взаимодействия веб-браузеров с веб-серверами.
  2. ^ Сюда входят метаданные, связанные с ответом, такие как коды состояния и заголовки HTTP. [19]
  3. ^ Примером такого запроса может быть название известного банка или контактная информация человека или организации, с которыми, как ожидается, пользователь взаимодействовал. [20]
  4. ^ Performance API — это набор функций Javascript, которые позволяют веб-сайтам получать различные показатели, связанные с веб-производительностью. [44]
  5. ^ Установка Strict Директива гарантирует, что все межсайтовые запросы не сохраняют состояние, тогда как Lax позволяет браузеру отправлять файлы cookie для изменения состояния (т. е. GET или HEAD) запросы, которые отправляются при переходе на другую страницу с перекрестной страницы. [92]

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

  1. ^ Книттель и др. 2021 , стр. 1773, 1776.
  2. ^ «Как работает Интернет – Изучите веб-разработку | MDN» . Веб-документы MDN . 24 июля 2023 г. Архивировано из оригинала 24 сентября 2023 г. Проверено 1 октября 2023 г.
  3. ^ Вагнер, Дэвид; Уивер, Николас; Као, Пейрин; Шакир, Фузайл; Закон, Эндрю; Нгай, Николас. «Файлы cookie и управление сеансами» . Калифорнийского университета в Беркли Учебник по компьютерной безопасности CS-161 . Проверено 24 марта 2024 г.
  4. ^ Судходанан, Ходаяри и Кабальеро 2020 , стр. 2–3.
  5. ^ Залевский 2011 , стр. 15.
  6. ^ Швенк, Нимитц и Майнка 2017 , с. 713.
  7. ^ Залевский 2011 , стр. 16.
  8. ^ Швенк, Нимитц и Майнка 2017 , с. 716.
  9. ^ Некоторые 2018 , стр. 13–14.
  10. ^ «Политика одного и того же происхождения — Безопасность в Интернете | MDN» . Веб-документы MDN . 20 декабря 2023 г. Проверено 24 марта 2024 г.
  11. Перейти обратно: Перейти обратно: а б Книттель и др. 2021 , с. 1772.
  12. ^ Ван Гётем и др. 2021 , с. 1.
  13. Перейти обратно: Перейти обратно: а б с д Ван Гетем и др. 2022 , с. 786.
  14. ^ Судходанан, Ходаяри и Кабальеро 2020 , стр. 11.
  15. Перейти обратно: Перейти обратно: а б Раутенштраух, Pellegrino & Stock 2023 , с. 2747.
  16. Перейти обратно: Перейти обратно: а б с Ван Гетем и др. 2022 , с. 787.
  17. Перейти обратно: Перейти обратно: а б Гелернтер и Герцберг 2015 , стр. 1399–1402.
  18. Перейти обратно: Перейти обратно: а б Судходанан, Ходаяри и Кабальеро, 2020 , стр. 1.
  19. Перейти обратно: Перейти обратно: а б Ван Гётем и др. 2016 , с. 448.
  20. Перейти обратно: Перейти обратно: а б Гелернтер и Герцберг 2015 , с. 1400.
  21. Перейти обратно: Перейти обратно: а б с Ван Гетем и др. 2022 , с. 788.
  22. ^ Раутенштраух, Pellegrino & Stock 2023 , с. 2745.
  23. Перейти обратно: Перейти обратно: а б с Ван Гетем и др. 2022 , с. 785.
  24. Перейти обратно: Перейти обратно: а б с Фельтен и Шнайдер 2000 , с. 26.
  25. Перейти обратно: Перейти обратно: а б Тержанк. «Массовый XS-поиск с использованием атаки на кэш – HackMD» . Гитхаб . Архивировано из оригинала 29 октября 2023 года . Проверено 29 октября 2023 г.
  26. Перейти обратно: Перейти обратно: а б Раутенштраух, Pellegrino & Stock 2023 , с. 2754.
  27. ^ Фельтен и Шнайдер 2000 , стр. 25, 26, 27, 31.
  28. Перейти обратно: Перейти обратно: а б с Бортц и Бонех 2007 , стр. 623–625.
  29. ^ Гелернтер и Герцберг 2015 , стр. 1394–1397.
  30. Перейти обратно: Перейти обратно: а б Уокер, Джеймс (21 марта 2019 г.). «Новые методы XS-Leak открывают новые способы раскрытия пользовательской информации» . Ежедневный глоток . Архивировано из оригинала 29 октября 2023 года . Проверено 29 октября 2023 г.
  31. ^ Ван Гетем и др. 2021 , стр. 1, 6.
  32. ^ Эррера, Луан (31 марта 2019 г.). «XS-поиск в системе отслеживания ошибок Google для обнаружения уязвимого исходного кода» . Середина . Архивировано из оригинала 29 октября 2023 года . Проверено 29 октября 2023 г.
  33. ^ Ван Гётем и др. 2021 , с. 10.
  34. Перейти обратно: Перейти обратно: а б с д Раутенштраух, Pellegrino & Stock 2023 , с. 2756.
  35. ^ Судходанан, Ходаяри и Кабальеро 2020 , стр. 2.
  36. ^ Книттель и др. 2021 , с. 1773.
  37. ^ «Симпозиум IEEE по безопасности и конфиденциальности 2023» . sp2023.ieee-security.org . Архивировано из оригинала 29 октября 2023 года . Проверено 29 октября 2023 г.
  38. ^ Ван Гетем и др. 2022 , с. 784.
  39. ^ Раутенштраух, Pellegrino & Stock 2023 , с. 2748.
  40. ^ Раутенштраух, Pellegrino & Stock 2023 , стр. 2755–2756.
  41. ^ Ван Гетем и др. 2022 , стр. 796, 797.
  42. ^ Вила и Кёпф 2017 , стр. 851–853.
  43. Перейти обратно: Перейти обратно: а б Ван Гетем и др. 2022 , с. 796.
  44. ^ «Производительность — веб-API | MDN» . Веб-документы MDN . 19 февраля 2023 г. Проверено 11 марта 2024 г.
  45. Перейти обратно: Перейти обратно: а б Книттель и др. 2021 , с. 1778.
  46. Перейти обратно: Перейти обратно: а б с Снайдер и др. 2023 , стр. 7095.
  47. ^ Книттель и др. 2021 , с. 1775.
  48. ^ Книттель и др. 2021 , стр. 1775, 1785.
  49. ^ Стаику и Прадель 2019 , стр. 924, 930.
  50. ^ Захери, Орен и Куртмола, 2022 , с. 1505.
  51. ^ Книттель и др. 2021 , с. 1785.
  52. ^ Книттель и др. 2021 , стр. 1777, 1785.
  53. ^ Книттель и др. 2021 , стр. 1778, 1782.
  54. ^ Ван Гетем и др. 2022 , с. 789.
  55. Перейти обратно: Перейти обратно: а б с Мишра и др. 2021 , с. 404.
  56. ^ Фельтен и Шнайдер 2000 , стр. 25, 28, 29.
  57. ^ Bansal, Preibusch & Milic-Frayling 2015 , стр. 97.
  58. ^ Цзя и др. 2015 , стр. 1, 2.
  59. ^ Bansal, Preibusch & Milic-Frayling 2015 , стр. 99.
  60. ^ Ван Гетем, Йосен и Никифоракис, 2015 , стр. 1385, 1386.
  61. ^ Ким, Ли и Ким 2016 , стр. 411–413.
  62. ^ Снайдер и др. 2023 , стр. 7096, 7097.
  63. ^ Книттель и др. 2021 , стр. 1782, 1776–1778.
  64. ^ «XS-Leak: утечка идентификаторов с помощью фокуса» . Исследование ПортСвиггера . 8 октября 2019 года. Архивировано из оригинала 28 декабря 2023 года . Проверено 28 декабря 2023 г.
  65. ^ Ван Гетем и др. 2022 , с. 797.
  66. ^ Нг, Альфред. «Google обнаружил, что функция защиты от отслеживания Apple Safari действительно включает отслеживание» . CNET . Архивировано из оригинала 11 декабря 2023 года . Проверено 28 декабря 2023 г.
  67. ^ Виландер, Джон (10 декабря 2019 г.). «Предотвращение отслеживания. Предотвращение отслеживания» . Вебкит . Архивировано из оригинала 16 ноября 2023 года . Проверено 28 декабря 2023 г.
  68. ^ Янк, Артур; Котович, Кшиштоф; Вайхзельбаум, Лукас; Клапис, Роберто. «Утечка информации через интеллектуальную систему предотвращения отслеживания Safari» . Google Исследования . Архивировано из оригинала 28 декабря 2023 года . Проверено 28 декабря 2023 г.
  69. Перейти обратно: Перейти обратно: а б Книттель и др. 2021 , с. 1780.
  70. ^ Ван Гётем и др. 2021 , с. 16.
  71. ^ Захери и Куртмола, 2021 , с. 160.
  72. ^ Мишра и др. 2021 , с. 399
  73. ^ Доан и др. 2022 .
  74. ^ Китамура, Эйдзи (6 октября 2020 г.). «Обеспечение безопасности и конфиденциальности путем разделения кэша» . Chrome для разработчиков . Архивировано из оригинала 29 октября 2023 года . Проверено 29 октября 2023 г.
  75. Перейти обратно: Перейти обратно: а б Ван Гетем и др. 2021 , с. 7.
  76. ^ Баннистер, Адам (13 октября 2020 г.). «Google Chrome разделяет HTTP-кеш браузера для защиты от атак XS-Leak» . Ежедневный глоток . Архивировано из оригинала 29 октября 2023 года . Проверено 29 октября 2023 г.
  77. ^ Reis, Moshchuk & Oskov 2019 , p. 1674.
  78. ^ Ван Гетем, Санчес-Рола и Йосен 2023 , стр. 379.
  79. ^ Ван Гетем и др. 2022 , с. 792.
  80. ^ «Политика открытия перекрестного происхождения — HTTP | MDN» . Веб-документы MDN . 10 апреля 2023 года. Архивировано из оригинала 31 октября 2023 года . Проверено 31 октября 2023 г.
  81. ^ Китамура, Эйдзи. «Как сделать ваш веб-сайт изолированным от перекрестного происхождения с помощью COOP и COEP | Статьи» . веб.разработчик . Архивировано из оригинала 31 октября 2023 года . Проверено 31 октября 2023 г.
  82. ^ Снайдер и др. 2023 , с.7092.
  83. ^ «Разделение состояний — Конфиденциальность в Интернете | MDN» . Веб-документы MDN . 24 июля 2023 г. Проверено 5 февраля 2024 г.
  84. ^ Ван Гетем и др. 2022 , с. 791.
  85. ^ Кальзавара и др. 2020 , стр. 684, 685.
  86. Перейти обратно: Перейти обратно: а б Ван Гетем и др. 2021 , с. 5.
  87. ^ «Параметры X-Frame — HTTP | MDN» . Веб-документы MDN . 25 июля 2023 года. Архивировано из оригинала 27 октября 2023 года . Проверено 29 октября 2023 г.
  88. ^ «Блокировка чтения из разных источников (CORB)» . Хром Геррит . Архивировано из оригинала 7 ноября 2023 года . Проверено 7 ноября 2023 г.
  89. ^ Reis, Moshchuk & Oskov 2019 , pp. 1665, 1666.
  90. ^ «Политика ресурсов перекрестного происхождения (CORP) – HTTP | MDN» . Веб-документы MDN . 10 мая 2023 года. Архивировано из оригинала 29 октября 2023 года . Проверено 29 октября 2023 г.
  91. Перейти обратно: Перейти обратно: а б Книттель и др. 2021 , с. 1781.
  92. Перейти обратно: Перейти обратно: а б Ходаяри и Пеллегрино 2022 , с. 1592.
  93. ^ Ходаяри и Пеллегрино 2022 , с. 1590.
  94. ^ Ходаяри и Пеллегрино 2022 , стр. 101-1. 1596, 1600.
  95. ^ Компаньа и др. 2021 , стр. 50–51.
  96. ^ «Обход ограничений файлов cookie SameSite | Академия веб-безопасности» . Портсвиггерские исследования . Архивировано из оригинала 29 октября 2023 года . Проверено 29 октября 2023 г.
  97. ^ Ходаяри и Пеллегрино 2022 , стр. 101-1. 1596–1598.
  98. ^ Вайхзельбаум, Лукас. «Защитите свои ресурсы от веб-атак с помощью Fetch Metadata | Articles» . веб.разработчик . Архивировано из оригинала 7 ноября 2023 года . Проверено 7 ноября 2023 г.
  99. ^ Бир и др. 2021 .
  100. ^ «Sec-Fetch-Site – HTTP | MDN» . Веб-документы MDN . 25 октября 2023 г. Архивировано из оригинала 29 октября 2023 г. Проверено 29 октября 2023 г.

Источники [ править ]

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

  • Книттель, Лукас; Майнка, Кристиан; Нимитц, Маркус; Носс, Доминик Тревор; Швенк, Йорг (12 ноября 2021 г.). «XSinator.com: от формальной модели к автоматической оценке межсайтовых утечек в веб-браузерах». Материалы конференции ACM SIGSAC 2021 года по компьютерной и коммуникационной безопасности . Ассоциация вычислительной техники. стр. 1771–1788. дои : 10.1145/3460120.3484739 . ISBN  978-1-4503-8454-4 . S2CID   244077807 .
  • Раутенштраух, Яннис; Пеллегрино, Джанкарло; Сток, Бен (21 мая 2023 г.). «Дырявая сеть: автоматическое обнаружение межсайтовых утечек информации в браузерах и Интернете» . Симпозиум IEEE по безопасности и конфиденциальности (SP) 2023 г. IEEE. стр. 2744–2760. дои : 10.1109/SP46215.2023.10179311 . ISBN  978-1-6654-9336-9 . S2CID   259321089 — через CISPA — базу данных публикаций Центра Гельмгольца по информационной безопасности.
  • Ван Гетем, Том; Франкен, Гертьян; Санчес-Рола, Искандер; Дворкен, Дэвид; Йосен, Воутер (30 мая 2022 г.). «SoK: изучение текущих и будущих направлений исследований XS-Leaks с помощью расширенной формальной модели». Материалы Азиатской конференции ACM по компьютерной и коммуникационной безопасности 2022 года . Ассоциация вычислительной техники. стр. 784–798. дои : 10.1145/3488932.3517416 . ISBN  978-1-4503-9140-5 . S2CID   248990284 .
  • Ван Гетем, Том; Франкен, Гертьян; Санчес-Рола, Искандер; Дворкен, Дэвид; Йосен, Воутер (6 сентября 2021 г.). Понимание межсайтовых утечек и средств защиты (PDF) . 8-й Европейский симпозиум IEEE по безопасности и конфиденциальности (EuroS&P), 2023 г., Материалы семинара SecWeb. п. 1. Архивировано (PDF) оригинала 11 октября 2023 г. Проверено 11 октября 2023 г.

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

Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: ef97ca4f3da2c590ba6467ec776b5d60__1714358340
URL1:https://arc.ask3.ru/arc/aa/ef/60/ef97ca4f3da2c590ba6467ec776b5d60.html
Заголовок, (Title) документа по адресу, URL1:
Cross-site leaks - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)