Как предотвратить использование ПОЛЬЗОВАТЕЛЕМ автоматических сообщений / спама?
Вот мой способ сделать это, новый php-сеанс для каждого запроса страницы, который имеет свои собственные ограничения, без многозадачности.
Я использовал новую сессию для каждой страницы в качестве защиты от CSRF и автоматических атак. Допустим, у нас есть форум, который использует AJAX для публикации тем и его проверки с помощью PHP SESSION.
add_answer.php? ID = 123
<?php if(!is_ajax()){// function that determines whether the request is from ajax (http header stuff) $_SESSION['token'] = md5(rand()); } //some ajax request to ajax.php?id=123 ?> ajax.php? ID = 123
<?php if($_SESSION['token'] == $_GET['token']){ echo 'MYSQL INSERT stuff'; }else{ echo 'Invalid Request'; } ?>
Все работает нормально, пока пользователь не откроет page.php? Id = 456 на другой вкладке, ajax возвращает «неверный запрос» на ajax.php? Id = 123 Это связано с другим вопросом, который я задал . Они предлагали использовать только один сеанс хэша все время, пока он / она не выйдет из системы – только после этого сеанс будет восстановлен. Если токен – это тот же ПОЛЬЗОВАТЕЛЬ, он может просто обойти его и выполнить автоматические атаки. Есть идеи по этому поводу?
Во всяком случае, какой способ предотвратить автоматические атаки AJAX?
PS:
Похоже, что вы возражаете против того, чтобы сеанс оставался открытым до тех пор, пока браузер открыт, это проблема автоматических атак. К сожалению, обновление токена на каждой загрузке страницы только уменьшает количество любительских злоумышленников.
Во-первых, я предполагаю, что мы говорим об атаках, специально предназначенных для вашего сайта. (Если мы говорим о ботах, которые просто бродят вокруг и представляют различные формы, это не только не остановит их, но есть намного лучшие и более простые способы сделать это.) Если это так, и я нацелился на мои сайт, вот что сделает мой бот:
(Или, если бы я достаточно исследовал вашу систему, я бы понял, что если бы я включил заголовок «это AJAX» для каждого запроса, я мог бы сохранить один токен навсегда. Или я понял бы, что токен – это мой идентификатор сеанса и отправьте мой собственный PHPSESSID cookie PHPSESSID .)
Этот способ изменения токена при каждой загрузке страницы не должен был бы абсолютно ничего, чтобы остановить кого-то, кто действительно хотел на вас напасть. Поэтому, поскольку токен не влияет на автоматизацию, сосредоточьтесь на его влиянии на CSRF.
С точки зрения блокировки CSRF, создавая один токен и поддерживая его до тех пор, пока пользователь не закрывает браузер, похоже, не достигнет всех целей. Простые атаки CSRF побеждены, и пользователь может открыть несколько вкладок.
TL; DR: обновление токена по каждому запросу не повышает безопасность. Пойдите для удобства использования и сделайте один токен за сеанс.
Однако! Если вас очень беспокоят дублирующие формы, случайные или другие, эта проблема все же может быть легко решена. Ответ прост: используйте два токена для двух разных заданий.
Первый токен останется неизменным до окончания сеанса браузера. Этот токен существует для предотвращения атак CSRF. Любая подача этого пользователя с этим токеном будет принята.
Второй токен будет уникально сгенерирован для каждой загруженной формы и будет сохранен в списке в пользовательских данных сеанса токенов открытой формы. Этот токен является уникальным и недействителен после его использования. Представления этого пользователя с этим токеном будут приниматься один раз и только один раз.
Таким образом, если я открою вкладку Form A и вкладку Form B, у каждого из них будет мой личный токен анти-CSRF (CSRF позаботился) и мой одноразовый токен формы (позаботьтесь о повторной отправке формы). Обе проблемы решены без какого-либо негативного влияния на пользовательский интерфейс.
Конечно, вы можете решить, что это слишком много для реализации такой простой функции. В любом случае, я думаю. Независимо от того, твердое решение существует, если вы этого хотите.
Если вы пытаетесь предотвратить наличие одного клиента DoS, необычная, но работоспособная стратегия заключалась бы в том, чтобы включить в запрос токен hashcash (уже есть реализации PHP и JavaScript ).
Чтобы предотвратить нарушение просмотра вкладок и обратную связь, в идеале вам нужно, чтобы задача токена хэш-кавы содержала как токен анти-подделки за сеанс, так и часть уникальности, созданную для каждого запроса. Чтобы свести к минимуму влияние на удобство использования, если у вас большая стоимость токена, начните предварительную вычисление следующего токена на своей странице, как только вы потратите предыдущий.
Это ограничивает скорость, с которой клиент может выдавать действительные запросы, потому что каждый токен хэш-каротажа может использоваться только один раз (это означает, что вам нужно будет хранить кэш действительных, уже потраченных токенов хэш-кэша, прикрепленных к сеансу, чтобы предотвратить бесконечное повторное использование одного токена), они не могут быть вычислены до начала сеанса (из-за случайного значения анти-подделки), и это требует нетривиальных сумм процессорного времени для генерации каждого нового действительного токена, но только тривиальное количество времени для подтверждения.
Хотя это не предотвращает автоматизацию вашего API AJAX как такового , он сдерживает высокопроизводительный удар по API.
Как предотвратить использование ПОЛЬЗОВАТЕЛЕМ автоматических сообщений / спама?
Вероятно, это можно решить так же, как и обычные запросы. Загрузка токена на страницу и остановка новых вкладок могут быть чрезмерными. Разумеется, чувствительный к времени токен на форму может в некоторой степени смягчить атаки CSRF. Но в противном случае, вместо ограничения пользовательского опыта, может быть лучше всего определить и реализовать механизм политики отправки.
Рискуя чувствовать себя помпезно или унизительно для всех: часто сайты используют систему вознаграждений на основе очков, такую как «карма» или «значки». Такие системы на самом деле добавляют к пользовательскому опыту, так как представления затем становятся своего рода игрой для пользователей. Они могут часто ограничивать возможность отправки материалов только доверенным пользователям или максимальным числом в течение заданного временного интервала. Взгляните на систему SO для хорошего использования.
Очень простой ответ просто демонстрирует некоторые общие правила сайта:
Более того, количество нарушений правил может быть сохранено для каждого пользователя, и если оно превышает определенный момент за определенный период времени, вы можете выбрать, чтобы они автоматически запрещались в течение определенного периода времени. Запрет может быть введен в действие, если вы хотите удалить все записи db, связанные с этим пользователем.
В примечании о «заголовке HTTP» заголовки предназначены только для того, чтобы отработать наилучшее предположение и любезность в отношении того, что запрашивает клиент. Их так же сложно подделать, как куки, а куки-куки всего лишь щелкнуть мышью. И, честно говоря, у меня лично не было бы этого иначе.