Остановка бота [SO] - PHP - PullRequest
2 голосов
/ 08 мая 2011

Я сохранил этот код в index.php и после заполнения нажал кнопку «Отправить», а затем мне показали страницу подтверждения!
У меня вопрос как он обнаружил, что он не был с исходного сервера ?
[я надеюсь, что они не используют реферера, так как его легко отключить]

Мой поддельный код

<html>
 <form id="post-form" action="http://stackoverflow.com/questions/ask/submit" method="post">
  <input id="title" name="title" type="text" maxlength="300" tabindex="100" class="ask-title-field" value="">                        
  <textarea id="wmd-input" name="post-text" cols="92" rows="15" tabindex="101"></textarea>
  <input id="tagnames" name="tagnames" type="text" size="60" value="" tabindex="103">
  <input id="submit-button" type="submit" value="Post Your Question" tabindex="120">  
 </form>
</html>  

Может ли кто-нибудь помочь мне создать такую ​​безопасную страницу [где, если пользователь попытается опубликовать пост с скучной страницы, его попросят подтвердить] ?

Ответы [ 2 ]

7 голосов
/ 08 мая 2011
  1. Создание токена на сервере.
  2. Поместите этот токен в скрытый элемент ввода.
  3. Сохраните этот токен на сервере в списке сгенерированных форм.
  4. Когда приходит форма
    1. проверить, был ли токен передан и действителен,
    2. удалить токен из списка созданных форм.

Я подозреваю, что именно для этого <input id="fkey" type="hidden" value="..." name="fkey"> в форме представления вопроса.

2 голосов
/ 08 мая 2011

хорошая идея, но это также оказывает давление на БД: (

Вы можете создать токен anti-XSRF без необходимости запоминать их все на сервере.

Вы можете сделать это, поместив информацию, которую вы хотите проверить, в токен, как правило, включая:

  • идентификатор пользователя, поэтому один пользователь не может создать форму для другого пользователя
  • метка времени истечения, чтобы токены не длились вечно

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

Так, например, для ID пользователя 18936 с отметкой времени истечения 1304861680 (время Unix примерно сейчас) вы можете создать токен, подобный:

18936.1304861680.2A956E39.11E859E44B9308B812257BEE660330D9D0566189

, где 2A956E39 - некоторая случайная соль, а бит в конце - это шестнадцатеричный код HMAC-SHA1 хэш 18936.1304861680.2A956E39 с использованием не очень хорошего секретного ключа secretkey.

Это достигает цели анти-XSRF, но иногда также используется одноразовый серверный сохраненный токен, чтобы предотвратить двойное представление формы. Как есть, метод хеширования не помогает с этим битом. Но в конкретном случае создания нового объекта, который представляет собой обычное место для развертывания предотвращения двойного представления, вы можете использовать токен как уникальное значение, вставленное в БД как часть нового объекта, а затем отказаться от создания новая сущность, если она уже есть с токеном.

...