API-интерфейс Mobile-to-Server

Question

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

По сути, мы разрешаем людям входить через OAuth через Facebook или Twitter. Мобильное приложение (созданное с помощью Appcelerator Titanium) тоже должно это делать. После успешного входа в систему по телефону мне нужно уведомить мое приложение о том, что кто-то вошел в систему с помощью FB или Twitter, чтобы мое приложение могло получить идентификатор пользователя для конкретного приложения пользователя.

Моей первой мыслью было написать API, к которому телефон мог бы обращаться, и в котором принимались бы такие параметры, как идентификатор пользователя Facebook или Twitter. Я бы запросил свою базу данных и нашел бы внутренний идентификатор пользователя и вернул его на телефон.

Это будет нормально работать, но совершенно небезопасно. Любой может поразить тот же API с помощью идентификатора пользователя Facebook, и API просто вернет внутренний идентификатор (и любые другие данные, необходимые приложению), не зная, авторизован ли запрос.

Это мое первое мобильное приложение, поэтому я немного не уверен в правильном способе обеспечения безопасности в моем API.

Answer 1

1. Если можете, используйте https, и множество проблем решено.
2. при успешном входе в систему вы можете создать сеанс и передать sessionid клиенту, здесь я советую вам отправить идентификатор сеанса с помощью RSA (в случае, если кто-то может перехватить ваш идентификатор сеанса)
3. используйте хэш-подпись, чтобы убедиться, что запрос не изменен в пути, но этот метод не может предотвратить проблему с репостом.

Наконец, для вашей проблемы, если есть новый прогресс, пожалуйста, дайте мне знать, спасибо!

Answer 2

Я тоже сталкивался с этой проблемой, аутентификация пользователя достаточно проста, но аутентификация устройства намного сложнее.Как вы сказали, любой может подключиться к вашему API и представить пользователя, прошедшего аутентификацию через Facebook, и получить доступ к вашему API.

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

В конце концов я заставил устройство зарегистрироваться в моем API при первой установке приложения.Устройство выполняет API-вызов на моем сервере, и ему выдается секретный ключ API, который он затем должен использовать для выполнения всех других API-вызовов.Это небезопасно, поскольку вы можете написать сценарий для регистрации и получить ключ API, но это позволяет мне отслеживать использование API и отключать устройства, которые ведут себя плохо.

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

Answer 3

У меня была та же проблема, и я решил ее, создав собственный API (PHP) в сочетании с прокси-сервером (NodeJS). Каждый запрос от моего клиента отправляется на прокси-сервер, прокси-сервер проверяет запрос и передает его моему API. API разрешает только запросы от прокси-сервера его IP.

Сначала пользователь проходит аутентификацию на прокси-сервере с помощью заголовка авторизации, в случае успеха пользователь получит 2 токена. Токен доступа и токен обновления. Маркер доступа используется для отправки запросов и живет в течение 5 минут в моем случае. Когда срок действия маркера доступа истек, пользователь может обновить токен с помощью маркера обновления, который существует вечно.

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

Если вы используете это с HTTPS, ключи не могут быть проанализированы, и вы не сможете получить ключи, если декомпилируете приложение, потому что они хранятся на устройстве пользователя, а не «жестко закодированы» в самом приложении. Технически, если у злоумышленника есть устройство пользователя, он может декомпилировать приложение и получить ключи. Я знаю это, но если у него уже есть доступ к физическому устройству, он все равно сможет использовать любое приложение.

Прокси-сервер также регистрирует каждый входящий запрос и уведомляет меня по электронной почте, когда кто-то пытается проделать трюки (я создал это сам). Я использовал следующие модули:

• Экспресс
• * 1014 протокол HTTPS *
• http-proxy (передает запрос на мой API)
• jsonwebtoken (генерирует и проверяет токены доступа / обновления)

Answer 4

Большинство настроек API включают в себя некоторый тип secretKey или APIKey, который является уникальным для разработчика.Поскольку вы являетесь единственным разработчиком, вы можете просто установить ключ / хеш в своем мобильном приложении, который также будет передаваться для успешного возврата данных.

http://lcsd05.cs.tamu.edu/slides/keynote.pdf - это ключевая заметка, предоставленная Google о разработкехороший API с нуля.

Также посмотрите этот предыдущий вопрос