Как предотвратить повтор воспроизведения формы / атаки типа «человек посередине» в PHP, csrf, xsrf - PullRequest
11 голосов
/ 09 октября 2009

У меня есть веб-форма, и я использую PHP. Я знаю, что формами можно манипулировать (я считаю, что это называется повторной атакой или атакой «человек посередине»). Поэтому я хотел бы использовать маркер аутентичности в качестве скрытого поля.

Возможные угрозы:

  • Атакующий захватывает легитимную форму пользователя (я полагаю, это атака «человек посередине»)
  • законный пользователь сам является нападающим: он получает форму, читает токен, но использует ее для отправки опасных данных (я полагаю, это атака воспроизведения)

Прежде чем я перейду к вопросам, поправьте меня, если что-то, что я сказал до сих пор, неверно, потому что, возможно, мое понимание неверно.

Теперь к вопросам:

  • Как лучше всего генерировать этот токен, чтобы форма без него была отклонена (например, засолка?).
  • Что делают люди, чтобы убедиться, что токен не воспроизводится.

Новые небольшие вопросы на основе комментариев:

  • Является ли сессия захватом такой же, как атака "человек посередине"?

Ответы [ 4 ]

5 голосов
/ 09 октября 2009

Вы упомянули CSRF в названии, но не затронули его в своем вопросе.

Вы можете прочитать об этом подробно онлайн , но CSRF - это, по сути, атака, которая позволяет легитимному пользователю отправиться на сайт по незнанию. Например, если SO не защищает от таких атак, я мог бы создать форму, которая приводит к изменению информации вашего профиля SO, когда вы нажимаете на эту мою плохую форму, ожидая, что произойдет что-то еще («Выиграйте миллион долларов!» Кликните сюда!!"). Эта форма будет использовать куки-файлы вашего браузера, чтобы авторизовать вас с помощью SO и дать понять SO, что вы законно отправляете обновления в свой профиль.

Чтобы защититься от этого, вы действительно хотите сделать пару вещей:

  • убедитесь, что GET не вызывают обновления (например, не публикуйте новое обновление статуса в профиле пользователя с использованием параметров запроса в GET)
  • гарантирует, что все POST сопровождаются скрытым полем, которое позволяет вам проверить, что форма была сгенерирована вашим сервисом, а не кем-то другим, и что она была предназначена для предполагаемого пользователя. Таким образом, это скрытое поле должно генерироваться сервером каждый раз, когда он отправляет html для формы, и должно быть уникальным для этого пользователя для этого сеанса.

Альтернативой этому второму пункту является проверка того, что рефералом всегда является ваш сайт или сайт, от которого вы ожидаете POST. Я не поощряю это для сайтов, не поддерживающих HTTPS, потому что некоторые браузеры / сетевое оборудование убирают ссылки, и не всегда надежно, что существует ссылка.

3 голосов
/ 09 октября 2009

Метод, используемый для генерации токена, не очень важен. Важно то, что токен будет использоваться только один раз. Храните список токенов, сгенерированных для пользователя, в сеансе пользователя. Если пользователь отправляет форму, а отправленный токен отсутствует в сеансе, вы можете отклонить форму.

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

Когда пользователь успешно отправит форму с токеном, удалите токен из сеанса, поэтому любое воспроизведение этой отправки завершится неудачно. Тем не менее, все, что требуется, это пользователь, снова запрашивающий форму для создания другого токена. Этот новый токен может быть использован в последующих автоматических атаках. Другими словами, токены форм полезны против CSRF, но не очень эффективны против автоматических реплеев и атак «человек посередине».

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

Кроме того, честно говоря, к тому времени, когда вам нужно беспокоиться о повторных запросах и атаках типа «человек посередине», соединение вашего пользователя уже взломано, и вы, вероятно, не так уж много можете сделать, чтобы уменьшить любой ущерб. SSL сам по себе является достаточным уровнем защиты от MITM и воспроизведения, и если вас это беспокоит, вы будете работать под SSL ...

1 голос
/ 10 октября 2009

Чтобы сгенерировать этот токен, вот стратегия, которую я использую, которая, кажется, работает хорошо.

  • Установите для cookie случайное значение (генерируемое на сервере с использованием обычных приемов) и установите его срок действия в соответствии с вашими потребностями.
  • При открытии страницы с формой вставьте скрытое поле, значение которого равно значению этого файла cookie.
  • При обработке сообщения убедитесь, что это поле существует и что значение соответствует cookie пользователя
0 голосов
/ 17 июня 2014

csrf-magic - отличный класс для токенов CSRF, он автоматически помещает их на вашу страницу

http://csrf.htmlpurifier.org/

"csrf-magic использует возможности буферизации вывода PHP для динамического переписывания форм и скриптов в вашем документе. Он также будет перехватывать запросы POST и проверять их токен (используются различные алгоритмы; некоторые генерируют одноразовые номера, некоторые генерируют пользовательские токены). Это означает, что для традиционного веб-сайта с формами вы можете вставить csrf-magic в свое приложение и забыть об этом! "

...