Что включать при подписании запроса API

Question

Если у меня есть сложный объект, который был отправлен как запрос API (например, Заказ ниже), я должен включить все свойства при генерации подписи или я должен использовать только подмножество?

Я спрашиваю, потому что мне неясно, и, глядя на другие API, параметры запросов плоские и простые

public class Order
    {
        public string Id { get; set; }
        public string ClientIdentifier { get; set; }
        public IEnumerable<OrderItems> OrderItems { get; set; }
        public long timestamp { get; set; }
        public string signature { get; set; }
    }

public class OrderItems
{
    public string ItemId { get; set; }
    public string Name { get; set; }
    public IEnumerable<decimal> PriceBands { get; set; }pes
            more types



}

and so on ....

Answer 1

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

1. При подписанном запросе пароль сохраняется в безопасности, и злоумышленник не может использовать информацию в запросе, чтобы подписать другой запрос. Это полезно, если злоумышленник видит запрос, отправляемый на сервер.
2. Злоумышленник не может изменить какие-либо данные в запросе, которые использовались для генерации подписи, без аннулирования подписи, в результате чего сервер отклонил запрос.

Номер 2 имеет подвох. Это только помогает защитить данные, которые являются частью подписи. Если вы пропустите какие-либо данные, злоумышленник может изменить эти данные и отправить сообщение, отличное от того, которое вы отправили. Вот почему при подписании запроса должны быть включены все данных запроса: полный URI, включая домен, заголовки, параметры строки запроса и любые опубликованные данные, такие как XML или JSON.

Answer 2

Как уже указывалось, вам нужно выяснить, какие атаки вы хотите предотвратить.

Обычный подход к случаю, когда данные, которые вы отправляете, чувствительны, заключается в использовании HTTPS (SSL) для связи с сервером.,В этом случае вам не нужно шифровать / подписывать данные самостоятельно, любой простой протокол, включая отправку JSON, в порядке.

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

Если вы хотите убедиться, что данные не подделаны через HTTP - подпишите весь блок данных ... Но гораздо труднее правильно реализовать, чем использовать существующиеSSL-соединение.Выезд http://blogs.msdn.com/b/ericlippert/archive/2011/09/27/keep-it-secret-keep-it-safe.aspx

Answer 3

Как подсказал Навин в комментарии выше, ваш вопрос, похоже, не является вопросом OAuth напрямую:

Глядя на (довольно хорошее) объяснение потока OAuth на http://hueniverse.com/oauth/guide/authentication/приводит к заключению, что все параметры в запросе OAuth необходимо использовать при подписании запроса, потому что сервер также примет все параметры (по определению) для проверки подписи, поэтому я предлагаю использовать все параметры для подписи тоже;)

Но (в качестве примечания):

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

Предполагая, что вы сериализуете данные в XML или JSON для использования в качестве параметра запроса, вы получите «простострока "для данных.Эти данные - используемые в качестве параметра запроса - будут полностью использоваться для подписи, как упоминалось выше.

Я бы также предложил использовать реализацию OAuth-клиента с открытым исходным кодом.Хорошим местом для начала поиска является страница клиентской библиотеки Twitter по адресу https://dev.twitter.com/docs/twitter-libraries#dotnet, поскольку Twitter использует OAuth для стороннего доступа к своему API и библиотеки (такие компоненты OAuth, как Hammock) стабильны.