Рекомендации по защите API без логина/пароля

У меня есть клиентское приложение, которое можно идентифицировать с помощью некоторого UID. У меня есть бэкэнд-сервис, который клиентское приложение нужно вызвать, чтобы получить некоторые списки. Какова была бы наилучшая практика для обеспечения этой бэкэнд-службы? Я не хочу защищать логин/пароль (потому что клиенту не требуется «войти» для извлечения списков), однако я бы не хотел, чтобы кто-нибудь легко вызывал этот API-интерфейс и извлекал эти списки для своих целей , Подумайте о клиенте как пользовательский клиент Flash или мобильный клиент и т. Д. Связь осуществляется через HTTP REST. Любые идеи?Рекомендации по защите API без логина/пароля

Благодаря

UPDATE: К сожалению, забыл упомянуть - без использования SSL. В принципе, я ищу здесь идею алгоритма/стратегии. Спасибо за предложения!

источник

2012-07-03 alexeypro

какой-нибудь длинный случайный токен, который идентифицирует пользователя? – alfasin

Что случилось с другим ответом? У него были действительно хорошие ссылки! –

Если вы не используете SSL, вы потерпите неудачу. Плохой парень может легко следить за связью между сервером/клиентом и делать всевозможные плохие вещи. –

Основная идея здесь в том, что вы будете использовать HTTPS с клиентом настроен подписывать свои запросы, используя сертификат X.509, что поставщик API выданный им через какой-либо другой безопасный метод. Сервер будет иметь этот сертификат (или, еще лучше, сертификат, сертификат клиента которого является дочерним), а также может проверить, был ли с ним подписан подписанный запрос. Это довольно стандартно для связи между серверами. Это не сработает, если вы создаете приложение для конечных пользователей для запуска локально, потому что плохой парень может легко извлечь этот сертификат из клиентского приложения и победить всю схему.

Существует множество статей, посвященных технологиям чтобы настроить это, и вы не указали, какой стек вы используете, но вот общая статья, чтобы доказать, что я не делаю этот материал :) http://www.ibm.com/developerworks/lotus/library/ls-SSL_client_authentication/

источник

2012-07-03 04:05:40

Это отличное решение, если у вас есть связь между серверами, если вы можете убедиться, что ваш сертификат безопасен. – Tilo

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

, если вы воспользуетесь усилиями по созданию собственного центра сертификации (Certificate Authority), вы можете предоставить каждому отдельному клиенту собственный сертификат - таким образом, сертификаты могут быть отозваны индивидуально, если они скомпрометированы .. но это, вероятно, слишком сложно, как практический сценарий – Tilo

Вы должны посмотреть на OAuth для авторизации, и соединение всегда должно быть HTTPS, поэтому пакеты не могут быть легко обнюханы.

Чтобы использовать это без аутентификации, довольно небезопасно, так как любой может попытаться олицетворять действительного клиента. Наличие соединения HTTPS только замедлит хакера.

См:

http://oauth.net

http://en.wikipedia.org/wiki/OAuth

http://library.edgecase.com/securing-apis-using-rack-middleware (для Rails/Rack)

http://developers.sun.com/identity/reference/techart/restwebservices.html

http://www.slideshare.net/mohangk/securing-your-web-api-with-oauth

и это может быть интересно, а также: (без OAuth)

http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

источник

2012-07-03 04:02:43 Tilo

№ OAuth позволяет пользователю предоставить одну систему * авторизацию * для доступа к данным этого пользователя из других служб системы. Авторизация и аутентификация - это совсем другие звери, и, как вы увидите на сайте oauth.net, с которым вы связались, OAuth пытается только разрешить авторизацию. Кроме того, это противоречит требованию OP, чтобы пользователи не вводили учетные данные. –

@RobertLevy: Хотя я согласен с тем, что OAuth используется для разрешения авторизации с точки зрения пользователя (User1 разрешает ServiceA использовать данные из ServiceB), безусловно, служба может использовать OAuth для аутентификации? Как и в ServiceA, пользователь 1 должен аутентифицировать себя с помощью ServiceB (и в то же время получает разрешение на использование идентифицирующей информации из ServiceB). Это то, что многие сайты, включая SO, теперь предлагают как способ входа в систему без необходимости создавать отдельные учетные записи по всему Интернету. –

Привет, я думаю, вы могли бы взглянуть на эту статью , он использует hmac-аутентификацию. http://bitoftech.net/2014/12/15/secure-asp-net-web-api-using-api-key-authentication-hmac-authentication/

Помните, что этот хеш можно использовать для гарантии целостности, например, если вы передаете запрос и сервер получает запрос и хэш-файл, сервер будет хэш-запрос и сравнить оба запроса, сервер и клиент. Если они совпадают, вы можете быть уверены, что запрос не будет изменен при переходе. Если у вас есть личное значение (никто не должен этого знать!), скажем, «hiworld» (значения - фактически гиды или случайные значения), и вы используете это значение в качестве параметра для хэша, вы получите специальное значение хэша. Если вы отправляете запрос по специальному значению хэша, а сервер (кто знает частное значение) хэширует запрос с использованием этого специального значения, и оба хэша имеют совпадение, сервер может быть уверен, что запрос не был изменен, и что вы были теми, кто его отправил.

источник

2017-02-06 05:47:25

Рекомендации по защите API без логина/пароля

ответ

Смежные вопросы