Как предотвратить автоматические AJAX-атаки

Question

Как запретить пользователю USER делать автоматические сообщения / спам?

Вот мой способ сделать это, новый сеанс 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:

1. Не мучайте пользователей капчами.
2. Google не смог показать мне что-то полезное по этому поводу.
3. Примите это как вызов.
4. Или хотя бы проголосуйте за ответы экспертов, которые вы считаете блестящим способомделать это

Answer 1

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

Во-первых, я предполагаю, что речь идет об атаках, специально направленных на ваш сайт. (Если мы говорим о ботах, которые просто бродят и отправляют различные формы, это не только не остановит их, но и есть гораздо лучшие и более простые способы сделать это.) Если это так, и я нацеливаюсь на своих сайт, вот что мой бот будет делать:

1. Загрузить страницу формы.
2. Прочитать токен на странице формы.
3. Отправить автоматический запрос с этим токеном.
4. Перейти к шагу 1.

(Или, если бы я достаточно исследовал вашу систему, я бы понял, что если бы я включал заголовок «это AJAX» в каждый запрос, я мог бы сохранить один токен навсегда. Или я бы понял, что токен - это мой сеанс ID и отправьте мой собственный PHPSESSID cookie.)

Этот метод изменения токена при каждой загрузке страницы абсолютно ничего не сделает, чтобы остановить человека, который на самом деле хотел напасть на вас так сильно. Поэтому, поскольку токен не влияет на автоматизацию, сконцентрируйтесь на его влиянии на CSRF.

С точки зрения блокировки CSRF создание одного токена и его поддержка до тех пор, пока пользователь не закроет браузер, кажется, выполняет все задачи. Простые CSRF-атаки побеждены, и пользователь может открывать несколько вкладок.

TL; DR: обновление токена один раз при каждом запросе не повышает безопасность. Выберите удобство использования и сделайте один токен за сеанс.

---

Однако! Если вы крайне обеспокоены дублированием форм, случайным или иным образом, эту проблему все еще можно легко решить. Ответ прост: используйте два токена для двух разных заданий.

Первый токен останется прежним до конца сеанса браузера. Этот токен существует для предотвращения CSRF-атак. Любая заявка от этого пользователя с этим токеном будет принята.

Второй токен будет сгенерирован уникально для каждой загруженной формы и будет сохранен в списке в данных сеанса пользователя токенов открытой формы. Этот токен является уникальным и становится недействительным после его использования. Материалы от этого пользователя с этим токеном будут приниматься один раз и только один раз.

Таким образом, если я открою вкладку для формы A и вкладку для формы B, у каждого из них будет свой личный токен анти-CSRF (забота о CSRF) и мой одноразовый токен формы (повторная передача формы позаботится о ). Обе проблемы решаются без какого-либо вреда для пользователя.

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

Answer 2

Как запретить пользователю USER делать автоматические сообщения / спам?

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

Риск звучать помпезно или унизительно для всех: часто сайты используют систему вознаграждений, основанную на баллах, например, "карма" или "значки". Такие системы на самом деле добавляют к пользовательскому опыту, поскольку представления становятся своего рода игрой для пользователей. Они часто могут ограничивать возможность публикации сообщений только доверенным пользователям или максимальным числом в течение заданного периода времени. Взгляните на систему SO для хорошего варианта использования.

Очень простой ответ, демонстрирующий некоторые общие правила сайта:

• Если пользователь превысил число сообщений x за последние y минут, запретите вставку в БД и отобразите предупреждение «Извините, слишком рано после вашего последнего сообщения». Это может быть достигнуто путем запроса к базе данных количества сообщений пользователей за данный последний период времени, прежде чем разрешить вставку новой записи.
• Если у пользователя нет определенного порога кармы - например, новых пользователей или тех, кто неоднократно помечается как спамер, - отрицают запись в БД и отображают «Извините, вы не были здесь достаточно долго» или «Извините Вы слишком много спама "предупреждение. Это может быть достигнуто путем запроса к БД всей пользовательской «кармы», которая управляется в отдельной таблице или модуле сайта, прежде чем разрешить вставку новой записи.
• Если сайт небольшой и достаточно управляемый, чтобы его модерировать только один или два пользователя, сначала рассмотрите и одобрите все запросы и сообщения новых пользователей. Это может быть достигнуто путем хранения новых записей в отдельной таблице для просмотра перед переходом к активной таблице или с помощью столбца «утвержденных» флагов на главной таблице.

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

В примечании о "заголовке http" заголовки предназначены только для того, чтобы отработать правильное предположение и вежливость в отношении того, что запрашивает клиент. Подделать их так же сложно, как и cookie-файлы, а подделать cookie-файлы можно одним щелчком мыши. И, честно говоря, лично у меня не было бы этого иначе.

Answer 3

Если вы пытаетесь не допустить, чтобы один клиент делал DoS, необычной, но работоспособной стратегией было бы включение в запрос hashcash токена (уже есть PHP и JavaScript реализации).

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

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

Хотя это не мешает автоматизации вашего AJAX API per se , оно ограничивает массовое использование API.