Обмен ресурсами между источниками (CORS) - я что-то здесь упускаю?

Question

Я читал о CORS , и я думаю, что реализация проста и эффективна.

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

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

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

Таким образом, расширенная последовательность будет:

1. Предоставить страницу со списком допустимых серверов CORS (abc.com, xyz.com и т. Д.)
2. Пейдж хочет сделать XHR-запрос к abc.com - браузер разрешает это, потому что он находится в списке разрешенных, а аутентификация проходит как обычно
3. Страница хочет сделать XHR-запрос к malware.com - запрос отклонен локально (т. Е. Браузером), поскольку сервера нет в списке.

Я знаю, что вредоносный код все еще может использовать JSONP для своей грязной работы, но я бы подумал, что полная реализация CORS подразумевает закрытие многосайтовой лазейки тега script.

Я также ознакомился с официальной спецификацией CORS (http://www.w3.org/TR/cors)) и не смог найти упоминания об этой проблеме.

Answer 1

Но что, если вредоносный код на странице захочет разместить конфиденциальную информацию пользователя на чужом сайте?

Как насчет этого? Вы уже можете сделать это без CORS. Даже до Netscape 2 вы всегда могли передавать информацию на любой сторонний сайт с помощью простых запросов GET и POST, вызванных такими простыми интерфейсами, как form.submit(), new Image или установкой window.location.

Если вредоносный код имеет доступ к конфиденциальной информации, вы уже полностью потеряны.

3) Страница хочет сделать XHR-запрос к malware.com - запрос отклонен локально

Почему страница пытается отправить XHR-запрос на сайт, которого она еще не занесла в белый список?

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

Answer 2

Ваши заботы полностью действительны.

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

Подробнее об этом я расскажу здесь:

• http://isisblogs.poly.edu/2011/06/22/cross-origin-resource-inclusion/
• http://files.meetup.com/2461862/Cross-Origin%20Resource%20Inclusion%20-%20Revision%203.pdf

Answer 3

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

Answer 4

Проблема не в том, что сайт может получить доступ к ресурсам других сайтов, к которым у него уже был доступ. Проблема связана с доменом - если я использую браузер в своей компании, и ajax-скрипт злонамеренно решает попробовать 10.0.0.1 (возможно, мой шлюз), он может иметь доступ просто потому, что запрос теперь поступает от моего компьютер (возможно 10.0.0.2).

Итак, решение - CORS. Я не говорю, что это лучше, но решает эту проблему.

1) Если шлюз не может вернуть обратно принятый исходный заголовок «bobthehacker.com», запрос отклоняется браузером . Это обрабатывает старые или неподготовленные серверы.

2) Если шлюз допускает только элементы из домена myinternaldomain.com, он отклонит ORIGIN из «bobthehacker.com». В случае SIMPLE CORS он все равно будет возвращать результаты. По умолчанию; вы можете настроить сервер даже не делать этого. Затем результаты отбрасываются без загрузки браузером .

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

Примечание. Заголовки ORIGIN и OPTIONS контролируются запрашивающей стороной - очевидно, кто-то, создающий собственный HTTP-запрос, может поместить туда все, что он захочет. Однако современный CORS-совместимый браузер этого НЕ БУДЕТ. Это браузер, который контролирует взаимодействие. Браузер не позволяет bobthehacker.com получить доступ к шлюзу. Это та часть, которую вам не хватает.

Answer 5

Я также ознакомился с официальной спецификацией CORS и не смог найти упоминания об этой проблеме.

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

Хорошая новость заключается в том, что - это широко распространенная спецификация , решающая эту проблему: Content-Security-Policy . Это позволяет вам указывать браузеру устанавливать ограничения на возможности вашей страницы.

Например, вы можете указать браузеру не выполнять никаких встроенных сценариев, которые сразу же победят многие атаки XSS. Или - как вы просили здесь - вы можете явно указать браузеру, с какими доменами страница может контактировать.

Answer 6

Я разделяю озабоченность Дэвида. Безопасность должна быть построена слой за слоем, и белый список, обслуживаемый сервером происхождения, кажется хорошим подходом.

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