Как защитить веб-службы RESTful?

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

Параметры:

TLS (HTTPS) +

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

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

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


person Jan Deinhard    schedule 27.01.2011    source источник


Ответы (3)


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

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

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

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

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

person Tom Ritter    schedule 27.01.2011
comment
Хорошо, теперь я не понимаю, что лучше, этот подход или другой ответ. Не могли бы вы уточнить? : D - person fikr4n; 18.04.2014
comment
Ваш ответ идеально подходит для мастеров, но сбивает с толку новичков. Не могли бы вы предоставить подробную информацию или ссылки для чтения? - person Rajan Rawal; 02.06.2014
comment
Если сертификаты самоподписаны, насколько это безопасно? - person Joyce; 19.03.2015
comment
@Joyce Я бы не подумал. Поскольку вам не доверяют (без обид), сертификатам, которые вы подписываете (своим собственным сертификатом), нельзя доверять. Я считаю, что самоподписанные сертификаты более полезны для тестирования. - person mbmast; 08.01.2016
comment
Учитывая, что у конечного пользователя (клиента) есть сертификат клиента, открытый ключ которого используется совместно с сервером, не развалится ли вся эта очень безопасная вещь, если компьютер клиента будет взломан, а его сертификат клиента украден? - person mbmast; 08.01.2016
comment
@Rajan Rawal: руководство по Java дает хорошее объяснение аутентификации с помощью клиентских сертификатов, включая взаимную аутентификацию с клиентскими сертификатами (т.е. сервер аутентифицирует клиента, клиент аутентифицирует сервер). см. руководство по аутентификации сертификата - person StvnBrkdll; 18.07.2016

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

person pc1oad1etter    schedule 27.01.2011
comment
Я не думаю, что дайджест http дает вам что-нибудь по сравнению с базовым http, если они оба работают по https. - person pc1oad1etter; 28.01.2011
comment
Вы можете серьезно добавлять полезную информацию о преимуществах HTTP-дайджеста. - person pc1oad1etter; 24.04.2014

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

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

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

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

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

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

person dthorpe    schedule 17.04.2013