Комментарии 7
В "Attack scenario" ничего не сказано про Access-Control-Allow-Credentials, а это самый важный момент.
Наглядный пример совершенно не в тему и больше относится к DOM Based XSS.
веб-приложение, с неверно настроенной политикой Access-Control-Allow-Origin
При этом в примере заголовок вообще используется только на сайте злоумышленника.
Может быть не совсем удачный пример, ниже есть пример с HackerOne, правда он тоже связана с XSS.
Про Access-Control-Allow-Credentials Вы правы — для запросов с withCredentials предусмотрено дополнительное подтверждение со стороны сервера.
При запросе с withCredentials сервер должен вернуть уже не один, а два заголовка:
Access-Control-Allow-Origin: домен
Access-Control-Allow-Credentials: true
Про Access-Control-Allow-Credentials Вы правы — для запросов с withCredentials предусмотрено дополнительное подтверждение со стороны сервера.
При запросе с withCredentials сервер должен вернуть уже не один, а два заголовка:
Access-Control-Allow-Origin: домен
Access-Control-Allow-Credentials: true
Статья дает неверный посыл — 'CORS со звездочкой' (которого так боятся начинающие) НЕ ПОЗВОЛЯЕТ проводить атаки с воровством авторизационной куки.
Для того чтобы передавались креденшиалз — требуется заголовок Access-Control-Allow-Credentials.
Для того чтобы передавались креденшиалз — требуется заголовок Access-Control-Allow-Credentials.
Не понял в чем дыра...
Автор накрутил...
Проблема 1 в том что JS на уязвимом сайте не валидирует GET параметры. С тем же успехом можно было выполнять код из GET параметра.
Проблема 2 в том что сайт рассчитывает что браузер не делает кроссдоменных AJAX запросов. Но это не так. Браузер таки всегда делает их, а CORS управляет тем будет ли виден результат странице, сделавшей вызов.
На сайте необходима проверка csrf токена, тогда неправильный cors сильно не навредит, запрос не пройдет. А если csrf возможна, то какой уж тут cors, и без него дыра дырой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Небезопасный cross-origin resource sharing