Как вы определяете порядок параметров HTTP-запроса при расчете HMAC? - PullRequest
3 голосов
/ 01 декабря 2011

Я пишу веб-сервис, который будет использовать HMAC для аутентификации.Краткий обзор: HMAC - это дайджест сообщения, рассчитанный с использованием тела сообщения и секретного ключа.Отправитель вычисляет HMAC и присоединяет его к запросу, затем получатель вычисляет дайджест сообщения при получении с использованием секретного ключа, который он имеет в файле.Если дайджесты совпадают, то получатель может быть уверен, что сообщение было отправлено человеком, которого он называет.

Мой вопрос касается порядка параметров.Допустим, запрос веб-службы имеет три параметра: foo, bar и baz.Тело HTTP POST будет выглядеть примерно так:

foo=1&bar=2&baz=3&hmac=de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9

(HMAC в данном случае является поддельным примером.)

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

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

1 Ответ

0 голосов
/ 02 декабря 2011

Я бы сказал, что манипулируя телом запроса после , вы вычислили хеш на основе этого тела, что важно для того, принят ли запрос, как правило, является плохой практикой (по причинам, которые я чувствую, очевидны). Этот HMAC не должен добавляться к телу запроса, а должен быть задан либо в параметре GET, в файле cookie, либо в пользовательском заголовке.

Это также уменьшает burden on the implementor on the server side для вашего первого предложения, и я рекомендую этот путь.

Но это я, у других могут быть разные мнения на все это ...

...