Ответ 1

Чтобы быть более конкретным, легко сделать ошибку, считая, что если evil.com не может сделать запрос на good.com из-за CORS, то CSRF будет предотвращен. Однако есть две проблемы:

• CORS уважают только браузеры. Это означает, что Google Chrome будет подчиняться CORS и не позволит evil.com делать запрос на good.com. Однако представьте себе, что кто-то создает собственное приложение или что-то еще, что имеет форму POST-вещей на вашем сайте. Знаки XSRF - единственный способ предотвратить это.

• Легко ли игнорировать тот факт, что CORS предназначен только для запроса JS. Регулярная форма на evil.com, что POSTs обратно на good.com будет работать, несмотря на CORS.

По этим причинам CORS не является хорошей заменой токенам XSRF. Лучше использовать оба.

Ответ 2

Нет!

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

Я не понимаю, что вы подразумеваете под "CORS правильно настроен", но при атаке с помощью XSRF браузер не запрашивает заголовки CORS на сервере.

CORS не является безопасностью:)

Ответ 3

Нет.

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

Агрессивная атака на основе кросс-сайта - это когда сторонний сайт маскируется как пользователь на отправлять данные на другой сайт (в качестве этого пользователя). Ему не нужно читать ответ.

Ответ 4

Может

Человек это жесткий, и он намного сложнее, чем другие. "Возможно"

Во-первых, CORS предназначен для "ослабления" политики одного и того же происхождения, которая по умолчанию предотвращает определенный тип атаки CSRF. Но то же самое происхождение не применяется ко всем видам запросов.

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

Для примера, проверьте это.

<img src=victim.bank/check.png?account=...>; чтобы получить чек-фотографию с уязвимого банковского сайта, без генерации заголовков источника или предпроданных запросов. [...] Фотографии будут отображаться, а злоумышленники могут получить фотоданные с помощью Javascript и отправить их обратно. источник

Однако, по крайней мере, один источник предполагает, что, возможно, в будущем веб-серверы возвратят изображения с заголовками Access-Control-Allow-Origin (CORS) на изображениях, которые не позволят браузерам отображать изображение. Это предотвратит атаки CSRF-GET такого типа.

Если браузер проверяет заголовок Access-Control-Allow-Origin в ответе и отказывается отображать его, он будет эффективной защитой. источник

Ответ 5

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