#spam-prevention #bots #timestamp-analysis
#предотвращение спама #боты #анализ временных меток
Вопрос:
В этой статье о том, насколько отстойна CAPTCHA, упоминается, что Animoto использовала анализ временных меток для сокращения спама.
В нем содержится ссылка на руководство по jQuery по анализу временных меток. По сути, вы используете AJAX, чтобы заставить PHP установить cookie, используете JS для добавления скрытого ввода в форму, а затем (при отправке) сравниваете значение скрытого ввода со значением cookie. Из руководства:
Проверка формы
test.php используется ли пример PHP-кода для проверки токена
- Присутствует ли токен [скрытое входное значение]?
- Соответствует ли он временной метке при запуске через функцию md5 ()?
- Прошло слишком много времени?
…Но мне это показалось действительно запутанным по следующим причинам:
- Присутствует ли токен?Токен добавляется только с помощью JavaScript, поэтому все, что вы на самом деле делаете, это определяете, включен JS или нет. Конечно, есть более простые способы сделать это.
- Совпадает ли он с временной меткой при запуске через функцию md5 ()?md5 может заставить нас чувствовать себя лучше, но разве это не просто проверка того, что cookies включены? Конечно, есть более простые способы сделать это.
- Прошло слишком много времени?Действительно ли спам-ботам требуется много времени для отправки форм? Конечно, в этом нет необходимости. (Разве вы на самом деле не хотели бы посмотреть, была ли форма отправлена слишком рано?)
Я надеюсь, что на самом деле я понятия не имею, как и почему боты взаимодействуют с HTML-формами, и что теперь меня можно исправить и обучить.
Ответ №1:
- Присутствует ли токен?Да, вы в значительной степени видите, включен ли JavaScript в клиенте. Но суть в том, что многие фреймворки веб-автоматизации не поддерживают JavaScript (или поддерживают только некоторое ограниченное его подмножество), а те, которые имеют надлежащую поддержку JavaScript, как правило, довольно тяжеловесны и, следовательно, не подходят для использования в качестве спам-бота. Таким образом, по сути, вы отфильтровываете простых спам-ботов, которые полагаются на отправку формы по URL-адресу, фактически ничего не оценивая на странице, содержащей форму.
Следующие два пункта, похоже, больше защищают от кэширования спам-ботом и повторного использования формы отправки, чем от того, что отправка данной формы занимает слишком много времени после загрузки с сервера страницы, содержащей ее. Как вы говорите, можно было бы ожидать, что спам-бот будет быстрее реального пользователя отправлять форму при условии, что спам-бот следует потоку запроса формы с вашего сервера, а затем отправляет ответ обратно. Но не все спам-боты будут следовать этому потоку. Некоторые могут кэшировать страницу, которую отправляет ваш сервер (или ответ, который был сгенерирован для этой страницы), для повторного использования снова и снова. Если они это сделали, то временные метки / cookies дают вам способ обнаружить это.
Но я действительно думаю, что временные метки не нужны. Я бы придерживался только токена JavaScript, используя подход, примерно подобный:
- Каждый раз, когда запрашивается страница / форма, сервер генерирует новый случайный токен для этого запроса.
- Токен связан с текущей HTTP-сессией пользователя.
- Токен (или его слегка зашифрованная версия) также отправляется на страницу.
- JavaScript добавляет значение токена в качестве скрытого ввода в форму (при необходимости сначала расшифровывая его).
- При отправке сервер проверяет, существует ли а) токен в HTTP-сеансе пользователя, б) токен был отправлен вместе с формой, и в) совпадают ли оба токена.
- Предполагая, что отправка была действительной, сервер удаляет токен из HTTP-сеанса пользователя, чтобы его нельзя было использовать повторно.
Таким образом, вся явная бессмыслица с временными метками исчезает, потому что это встроено в HTTP-сессию. Срок действия очень старых сеансов истечет, забирая с собой их токены. Вы по-прежнему отфильтровываете любых спам-ботов, которые недостаточно сложны для поддержки JavaScript или cookies, и вы отказываетесь от использования кэшированных URL-адресов / отправлений формы, потому что шаг 6 гарантирует, что ни один токен не может быть использован более одного раза. По сути, спам-бот вынужден пройти весь цикл запроса страницы с вашего сервера, выполнения JavaScript и отправки формы для каждой отправки, которую он хочет сделать.