Понимание CSRF

Я не понимаю, как использование "токена вызова" добавит какие-либо предупреждения: какое значение должно сравниться с чем?

От OWASP:

В общем, разработчикам нужно только генерируйте этот токен один раз для текущая сессия. После первоначального генерация этого токена, значение хранится в сеансе и используется для каждого последующего запроса до сеанс истекает.

Если я правильно понял процесс, это то, что происходит.

Я вхожу в систему http://example.com, и создается сеанс/файл cookie, содержащий этот случайный токен. Затем каждая форма содержит скрытый ввод, содержащий это случайное значение из сеанса, которое сравнивается с сеансом /cookie при отправке формы.

Но что это значит? Разве вы не просто берете данные сеанса, не помещаете его на страницу, а затем сравниваете с теми же данными сеанса? Похоже на круговые рассуждения. В этих статьях постоянно говорится о политике "одного и того же происхождения", но это не имеет никакого смысла, поскольку все атаки CSRF имеют тот же источник, что и пользователь, просто обманывая пользователя в действиях, которые он/она не намеревался.

Есть ли альтернатива, кроме добавления токена к каждому URL-адресу в виде строки запроса? Кажется очень уродливым и непрактичным, и делает закладки более сложными для пользователя.

Ответ 1

Злоумышленник не имеет возможности получить токен. Поэтому запросы не будут иметь никакого эффекта.

Я рекомендую этот пост от Gnucitizen. У этого есть довольно приличное объяснение CSRF: http://www.gnucitizen.org/blog/csrf-demystified/

Ответ 2

Вам нужно продолжать изучать эту тему для себя, но я думаю, почему вы отправляете SO:). CSRF - очень серьезный и распространенный тип уязвимости, о котором должны знать все разработчики веб-приложений.

Прежде всего, существует более одной той же политики происхождения. Но самая важная часть заключается в том, что script, размещенный из http://whatever.com, не может читать данные из http://victom.com, но он может передавать данные через POST и GET. Если запрос содержит только информацию, известную злоумышленнику, тогда злоумышленник может подделать запрос в браузере victom и отправить его в любом месте. Вот 3 XSRF-эксплоиты, которые строят запросы, которые не содержат случайный токен.

Если сайт содержит случайный токен, тогда вы должны использовать XSS для обхода защиты, предусмотренной политикой того же происхождения. Используя XSS, вы можете заставить javascript "зарождаться" из другого домена, тогда он может использовать XmlHttpRequest, чтобы прочитать токен и подделать запрос. Вот exploit Я написал, что делает именно это.

Ответ 3

Есть ли альтернатива, кроме добавление токена к каждому URL как строка запроса? Кажется очень уродливым и нецелесообразно, и делает закладок сложнее для пользователя.

Нет причин добавлять токен к каждому URL вашего сайта, если вы гарантируете, что все запросы GET на вашем сайте доступны только для чтения. Если вы используете запрос GET для изменения данных на сервере, вам необходимо защитить его с помощью токена CSRF.

Забавная часть с CSRF заключается в том, что, хотя злоумышленник может сделать любой HTTP-запрос на ваш сайт, он не может прочитать ответ.

Если у вас есть URL-адреса GET без случайного токена, злоумышленник сможет сделать запрос, но он не сможет прочитать ответ. Если этот URL-адрес изменил какое-то состояние на сервере, работа злоумышленников завершена. Но если только что сгенерировал некоторый html, злоумышленник ничего не выиграл, и вы ничего не потеряли.