Cross-Origin Resource Sharing (CORS) - я что-то упустил?

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

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

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

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

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

Поставьте страницу со списком приемлемых серверов CORS (abc.com, xyz.com и т.д.)
Страница хочет сделать запрос XHR на abc.com - браузер разрешает это, потому что он в разрешенном списке и аутентификации протекает как обычно.
Страница хочет сделать запрос XHR на malicious.com - запрос отклонен локально (т.е. браузером), потому что сервер отсутствует в списке.

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

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

Ответ 1

Но что, если вредоносный код на странице хочет ПОЧТАТЬ конфиденциальную информацию на чужом сайте?

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

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

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

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

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

Ответ 2

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

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

Я расскажу об этом более подробно здесь:

Ответ 3

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

Ответ 4

Проблема заключается не в том, что сайт может получить доступ к ресурсам других сайтов, к которым у него уже был доступ. Проблема заключается в одном из доменов. Если я использую браузер в своей компании, а ajax script злонамеренно решает попробовать 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-совместимый браузер WONT делает это. Браузер контролирует взаимодействие. Браузер препятствует доступу bobthehacker.com к шлюзу. Это та часть, которую вам не хватает.

Ответ 5

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

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

Ответ 6

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

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

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

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