Что такое rate limiting

Rate limiting — это ограничение числа запросов за промежуток времени. RFC 6585 (апрель 2012) вводит для этого код 429 Too Many Requests: пользователь послал слишком много запросов за данный промежуток. Ответ может содержать Retry-After. К скликиванию код сам по себе не относится: он про частоту запросов к серверу, не про интерес к объявлению.

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

Код не говорит, кого вы посчитали

Спецификация не определяет, как сервер узнаёт пользователя и как считает запросы: по одному ресурсу, по всему серверу или по группе серверов, по учётным данным или по cookie. Два кабинета могут отвечать 429 на разное. Один считает IP, другой — сессию, третий — логин. Клиент видит один и тот же код.

Фраза «50 запросов в час» в документе — пример тела ответа, не норма. Свой порог из этого примера не берут.

В соображениях безопасности сказано: под ударом или при очень большом потоке ответ 429 сам тратит ресурсы. Сервер не обязан его слать и может просто рвать соединения. Отсутствие 429 в логе не доказывает, что лимита нет. Соединение могли оборвать раньше ответа.

Капча, IP и вычислительная задача — не тот же приём

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

Блокировка IP останавливает простой перебор и не должна быть единственной защитой. Адрес легко сменить. Распределённый заход через прокси держит низкую частоту с одного адреса — как раз так, что лимит «на IP» молчит, а учётка получает много попыток.

Клиентские проверки, включая JavaScript, можно подделать, поэтому OWASP требует второй слой. Вычислительная задача в том же разделе — криптографическая или proof-of-work: клиенту дают работу, чтобы растянуть время атаки. Человек в цикле не нужен. Приём ограничивает частоту конкретной реализации клиента. Запрет визитов без JavaScript ухудшает доступность, в том числе для скринридеров. Это описание защиты входа, не параметры задачи Binetro.

Статья Адама Бэка от 1 августа 2002 года описывает hashcash как способ притормозить систематическое злоупотребление ресурсами без учёта, исходно почтой и анонимными ремейлерами. Первое предложение автор относит к маю 1997 года. Функция стоимости считает токен-доказательство работы. Его дёшево проверить и настраиваемо дорого вычислить. В интерактивном варианте сервер выдаёт задание клиенту. От капчи приём отделён: человека в цикле нет, цену задаёт объём вычисления. Формула сборки и число нулевых битов сюда не входят. Статья не задаёт сложность для веб-визита.

Одной частоты мало, чтобы не пустить

Binetro считает ложное решение против живого человека хуже пропущенного бота. Одного слабого сигнала, в том числе одной только частоты запросов, недостаточно, чтобы не пустить посетителя. Насколько слабым должен быть сигнал, в это правило не входит. Практический вывод уже есть: 429 или всплеск запросов записывают и смотрят вместе с другими признаками. Сам по себе всплеск — не бан.

Прочитайте один ответ 429 как карточку, а не как приговор. Время в Retry-After, если оно есть, говорит, когда клиенту предлагают повторить запрос. Оно не говорит, посчитали ли вы IP, cookie или логин. Два одинаковых кода за один час могут относиться к разным ресурсам: счёт идёт по одному адресу, по всему серверу или по группе серверов, по учётным данным или по cookie. График «сколько 429 за день» без подписи, что именно считали, между кабинетами не сравнивают.

Рядом держите предел капчи и предел адреса. Капча на входе замедляет автоматизацию и не закрывает её: тест решают с заметно высокой долей успеха. Адрес, который вы заблокировали, легко сменяют. Через прокси частота с одного адреса остаётся низкой, и лимит на IP молчит, пока учётка получает попытки. JavaScript в браузере подделывают, поэтому второй слой обязателен. Вычислительная задача растягивает время атаки без человека в цикле и ограничивает конкретную реализацию клиента. Запрет визитов без JavaScript бьёт по доступности, в том числе по скринридерам. Hashcash играет ту же роль: токен дёшево проверить и настраиваемо дорого собрать, цену задаёт объём вычисления, человека в цикле нет. Это не порог Binetro. Фраза «50 запросов в час» в RFC — пример тела ответа, не норма.

Соберите для входа три колонки и не сводите их в одну цифру. Первая — сколько 429 ушло клиенту и был ли обрыв соединения без кода: при очень большом потоке сервер вправе не тратить ресурсы на ответ. Вторая — есть ли второй слой кроме IP и кроме скрипта в браузере. Третья — не пускаете ли вы человека по одной частоте. Третью колонку Binetro закрывает правилом: одной частоты мало. Рекламный клик в эти колонки не входит.

Ручной предел: вы можете поставить порог на логин или на адрес и увидеть 429. Вы не увидите распределённый заход, который с каждого адреса остаётся ниже порога. Второй слой — тот, который OWASP требует рядом с клиентской проверкой: не только JavaScript в браузере и не только список IP. Binetro как раз не пускает по одной частоте. Деньги за клик он не возвращает: их списывает рекламная система. Кто скликивает, чем кликфрод отличается от скликивания, когда недействительный клик не списывают и вернётся ли бюджет — вопросы кабинета рекламы, не кода 429.