Понимание CSRF - PullRequest
       26

Понимание CSRF

31 голосов
/ 06 апреля 2010

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

С OWASP :

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

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

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

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

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

Ответы [ 4 ]

27 голосов
/ 06 апреля 2010

Атакующий не может получить токен. Поэтому запросы не будут иметь никакого эффекта.

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

11 голосов
/ 06 апреля 2010

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

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

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

7 голосов
/ 31 января 2018

CSRF Объяснено по аналогии - Пример:

Представьте, что вы открываете входную дверь, используя ключ - ваш ключ. никто другой не имеет вашего ключа. Вы открываете дверь, но перед тем, как войти внутрь, ваш сосед звонит вам через дорогу, и вы оба очень дружелюбно беседуете о погоде или, возможно, о последних твиттах президента Трампа в 3.45 и т. Д. вы, кто-то другой видит вас снаружи, и решает выдать себя за вас, надев ту же одежду и прическу, и решает пойти в ваш собственный дом, притворяясь вами!

Никто в твоем доме не замечает ничего другого - твоя жена похожа, "о боже, он дома".

Имитатор помогает себе на все ваши деньги и, возможно, поиграет в Xbox, и никто не станет мудрее.

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

Как решить эту проблему?

Когда вы впервые открываете дверь в свой дом, вам дается бумага с длинным и очень случайным числом, написанным вашим дверным служащим:

"ASDFLJWERLI2343234"

Теперь, если вы хотите попасть в свой собственный дом, вы должны подарить этот кусок бумаги дверному прохожему.

Итак сейчас когда подражатель пытается проникнуть в ваш дом, дверной человечек спрашивает:

«Какое случайное число написано на бумаге?»

Если подражатель не имеет правильного числа, он не сможет войти. Либо это, либо он должен правильно угадать случайное число - что является очень сложной задачей. Что еще хуже, случайное число действительно только в течение 20 минут (например). Так что знайте, что подражатель должен правильно угадать, и не только это, у него есть всего 20 минут, чтобы получить правильный ответ. Это слишком много усилий! И он сдается.

Конечно, аналогия немного натянута, но я надеюсь, что она вам пригодится.

** crud = (Создать, прочитать, обновить, удалить)

5 голосов
/ 06 апреля 2010

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

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

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

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

...