Как обеспечить безопасность веб-сервисов RESTful? - PullRequest
88 голосов
/ 27 января 2011

Мне нужно внедрить безопасные RESTful веб-сервисы . Я уже провел некоторые исследования с помощью Google, но я застрял.

Параметры:

TLS (HTTPS) +

Есть ли еще возможные варианты для рассмотрения? Если OAuth то какая версия? Имеет ли это значение? Из того, что я до сих пор читал, OAuth 2.0 с токенами на предъявителя (то есть без подписи) кажется небезопасным .

Я нашел еще одну очень интересную статью о аутентификации на основе REST .

Защитите свой REST API ... Правильный путь

Ответы [ 3 ]

58 голосов
/ 27 января 2011

Есть еще один, очень безопасный метод. Это клиентские сертификаты. Знаете, как серверы представляют сертификат SSL, когда вы связываетесь с ними по https? Ну, а серверы могут запросить сертификат у клиента, чтобы они знали, что клиент - это тот, кем они себя называют. Клиенты генерируют сертификаты и передают их вам по безопасному каналу (например, заходя в ваш офис с USB-ключом - предпочтительно не троянским USB-ключом).

Вы загружаете открытый ключ клиентских сертификатов cert (и сертификат (ы) подписывающего лица, если необходимо) на ваш веб-сервер, и веб-сервер не принимает подключения от кого-либо кроме людей, у которых есть соответствующие закрытые ключи для сертификатов, о которых он знает. Он работает на уровне HTTPS, поэтому вы можете даже полностью пропустить аутентификацию на уровне приложений, например, OAuth (в зависимости от ваших требований). Вы можете абстрагировать слой и создать локальный центр сертификации и подписать запросы клиентов на получение сертификатов, что позволяет пропустить шаги «заставить их войти в офис» и «загрузить сертификаты на сервер».

Боль в шее? Абсолютно. Хорошо для всего? Нету. Очень безопасно? Ага.

Однако он полагается на то, что клиенты сохраняют свои сертификаты в безопасности (они не могут публиковать свои закрытые ключи в Интернете), и обычно используется, когда вы продаете услугу клиентам, а не позволяете кому-либо зарегистрироваться и подключиться.

В любом случае, это может быть не то решение, которое вы ищете (возможно, это не совсем честно), но это другой вариант.

18 голосов
/ 27 января 2011

HTTP Basic + HTTPS - один из распространенных методов.

9 голосов
/ 17 апреля 2013

При выборе между версиями OAuth используйте OAuth 2.0.

Токены-носители OAuth следует использовать только с безопасным транспортом.

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

Хотя верно, что если кто-то перехватывает ваш токен на предъявителя, он может выдать себя за вас при вызове API, существует множество способов снизить этот риск.Если вы даете своим токенам длительный срок действия и ожидаете, что ваши клиенты будут хранить токены локально, у вас больше риск перехвата и неправильного использования токенов, чем если бы вы давали токены короткий срок действия, требуя от клиентов приобретать новые токены для каждого сеанса,и советуйте клиентам не сохранять токены.

Если вам нужно защитить полезные данные, проходящие через нескольких участников, вам нужно нечто большее, чем HTTPS / SSL, поскольку HTTPS / SSL шифрует только одну ссылку графа.Это не ошибка OAuth.

Токены на предъявителя легко доступны для клиентов, просты в использовании клиентами для вызовов API и широко используются (с HTTPS) для защиты общедоступных API от Google, Facebook,и многие другие услуги.

...