предотвращение злоупотребления использованием сервиса API

Я планирую использовать Laravel в моем следующем веб-проекте, для backend, Используя встроенную функциональность Laravel, я создам API оказание услуг. Поэтому моя главная забота сейчас — это безопасность такого сервиса. Промежуточное программное обеспечение Laravel для API кажется простым в использовании, но оно не обладает той гибкостью, которая мне нужна. Или, по крайней мере, я не вижу, сможет ли он справиться с моим сценарием или нет.

Вот мои вопросы. Надеюсь, кто-то может ответить на них.

  1. Можно ли применить другую логику регулирования в зависимости от того, вошел ли пользователь в систему или нет? (выполнить 2-3 проверки дроссельной заслонки) Или выполнить несколько разных проверок дроссельной заслонки в рамках одного запроса.

  2. Где хранится история IP-адресов, которые вызывают API? Это в заголовках HTTP или в каком-то кеше / memcached / redis?

  3. Если я хочу заблокировать IP-адрес, а затем выполнить проверку, если он заблокирован — есть ли хорошее руководство о том, как хранить такую ​​информацию? Как интегрировать это с дросселированием? Примеры схем или что-нибудь? Совет был бы хорош 🙂

Вот краткий пример логики, которую я хочу реализовать в конце концов:

  • маршрут: GET: /api/invoice/1

правила:

if IP throttling is enabled
then I don't want to check whether user is logged in or not

if (user is unauthorized) {
throttle by IP.
Throttle after 10 attempts within 1 minute

if (number of times throttled within last 5 minutes = 0) {
Retry-After: 1 minute
}
else if (number of times throttled within last 10 minutes > 1) {
Retry-After: 10 minutes
}
else if (number of times throttled within last 30 minutes > 3) {
Retry-After: 3 hours
}
else if (number of times throttled within last 8 hours minutes > 6) {
ban IP for 1 week!!!
}
}
else (user is authorised) {
if (has permission: get_invoices) {
throttle by JWT token.
Throttle after 100 attempts within 1 minute

if (number of times throttled within last 5 minutes = 0) {
Retry-After: 5 minutes
}
else if (number of times throttled within last 30 minutes > 1) {
ban user!!!
}
}
else (user is logged in but doesn't have necessary permission
{
throttle by JWT token.

Throttle after 50 attempts within 1 minute

// apply logic different from user who has permission
}

}

для маршрута № 2, 3, 4 это может быть другая логика.

Поэтому я не могу использовать только одно промежуточное ПО, как в этом примере, потому что оно основано на одном параметре (будь то IP, WTD, домен или другой) и не включает в себя логику запрета

Route::group(['prefix' => 'api', 'middleware' => 'throttle:2,5'], function () {
Route::get('invoice/{id}', function () {
return $some invoice;
});
});

Я хотел бы получить некоторые отзывы по этому вопросу. Я планирую выйти на мировой уровень 🙂

0

Решение

Вот мой ответ на ваши вопросы:

  1. Можно ли применить другую логику регулирования в зависимости от того, вошел ли пользователь в систему или нет? (выполнить 2-3 проверки дроссельной заслонки) Или выполнить несколько разных проверок дроссельной заслонки в рамках одного запроса.

    Да, вы можете сделать пользовательское промежуточное ПО а потом вызовите промежуточное программное обеспечение дроссельной заслонки из своего специального промежуточного основываясь на желаемой логике

  2. Где хранится история IP-адресов, которые вызывают API? Это в заголовках HTTP или в каком-то кеше / memcached / redis?

    Laravel не регистрирует IP-адреса из коробки. Опять же, вы можете сделать специальное промежуточное программное обеспечение для этого. Чтобы получить IP-адрес, вы можете использовать $request->ip()

  3. Если я хочу заблокировать IP-адрес, а затем выполнить проверку, если он заблокирован — есть ли хорошее руководство о том, как хранить такую ​​информацию? Как интегрировать это с дросселированием? Примеры схем или что-нибудь? Совет был бы хорош 🙂

    Да, вы можете встроить эту логику в пользовательское промежуточное ПО, которое вы пишете для Q2. Для хранения / извлечения заблокированных IP-адресов вы можете использовать кеш или БД. Чтобы «интегрировать» с регулированием, вы можете просто использовать оба промежуточных программного обеспечения

0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]