Как запретить злоумышленнику использовать токен из localStorage для вызова REST API

Это более концептуальный вопрос. Когда мы используем SPA, например Angular, мы использовали неявный поток для аутентификации. В этом потоке мы сохраняем токен либо в localStorage, либо в sessionStorage.

Когда нам нужно вызвать какой-либо API, мы передавали этот токен доступа этому API, чтобы получить данные или отправить данные POST.

У меня есть вопрос. Что если какой-либо злонамеренный пользователь нашел этот токен, то он может сделать тысячи вызовов POST API с некоторыми мусорными данными, используя postman или любой другой клиент.

Как нам избежать такой ситуации?
Заранее спасибо!!!!

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

Но я читал, что заголовок ORIGIN также небезопасен. Злоумышленник может легко установить его через код, и он может вызывать API программно. Так что же делать с такими условиями?

Пожалуйста, смотрите это изображение ниже для более подробной информации -

Подробное описание постановки задачи


person sudarshan1933    schedule 04.11.2018    source источник
comment
Используйте https, часто обновляйте токен, реализуйте какой-то фильтр, который сделает токен недействительным, если будет слишком много запросов за интервал.   -  person maljukan    schedule 04.11.2018
comment
@maljukan - Спасибо, maljukan, за ответ. Мы уже реализовали регулирование в нашем REST API. Но что, если кто-то публикует какие-то мусорные данные с интервалом в 10 минут или около того???   -  person sudarshan1933    schedule 04.11.2018
comment
@sudarshan1933 ты стреляешь повсюду. то, что вы упоминаете в своем комментарии, не имеет ничего общего с вашим вопросом. это хост, который должен смягчить DDOS-атаки. у них есть свои инструменты. вы не должны и не можете иметь дело с DDOS на уровне приложения.   -  person Stavm    schedule 04.11.2018


Ответы (1)


Многие приложения SPA поддерживают токен JSON Web Token (JWT), обычно аутентификация пользователя происходит на сервере авторизации, который возвращает токен JWT. Используя токен JWT, внешнее приложение может отправлять данные как часть токена аутентификации заголовка.

Обычно токен будет храниться в сеансовом/локальном хранилище для поддержания сеанса с полным состоянием ч/б клиента и сервера.

Поскольку инфраструктура на стороне клиента не обеспечивает большей безопасности. Эта проверка токена должна обрабатываться в бэкэнде.

1) Включите CORS, чтобы доступ к API был разрешен только для определенного доменного имени (https://example.com). используя «Access_control_allow_origin».

2) Если злоумышленник украдет токен, он будет получать доступ через другой домен, который внутренний сервер может запретить на основе происхождения.

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

person Suresh Kumar Ariya    schedule 04.11.2018
comment
Большое спасибо @Суреш Кумар Ария - person sudarshan1933; 04.11.2018
comment
Но я читал, что заголовок ORIGIN также не является безопасным. Злоумышленник может легко установить его через код, и он может вызывать API программно. Итак, как бороться с такими условиями? - person sudarshan1933; 04.11.2018
comment
Когда мы вызываем какой-либо API для бэкэнда, будет 2 запроса, 1-й — это запрос параметров без ответа, который проверит, авторизован ли хост / источник. 2-й запрос — это правильный запрос с ответом API. Взломать это очень сложно. - person Suresh Kumar Ariya; 04.11.2018
comment
Если какой-либо злоумышленник попытается получить доступ к API, 1-й запрос (OPTION) завершится ошибкой, что заблокирует 2-й запрос. - person Suresh Kumar Ariya; 04.11.2018