Остановка бота [SO] - PHP

Я сохранил этот код в 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>

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

Author: ಠ_ಠ, 2011-05-08
Source

2 answers

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

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

 7
Author: Oswald, 2011-05-08 13:22:48

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

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

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

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

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

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

18936.1304861680.2A956E39.11E859E44B9308B812257BEE660330D9D0566189

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

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

 2
Author: bobince, 2011-05-08 13:42:26