Риски безопасности CSRF, если токен проверки в заголовке вместо тела POST - PullRequest
3 голосов
/ 27 сентября 2011

Наиболее распространенное решение по поиску технических предупреждений CSRF - это то, что реализует MVCAntiForgeryToken (поставляется с MVC 3), где клиент сервера должен публиковать токен проверки в теле POST. На стороне сервера он будет проверен на соответствие токену в Cookie.

Одинаково ли безопасно отправлять токен проверки в настраиваемом заголовке, а на стороне сервера проверять значение настраиваемого токена с одним присутствующим в cookie?

1 Ответ

1 голос
/ 24 июля 2012

Это еще более безопасно :), потому что даже если злоумышленник может получить действительный токен csrf для текущей транзакции, он должен будет создать междоменный запрос ajax для включения в запрос пользовательских заголовков.И если пользователь отключил js в своем браузере, то злоумышленник поджаривается :).Однако его можно переопределить с помощью java-апплетов ... но вы знаете, что если пользователи необразованы и злоумышленник действительно мотивирован, вы можете сделать очень мало;).

Но есть проблема, что не все пользовательские заголовки будутперенаправляется в случае, если пользователь обращается к нам через брандмауэр или корпоративный прокси.Поэтому я думаю, что это основная причина использования поля вместо пользовательского заголовка.Хотя есть заголовок, который предотвращает атаки XSRF: Источник , Концепция веб-источника также в качестве дополнительной информации Политика безопасности контента 1.1 этотолько проект, но некоторые интересные идеи представлены там.

...