Разделение ресурсов перекрестного источника (CORS) - я пропускаю что-то здесь?

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

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

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

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

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

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

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

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

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

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

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

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

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