Безопасность веб-сервисов на основе REST на основе подписей HTTP

Question

Я провел некоторое исследование по использованию правильного механизма безопасности для нашего веб-сервиса REST. Я просматривал документацию по HTTP-сигнатурам -> https://tools.ietf.org/html/draft-cavage-http-signatures-12.

На основе этой документации некоторые заголовки HTTP выбираются, хэшируются и имеют цифровую подпись. Эта подписанная строка обновляется в заголовке HTTP. Поставщик услуг воссоздает ha sh (на основе полученных заголовков HTTP) и проверяет подписанную строку для аутентификации клиента. Это также, в свою очередь, доказывает, что сообщение не подделано.

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

Answer 1

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

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

Если да тогда сообщение, полученное поставщиком услуг, не является тем, которое предназначено клиентом, не так ли?

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

Итак, как этот способ подписания HTTP-запроса обеспечивает целостность сообщения?

Он обеспечивает целостность только тех частей, которые клиент выбирает для подписи. Чтобы обеспечить целостность полного сообщения, вам также необходимо проверить подписанные headers и убедиться, что они охватывают все, что вы хотите обработать.

Если вы хотите узнать больше о схемах подписи и альтернативы, ознакомьтесь с постом, который я написал именно об этом: Руководство по аутентификации Web API, Схемы подписи .

Answer 2

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

A Быстрый просмотр документа спецификации, на который вы указываете: В нижней части страницы 10 прочитайте, как показано ниже:

POST / foo HTTP / 1.1 Хост: example.org Дата: вторник, 07 июня 2014 г. 20:51:35 GMT Тип контента: приложение / json Дайджест: SHA-256 = X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE = Длина контента: 18

{"hello": "world"}

Обратите внимание, что использование поля заголовка Digest соответствует RF C 3230 [RFC3230], раздел 4.3.2 [12] и включен просто как демонстрация того, как разработчик мог включить информацию о теле сообщения в подпись.

Answer 3

Существует другой механизм, который также предотвращает вмешательство, работает с заголовками и телом (и всем остальным) и уже широко поддерживается: HTTPS