Как использовать шаблон маркера синхронизатора для предотвращения безопасности CSRF?

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

Скажем, у меня есть сайт поддельного банка fakebank.com с двумя URL-адресами:

  • fakebank.com/withdrawForm.html - запрос GET, который отображает форму снятия денег
  • fakebank.com/doWithdraw - POST к этому URL-адресу, чтобы сделать вывод

Мое понимание недостатка безопасности заключается в том, что maliciousSite.com может обмануть запрос POST на fakebank.com/doWithdraw, и если вы в настоящее время вошли в fakebank, POST будет успешным.

Скажем, мы реализуем шаблон маркера синхронизатора, который будет вставлять секретный код на fakebank.com/withdrawForm.html. Не может maliciousSite.com просто подделать запрос GET для этой формы, проанализировать результат html, получить токен и затем создать запрос POST с этим токеном?

Это предполагает, что fakebank.com не проверяет HTTP-ссылку или Origin или maliciousSite.com успешно подделывает, что Referrer/Origin является fakebank.com.

Ответы

Ответ 1

Причина, по которой это безопасно, и maliciousSite.com не может просто сделать GET, украсть токен, а затем сделать POST в том, что запрос выполняется браузером пользователя, а не сервером в maliciousSite.com. Все данные, возвращаемые с fakebank.com, возвращаются в браузер пользователя, а не на сервер maliciousSite.com. Если maliciousSite.com выполняет GET для получения токена, это будет другой токен, который был выдан пользователю. maliciousSite.com не может установить этот файл cookie в пользовательский браузер для отправки на fakebank.com из-за ограничений на один домен.

Атака CSRF POST работает, обманывая пользовательский браузер, запрашивая fakebank.com/withdrawForm.html напрямую, используя правильно сформированный запрос POST. Сервер fakebank.com счастливо выполняет запрошенный POST, тем самым перенося средства, используя параметры, предоставленные в теле POST (которые включают в себя адрес назначения, принадлежащий злоумышленнику, который был помещен туда maliciousSite.com). Серверу maliciousSite.com не нужно видеть возвращенные данные, поскольку действие было выполнено (если только fakebank.com не использует эти токены CSRF, которые maliciousSite.com не может знать, если только это не было разглашено каким-либо образом Он не может просить об этом). Если fakebank.com использует токены CSRF, то maliciousSite.com отправит запрос POST, в котором отсутствует токен, что указывает на потенциальную атаку CSRF.

Уязвимость этого метода включает использование токена CSRF, который не является достаточно секретным и каким-то образом разглашается. Кроме того, если токен CSRF не является достаточно случайным, то maliciousSite.com может угадать его. Кроме того, если есть слабость в применении браузером той же политики домена, это может быть использовано. Вообще говоря, современные браузеры не уязвимы для этого.

Пожалуйста, дайте мне знать, если это недостаточное объяснение, и я попытаюсь сформулировать его немного лучше для вас.

Ответ 2

И это точно так. Одинаковая политика происхождения в браузере не разрешает запросы GET на другие сайты. Таким образом, ни один сайт не может получить токен CSRF от другого, используя Javascipt в браузере.