CSRF (Подделка запроса перекрестного сайта) нападают на пример и предотвращение в PHP
У меня есть веб-сайт, куда люди могут поместить голосование как это:
http://mysite.com/vote/25
Это поместит голосование по объекту 25. Я хочу только сделать это доступным для зарегистрированных пользователей, и только если они хотят сделать это. Теперь я знаю, когда кто-то занят на веб-сайте, и кто-то дает им ссылку как это:
http://mysite.com/vote/30
затем голосование будет местами для него на объекте без него желающий сделать это.
Я считал объяснение на веб-сайте OWASP, но я действительно не понимаю это
Действительно ли это - пример CSRF, и как я могу предотвратить это. Лучшая вещь я могу думать прочь, добавляет что-то к ссылке как хеш. Но это будет довольно раздражающим для помещения чего-то на конец всех ссылок. Нет ли никакой другой способ сделать это.
Другая вещь может кто-то, возможно, давать мне некоторый другой пример этого, потому что веб-сайт кажется справедливо фугой мне.
2 ответа
Это может стать примером CSRF, если:
- эта ссылка извлекается (например, с помощью тега
- с другого сайта: межсайтовый
Например, если бы я мог ввести это тег в исходном HTML-коде stackoverflow (и я могу, поскольку stackoverflow позволяет использовать теги
в своих сообщениях) :
<img src="http://mysite.com/vote/30" />
Вы бы просто проголосовали за этот элемент; -)
Обычно используется решение: разместить токен с ограниченным временем жизни в URL-адресе, а при получении URL-адреса установить флажок что этот токен все еще действителен.
Основная идея:
- При создании страницы:
- сгенерировать уникальный токен
- сохранить его в сеансе пользователя
- и поместить в ссылки на странице - которые будут выглядеть так:
http://mysite.com/vote/30?token=AZERTYUHQNWGST
- При вызове страницы голосования:
{{1} }
- Проверить, присутствует ли токен в URL
- Проверить, присутствует ли он в сеансе пользователя
- Если нет => не регистрировать голосование
Идея такая:
- Токены не у них долгий срок службы, и их трудно угадать
- Это означает, что ваш злоумышленник :
- имеет только окно в несколько минут, в течение которого его инъекция будет действительной
- должен уметь угадывать ^^
- должен будет генерировать разные страницы для каждого пользователя.
Также обратите внимание, что чем короче сеанс пользователя остается активным после того, как он покинул ваш сайт, тем меньше рисков, что он все еще действителен, когда он посещает плохой веб-сайт.
Но здесь вы должны выбирать между безопасностью и удобством ...
Другая идея (это не совсем безопасно, но помогает против парней, которые не знают, как принудительно отправить POST-запрос) , будет принимать запросы POST только тогда, когда люди голосуют:
- Браузер отправляет запросы GET для внедренных тегов
- Поскольку этот URL-адрес изменяет некоторые данные, в любом случае он не должен работать с GET, а только с POST
Но обратите внимание, что это не совсем безопасно: (вероятно?) возможно принудительно / подделать запрос POST с помощью некоторого фрагмента Javascript.
Во-первых, GET запрос не должен использоваться для изменения состояния на сервере, поэтому для вашего сервиса голосования я бы рекомендовал POST/PUT. Это всего лишь рекомендация, но разумная.
Итак, отвечая на ваш вопрос, CSRF - это проблема клиента, поэтому не имеет значения, какой язык сервера вы используете (в вашем случае PHP). Стандартное решение проблемы одинаково и выглядит следующим образом: Задайте случайное значение в URI/POST-данных и такое же значение в заголовке Cookie. Если они совпадают, вы можете быть уверены, что CSRF нет. Есть много информации о том, как это можно сделать на StackOverflow, например этот.
Удачи!