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

Question

Я должен реализовать безопасный RESTful web services. Я уже проводил некоторые исследования с использованием Google, но я застрял.

Варианты:

TLS (HTTPS) +

• HTTP Basic (pc1oad1etter)
• HTTP Digest
• two-leggedOAuth
• a Cookie-based approach
• сертификаты клиента (Tom Ritter и here)
• Подписанные запросы с использованием HMAC и a limited lifetime

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

Я нашел еще одну очень интересную статью о REST based authentication.

Secure Your REST API... The Right Way

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

Маркировочные маркеры OAuth должны использоваться только с надежным транспортом.

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

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

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

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