Защита не аутентифицированного REST API

Я читал о защите API REST и читал о oAuth и JWT. Оба являются действительно отличными подходами, но из того, что я понял, они оба работают после аутентификации пользователя или, другими словами, "вошли в систему". Это основано на учетных данных пользователя oAuth и JWTs генерируются, и после того, как токен oAuth или JWT будет получен, пользователь может выполнить все действия, на которые он разрешен.

Но мой вопрос: а как насчет входа и регистрации apis? Как защитить их? Если кто-то читает мои javascript файлы, чтобы увидеть мои вызовы ajax, они могут легко узнать конечные точки и переданные параметры, и они могут ударить его несколько раз через некоторый клиент REST, более строго они могут закодировать программу, которая попадает на мою подпись api скажем, тысячу раз, что создало бы тысячи пользователей спама, или они могли бы даже грубо заставить login api. Так как же они защищают их?

Я пишу свой API в yii2.

Ответ 1

Структура Yii 2.0 имеет встроенный фильтр, называемый yii\filters\RateLimiter, который реализует алгоритм ограничения скорости, основанный на негерметичный алгоритм ведра. Это позволит вам ограничить максимальное количество принятых запросов за определенный промежуток времени. В качестве примера вы можете ограничить как конечные точки входа и регистрации, так и принимать не более 100 вызовов API в течение 10 минут. Когда этот предел превышен, будет выбрано исключение yii\web\TooManyRequestsHttpException (429).

Подробнее об этом можно узнать в API-интерфейсе Yii2 RESTful или в рамках SO размещать.

Я не использовал его сам до сих пор, но из того, что я читал об этом в официальных документах, и я имею в виду это:

Обратите внимание, что RateLimiter требует $userдля реализации yii\filters\RateLimitInterface. RateLimiter ничего не сделает, если $userне задано или не выполняется yii\filters\RateLimitInterface.

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

Быстрый поиск в Google позволяет мне использовать это расширение: yii2-ip-ratelimiter, к которому вы также можете обратиться.

Ответ 2

Ваши URL-адреса будут легко определены. У вас должен быть черный список IP-адресов, и когда IP-адрес действует подозрительно, просто добавьте его в черный список. Вы определяете, что такое подозрительное, но если вы не уверены, вы можете начать со следующего:

Создайте что-то вроде таблицы базы данных с этой схемой:

ip_addresses (ip, is_suspicious, login_attempts, register_attempts)

Где is_suspicious означает, что он включен в черный список. login_attemtps и register_attempts должны быть json-значениями, отображающими историю этого ip-адреса, пытающегося войти в систему/зарегистрироваться. Если последние 20 попыток были безуспешными и были в течение минуты, тогда ip-адрес должен быть внесен в черный список. Черные списки IP-адресов должны получать ответ, что они занесены в черный список независимо от их запроса. Поэтому, если они отказываются от ваших услуг или пытаются взломать вещи, вы отказываетесь от своих услуг от них.

Защищенные пароли, например, с помощью sha1. Этот алгоритм достаточно безопасен и, например, быстрее, чем sha256, что может быть чрезмерным. Если ваш API включает банковские счета или что-то чрезвычайно важное, важно, чтобы плохие парни использовали серверные парки, чтобы взломать его, а затем заставили пользователей создавать очень длинные пароли, включая числа, специальные символы, большие и маленькие буквы.

Ответ 3

Для javascript вы должны использовать OAuth 2.0 Implicit Grant flow, например Google или Facebook.
Вход и регистрация используют 2 основные веб-страницы. Не забудьте добавить к ним капчу.

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

Простым решением вы можете обратиться:

используйте алгоритм шифрования, такой как AES или 3DES для шифрования пароля от клиента используют секретный ключ (об этом знают только клиент и сервер)
используйте хэш-алгоритм, такой как sha256 для хэша (имя пользователя + время клиента + другое Секретный ключ). Клиент отправит как клиентское время, так и строку хеша сервер. Сервер отклонит запрос, если время клиента слишком отличается из строки сервера или хэша неверно.

Например:

api/login?user=user1&password=AES('password',$secret_key1)&time=1449570208&hash=sha256('user1'+'|'+'1449570208'+'|'+$secret_key2)

Примечание: в любом случае сервер должен использовать captcha, чтобы избежать атаки грубой силы, не верьте ни в какой другой фильтр

О captcha для REST API, мы можем создать базу captcha на токене.
Например.

Для действия регистрации: вы должны вызвать 2 api

/getSignupToken: чтобы получить URL-адрес изображения captcha и токен регистрации соответственно.
/signup: отправить данные регистрации (включить токен регистрации и captcha, набранный пользователем)

Для действия входа: мы можем потребовать, чтобы captcha с помощью счетчика неудачных логинов основывался на имени пользователя

Ответ 4

Добавьте сюда мой модуль api для справки. Я управляю аутентификацией пользователя маркером доступа. При входе в систему я генерирую токен, затем снова обращаюсь к клиенту, а клиент должен отправить токен, а сервер будет проверять.

Yii2 Starter Kit lite