Как защитить публичную часть службы REST от спама?

Question

У меня есть достаточно REST-сервис, который будет использоваться с приложением для iOS.Он построен с использованием Ruby / Sinatra, но я не думаю, что это действительно имеет значение.

Я использую базовую аутентификацию HTTP через SSL для различных конечных точек, и эта часть работает очень хорошо.

Вопросявляется: Как я могу остановить спаммеров и т. д. от вызова частей службы REST, которые не защищены с помощью базовой HTTP-аутентификации?

Пример: Регистрация пользователя

Давайте предположим, чтоREST-вызов (POST) ... / register_account передача объекта JSON в теле.

По понятным причинам этот вызов не может ожидать, что имя пользователя / пароль связанык учетной записи пользователя.

Идеи таковы:

1) Приложение имеет свое собственное имя пользователя / пароль, и некоторые вызовы проверяют учетные данные приложения.Проблема: при рутировании устройства и т. Д. Эти учетные данные могут быть обнаружены.

2) Приложение передает секретный токен через заголовок HTTP службе REST для этих вызовов.Проблема: То же, что (1)

Существуют ли какие-либо методы, которые обычно используются для предотвращения таких спам-вызовов?Я думаю, может быть, ввести идентификатор устройства iPhone в микс, но еще не определили определенный подход.

Спасибо

Answer 1

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

Answer 2

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

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

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

Если кто-то / что-то кроме вашего приложения пытается подключитьсяк вашему серверу соединение SSL не будет создано, так как сервер будет отклонять входящие соединения SSL, которые не предоставляют сертификат клиента, который вы включили в свое приложение.

Answer 3

Вы могли бы отслеживать IP-адреса, используя request.ip, и написать некоторую логику вокруг этого.