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


88

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

Параметры:

TLS (HTTPS) +

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

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

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

Ответы:


59

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

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

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

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

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


Хорошо, теперь я не понимаю, что лучше, этот подход или другой ответ . Не могли бы вы уточнить? : D
fikr4n

Ваш ответ идеален для мастеров, но сбивает с толку новичков. Не могли бы вы предоставить подробную информацию или ссылки для чтения?
Rajan Rawal

Если сертификаты самоподписаны, остается ли это «очень безопасным»?
Джойс

@Joyce Я бы не подумал. Поскольку вам не доверяют (без обид), сертификатам, которые вы подписываете (с вашим собственным сертификатом), нельзя доверять. Я считаю, что самоподписанные сертификаты более полезны для тестирования.
mbmast 08

Учитывая, что у конечного пользователя (клиента) есть сертификат клиента, открытый ключ которого используется совместно с сервером, не развалится ли вся «очень безопасная» вещь, если компьютер клиента взломан, а его сертификат клиента украден?
mbmast 08

18

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


3
Я не думаю, что дайджест http дает вам что-нибудь по сравнению с базовым http, если они оба работают по https.
pc1oad1etter

3
Вы можете серьезно добавлять полезную информацию о преимуществах HTTP-дайджеста.
pc1oad1etter

9

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

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

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.