Как токены CSRF защищают от вредоносных GET, за которыми следует POST на другой вкладке

Я знаю, что что-то упускаю, но, пожалуйста, помогите мне понять. Рассмотрим такую ​​ситуацию: у меня есть веб-сайт goodbank.com. URL-адрес http://goodbank.com/transfer/ служит HTML-страницей в GET с формой для перевода денег на другой аккаунт. Форма имеет случайный токен для предотвращения атаки CSRF. На сервере действительность токена проверяется при POST, и соответствующий контроллер разрешает только аутентифицированные сеансы.

Допустим, в моем браузере я вхожу на сайт goodbank.com/. В другой вкладке я захожу на robgoodbank.com. Как часть обслуживаемой страницы, он имеет javascript для выполнения запроса AJAX на goodbank.com/transfer/ для получения действительной формы. Затем он заполняет другие поля в форме и выполняет POST. Мой аккаунт удален :(

Как существующие схемы защиты защищают от такой атаки?

Заранее спасибо.


csrf csrf-protection
person user1486451    schedule 15.05.2013    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

Для дополнительной защиты ваш сервер должен проверить Origin, если он присутствует, и HTTP-заголовок Referer, который будет "http://robgoodbank.com" в вашем примере, и вы также можете отклонить запрос.

Они ни в коем случае не являются надежными, но обеспечивают дополнительные уровни защиты. Существуют механизмы (такие как расширения) для подмены Referer, но пользователь мог бы использовать их, если только их браузер не был каким-либо образом скомпрометирован. Если их браузер был скомпрометирован, у них гораздо больше проблем...

person Stuart Carnie    schedule 12.02.2014
comment
Просто чтобы добавить к этому, важными исправлениями здесь являются проверки реферера и происхождения. Без них было бы достаточно просто выполнить запрос GET в скрытом iframe, чтобы получить любой токен анти-csrf, который можно использовать в последующем запросе POST. - person Steven Bakhtiari; 25.04.2014