Как защитить REST API от невалидных запросов?

Question

[Иван Воробей]

Имею:

• Rest API на Lumen
  
• Соединение по httpS
  
• Basic авторизацию: Отправляется в хедаре login+password, в ответ приходит JWT c acsess_token (для каждого запроса с малым временем жизни) и refresh_token (для получения нового acsess_token)
  

Необходимо:
Реализовать архитектуру валидации запроса. Т.е. чтобы знать что запрос пришел именно от "своего" клиента (под клиентом я подразумеваю мобильное приложение). Чтобы ручками в браузере школьники не могли посылать запросы) Получается запрос от клиента должен быть идетицифирован по двум пунктам:

1. Запрос пришел от валидного клиента
   
2. Запрос пришел от валидного пользователя
   

Можно было...:
Идея была сделать два заголовка в хедаре, и передавать в них два токена: один выдан клиенту, второй выдан пользователю. Но два нельзя, а в url передавать - костыль.
UPD: Можно и два заголовка, распарсить их не проблема. Но нормальное ли это решение?


Итог:
Как сделать без костылей валидацию клиента?

Comments

[Станислав Макаров]

> Т.е. чтобы знать что запрос пришел именно от "своего" клиента (под клиентом я подразумеваю мобильное приложение).
Это не очень хорошая идея в принципе. Почему такая потребность возникла? Какова изначальная задача?

[Иван Воробей]

Станислав Макаров: почему не очень хорошая? Цель тривиальна: чтобы кто-угодно не мог посылать запросы, только "свои" клиенты.

[Станислав Макаров]

Иван Воробей Потому что надежное ограничение круга используемых клиентов задача довольно непростая, и редко оправдывается с точки зрения затрат. Возможно, у вас в клиенте реклама, и вы хотите чтобы её смотрели, тогда конечно в этом есть некоторый смысл. Если же вы это делаете ради безопасности, то это плохой путь к ней.

Попробуйте поработать с клиентскими сертификатами. Посмотрите, поддерживает ли http-клиент в вашем стеке технологий использование клиентского сертификата в TLS соединении. И вшейте потом приватный ключ в приложение, чтобы его сложнее было найти. Имхо, это единственный более-менее надежный вариант, т.к. все остальные велосипеды будут подвержены сниффингу и риплей атакам.

Answer 1

[xfg]

Все что выполняется на стороне клиента, можно разобрать и вытащить секретную информацию. Поэтому любое приложение работающее на стороне клиента по определению является небезопасным и авторизовывать его нет смысла. Это можно будет подделать.

То, что вы хотите можно сделать только с клиентами работающими на стороне сервера.

Я думаю, что вам стоит еще раз переосмыслить свою задачу. Возможно стоит описать ситуацию подробнее, почему вы пытаетесь совместить несовместимое, с одной стороны закрытый API и с другой публичное мобильное приложение.

Это так не работает. Нужно выбирать из двух:
1. Публичный API -> Публичный клиент (выполняется на клиенте).
2. Закрытй API -> Закрытый клиент (выполняется на сервере).

Comments

[Иван Воробей]

Казалось что в этом есть необходимость. Получается, что даже если я хочу работать только со "своими" клиентами - подписывать запрос не имеет смысла. Хотя изнутри что-то гложит)

Спасибо за ответ, это решение одназначно.

Дополнительный вопрос: если я захочу в один момент отключить запросы от приложения, как это лучше организовать? К примеру есть клиенты на android и ios, появилась необходимость отключить приложение на ios.

[Станислав Макаров]

Иван Воробей ну вот вам человек то же самое объяснил, только более доходчиво) И я с ним согласен.

[Иван Воробей]

Станислав Макаров: спасибо! Пометил бы и ваше решением, если бы была возможность. Спасибо за помощь.

Возможно знаете ответ на вопрос чуть выше?

[Станислав Макаров]

Иван Воробей
> К примеру есть клиенты на android и ios, появилась необходимость отключить приложение на ios.
Надежно - никак, по тем же причинам, что мы уже обсудили - все может будет подделать. Чел может сесть, собрать траффик, и отправить запросы вообще с ПК, и выдать себя за кого угодно.

Ненадежно - посылайте сами нужные заголовки из обоих приложений, User-Agent как раз для этого. Тогда вы сможете смотреть этот хедер и не обслуживать того, кого не хотите (т.е. сделать whitelist, а всех, кто не попадает в него - посылать), это будет работать для тех юзеров, кто не готов заморачиваться и что-то перехватывать.

И все-таки, хороший REST-сервис - тот, для которого клиент - ведь абстрактная. По сути, клиентское приложение - лишь инструмент упрощения жизни юзеру. С помощью клиентского приложения вы как бы избавляете человека от необходимости генерить HTTP-запросы вручную, не более того. Если нужно как-то ограничивать доступные ресурсы на сервисе - авторизуйте конкретного пользователя, плюс используйте rate limits, если нужно.

[xfg]

Иван Воробей: я верно понял, вам нужно уметь банить определенные клиенты? Если так, то едва ли что-то можно сделать. Вы же уже поняли, что любое приложение на клиентской стороне может прикинуться кем угодно. Вы запрещаете ios приложение, а завтра оно прикидывается, что оно android приложение. И работает, как и до.

[Иван Воробей]

xfg: банить - нет. Я уже понял что это бесмвсленно.

Цель такая: скажем я выпустил новый клиент на ios, а старый хочу не обрабатывать. Просто делаю неактивным клиентское приложение у себя на сервере, и ответы от него не приходят.

Вопрос не в безопасности, а в удобстве. Обычный пользователь откроет приложение и увидит мол "клиент больше не активен, удаляй". Утрирую, но идея должна быть понятна

[Иван Воробей]

Станислав Макаров: этот заголовок подходит для случая, когда у меня несколько клиентов на ios?

Выглядит как то что нужно. Вопрос не в безопасности, а в индетификации клиента

[xfg]

Иван Воробей: понял. В таком случае, я бы из клиента отправлял запрос с доп. заголовком с информацией о клиенте: X-Client: iOS v1.0.0
Сервер этот заголовок читает и если он ему не нравится, то отправляет что-нибудь клиенту в ответ.

[Иван Воробей]

xfg: спасибо! Со слезами на глазах благодарю!

[Станислав Макаров]

Иван Воробей у юзер-агента достаточно сложная структура, как минимум вы сможете указать название приложения и его версию. См. tools.ietf.org/html/rfc7231#section-5.5.3

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

[Иван Воробей]

Станислав Макаров: огромное спасибо! Не первый раз радуете отличными ответами.

Answer 2

[Airat1995]

Возможно использовать IMEI телефона для того, чтобы проверять телефон ли это. Вот здесь есть база IMEI'ов и API к нему www.imei.info/api/imei/docs Однако существуют программы для замены IMEI, а также для его генерации.

Comments

[Иван Воробей]

Слишком специфичное решение. Мне нужно сделать для любого типа клиента, просто валидация запроса.

[Airat1995]

Иван Воробей: простите просто в вопросе я прочитал что вы подразумеваете мобильное приложение.