Зачем нам безопасность службы REST, если у нас есть HTTPS?

13

Я ссылаюсь на эту прекрасную статью http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/, в которой говорится о безопасности, подобной Amazon для веб-службы. Однако мне задали вопрос в команде, зачем нам это нужно, если мы уже используем HTTPS. Я не смог ответить, так как мне действительно кажется, что они могут быть правы, хотя интуиция говорит мне об обратном.

Также есть ли места при предоставлении услуг REST, где HTTPS может не работать? Понравились сторонние сайты?

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

Заранее спасибо.

РЕДАКТИРОВАТЬ: Чтобы уточнить, я не говорю об аутентификации пользователя, но больше о аутентификации клиента. Аутентификация пользователя может быть принята как обычный текст по HTTPS + REST.

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

rest Абхишек Дуджари
источник
3
Лучше всего подходит для security.stackexchange.com ?
jweyrich
1
Может быть, вы правы, но мой вопрос более чем связан.

Ответы:

13

Почему мы должны предоставить Gmail - или любому другому сайту с учетными записями пользователей - наше имя пользователя и пароль, если он уже использует HTTPS? Ответ такой же, как ответ на ваш вопрос.

HTTPS обеспечивает, прежде всего, зашифрованное соединение между сервером и клиентом.

Доверие, присущее HTTPS, основано на основных центрах сертификации, которые предварительно установлены в программном обеспечении браузера (это эквивалентно высказыванию «Я доверяю центру сертификации (например, VeriSign / Microsoft / и т. Д.), Чтобы сказать мне, кому я должен доверять»).

Если сервер не дает каждому пользователю сертификат , сервер не может доверять клиенту без какого-либо другого метода аутентификации.

Мэтт Болл
источник
извините, что вы неправильно поняли, или я не был ясен. Документы Amazon APi заявляют, что мы должны использовать HTTPS, но если мы не делаем ТО, мы подписываем запрос. Пароль пользователя не имеет значения на данном этапе.
3
На высоком уровне вам необходимо подтвердить свою личность на сервере, чтобы он мог принимать команды от вас. Аутентификация клиента может быть выполнена через HTTPS, а также может быть выполнена с помощью подписи сообщений.
Мэтт Болл
1
Если вы хотите использовать HTTPS для аутентификации клиента, вам необходимо выдать каждому пользователю сертификат открытого ключа, как описано в последней ссылке в моем ответе. Думайте об этих сертификатах как об электронной версии паспорта.
Мэтт Болл
1
Вы ссылаетесь на "дать каждому пользователю сертификат". Ответы на мои вопросы. Я предполагаю, что весь закрытый открытый ключ и подпись все еще необходимы для надлежащей защиты обоих концов в веб-сервисе, поэтому SSL на сервере недостаточно. Ваш ответ пока самый близкий. большое Вам спасибо.
Абхишек Дуджари
1
+1 Хорошо, что вы упоминаете клиентские сертификаты, но не обязательно, чтобы сервер выдавал сертификаты. Они просто должны быть подписаны доверенным центром сертификации; в основном так же, как работают серверные сертификаты.
JimmyJames
3

HTTPS очень хорошо предотвращает подслушивание и атаки «человек посередине». Как это шифрует весь трафик для сеанса.

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

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

Джеймс Андерсон
источник
Я думаю, что вы очень близки к тому, что я прошу. Таким образом, вы предлагаете нам подписать запрос на стороне клиента, даже если мы используем HTTPS?
2

HTTPS - это защита канала, а не доказательство того, кто является вызывающим абонентом, или многих других вещей, которые вам необходимо учитывать. Аутентификация, авторизация и шифрование транспортного уровня - это лишь малая часть того, что вам нужно учитывать. Многие из известных уязвимостей, связанных с веб-приложениями, очень сильно относятся к REST apis. Вы должны учитывать проверку ввода, взлом сеанса, неуместные сообщения об ошибках, внутренние уязвимости сотрудников и так далее. Это большая тема.

Роберт

Роберт Моршель
источник
0

Вы можете использовать подход клиентских SSL-сертификатов и отделить безопасность от API. Большим недостатком этого подхода являются накладные расходы на эксплуатацию, которые будут дорогостоящими, поскольку все больше и больше клиентов потребляют ваш API.

В любом случае, базовая аутентификация HTTP прекрасно подходит для подавляющего большинства общедоступных сервисов.

CodeToGlory
источник