Почему токен CSRF должен находиться в метатеге и в cookie?

Для чего нужно указать имя и значение токена CSRF внутри тега <head> , используя <meta> , например:

например:

<meta content="authenticity_token" name="csrf-param" />
<meta content="4sWPhTlJAmt1IcyNq1FCyivsAVhHqjiDCKRXOgOQock=" name="csrf-token" />

Я прочитал о концепции, чтобы сохранить значение CSRF в файле cookie, но не обнаружил, почему сохранить внутри тега <head> .

Ответ 1

Чтобы предотвратить CSRF, вам нужно значение, которое отправляется с запросом, который не может быть отправлен вредоносным сайтом. Файлы cookie подлинности не подходят, потому что если злоумышленник может заставить браузер отправить запрос на сайт жертвы, файлы cookie будут автоматически отправлены.

Например, отправив форму через JavaScript, содержащуюся в www.evil.com, для атаки пользовательского сеанса на www.example.com:

<form method="post" action="https://www.example.com/executeAction">
    <input type="hidden" name="action" value="deleteAllUsers">
</form>

<script>document.forms[0].submit()</script>

Сохранение антивируса CRSF на странице является рекомендуемым решением OWASP для предотвращения отправки другим веб-сайтом формы, поскольку случайный токен в сеансе пользователя не может читайте www.evil.com из-за политики одинакового происхождения, предотвращая JavaScript на www.evil.com, читая содержимое страницы www.example.com.

Эти токены могут храниться в любом месте страницы. Чаще всего это будет в скрытых формах, но они также могут быть сохранены в атрибутах данных HTML 5. Похоже, что использование тегов meta - это просто другой способ, которым он может быть сохранен, где JavaScript может включать его в любые формы, предоставляемые этой страницей.

Ответ 2

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

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

Ответ 3

Это потому, что ничто не останавливает оскорбительный веб-сайт от POSTing данных до законного веб-сайта, который может включать ваш билет аутентификации и ваш токен CSRF. Представьте себе этот сценарий... взятый из ASP.NET

Пользователь регистрируется на сайте www.siteA.com, используя проверку подлинности форм.
Сервер аутентифицирует пользователя. Ответ с сервера включает файл cookie аутентификации.

Без выхода из системы пользователь посещает вредоносный веб-сайт. Этот вредоносный сайт содержит следующую HTML-форму:

<h1>You Are a Winner!</h1>
    <form action="http://siteA.com/api/account" method="post">
        <input type="hidden" name="Transaction" value="withdraw" />
        <input type="hidden" name="Amount" value="1000000" />
 <input type="submit" value="Click Me"/>
    </form>

Обратите внимание, что действие формы отправляется на уязвимый сайт, а не на вредоносный сайт. Это "кросс-сайт" часть CSRF.

Пользователь нажимает кнопку отправки. В обозревателе указан файл cookie проверки подлинности с запросом. Запрос выполняется на сервере с контекстом проверки подлинности пользователей и может выполнять все, что разрешен для аутентифицированного пользователя.

В принципе, когда siteA.com получает атаку CSRF, он должен сопоставлять токен CSRF в cookie с тем, что находится в метатеге. В законный запрос будут включены оба, однако атака подделки будет включать только токен CSRF, указанный в файле cookie.

Ответ 4

Единственный вариант, который я мог себе представить, - сделать доступ к этим данным из JavaScript. Причина в том, что файлы cookie только http.