Сложный вопрос для хорошего понимания CSRF

Question

У меня и моего друга пари на пиво.

Из википедии:

Требуется секрет, специфичный для пользователя токен во всех формах представления и URL побочных эффектов предотвращают CSRF; сайт злоумышленника не может поставить право токен в его представлениях

Атакер может использовать файлы cookie браузера косвенно, но он не может использовать их напрямую! Вот почему он не может поместить куки в ссылку, используя document.write()

Давайте посмотрим, как генерируется ссылка для выхода из системы. Это безопасный способ? Можно ли подделать этот запрос GET?

function logout(){
     echo '<a href="?action=logout&sid='.htmlspecialchars($_COOKIE['sid']).'>Logout</a>';
}

sid - идентификатор сеанса, сгенерированный для каждого сеанса

на стороне сервера выполняется следующая проверка:

$_GET['sid']==$_COOKIE['sid']

Answer 1

Эта предполагаемая система безопасности невосприимчива к CSRF .Причина этого заключается в том, что при атаке CSRF браузер отслеживает cookie, поэтому злоумышленнику не нужно знать значение cookie при создании запроса .Если эта предложенная система безопасности уязвима для CSRF, то эксплойт, подобный следующему Доказательству концепции, выйдет из браузера:

<img src=http://victim_site/index.php?action=logout&sid= />

Очевидно, что в этом случае sid требуется значение, и атакующийне может получить это значение без использования XSS, что делает его спорным.Используя xss, злоумышленник может прочитать токен CSRF для подделки запросов.Это было использовано в MySpace черве Sammy .

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

Answer 2

Абсолютно не ! Никогда не используйте идентификаторы сеанса для защиты CSRF.

Насколько, почему? Ну, ответ прост. Это открывает дверь для захвата сеанса атак. Представьте, что кто-то по какой-то причине копирует и вставляет ссылку в электронное письмо или в Интернет. Теперь у человека на другом конце электронного письма есть идентификатор сеанса этого сеанса. Конечно, если они нажмут на ссылку, это не активирует сеанс, но тот, кто знает, что делает, все равно сможет его использовать.

И не используйте секретное печенье тоже. Файлы cookie передаются по каждому запросу. Таким образом, само существование файла cookie не подтверждает, что пользователь намеревался сделать запрос.

Как это сделать вместо этого? Следуйте рекомендациям OWASP . Используйте уникальный случайный токен, который выдается при каждом запросе и связан с сеансом. Затем убедитесь, что токен действителен при отправке, а затем аннулируйте токен ! Это должен быть токен одноразового использования. Отправьте его в форме и не прикрепляйте к ссылке напрямую ...

Answer 3

Редактировать : Этот ответ по крайней мере частично неверен.Использование идентификатора сеанса в качестве токена CSRF может привести к перехвату сеанса, если, например, ссылки копируются + вставляются.См. Ответ и комментарии ircmaxell.

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

Тем не менее, было бы еще безопаснее использовать другое случайное число, если нет вероятности, что вредоносный JavaScript сможет захватить cookie сеанса (и идентификатор сеанса) ... Но если япришлось выбирать между «без токена CSRF» и «идентификатором сеанса в качестве токена CSRF», я всегда выбирал сеанс в качестве токена CSRF.

Единственная потенциальная проблема с использованием идентификаторов сеанса в качестве токенов CSRF:если бы кто-то смог украсть токен CSRF, он также мог бы украсть связанную с ним сессию ... Но я не могу придумать разумного сценария, в котором это было бы проблемой.

Теперь из обсужденияОтвет Марка Б ниже: использование nonce обеспечит другие преимущества (например, предотвращение повторной отправки форм) ... Но это не более безопасно от атак CSRF, чем идентификатор сеанса (содно предупреждение, которое я упоминаю в первом втором абзаце).

См. также: Маркер проверки CSRF: идентификатор сеанса безопасен?

Answer 4

А что мешает кому-то редактировать отправленный им HTML-код, а также файлы cookie, которые вы также отправляете им?Оба находятся под контролем пользователя.

С помощью firebug я могу тривиально изменить содержимое любой страницы, а также любой файл cookie.

Теперь, если бы вы изменили свою версию такчто СЕРВЕР хранит этот идентификатор, тогда будет сложнее взломать ...

$_SESSION['form_token'] = 's33krit valu3';

if ($_POST['form_token'] == $_SESSION['form_token']) {
  ... everything's ok ...
}

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

---

Вы должны своему другу пиво.