Oauth 2 — порядок параметров и целостность подписи

У меня есть два вопроса:

Вопрос 1. Почему OAuth2 требует, чтобы параметры были упорядочены и закодированы (для двусторонней связи)?

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

Мы можем просто проверить подпись, сгенерированную с помощью строки запроса (например, ?a=1&b=2). Поскольку подпись генерируется на основе секретного ключа, который известен только клиенту и провайдеру, мы можем рассматривать только строку запроса без какого-либо порядка/кодирования.

Итак, в чем преимущество выполнения заказа/кодирования, а затем создания подписи?

Вопрос 2. Как эта подпись может спасти меня от атаки "человек посередине"?

Если мне нужно сделать такой запрос на мой сервер от клиента:

increaseUserPoints?userId=1&pointsToAdd=5&appId=x&token=XYZ

Теперь токен XYZ всегда будет одинаковым, поэтому хакер может продолжать публиковать один и тот же запрос на увеличение points. Поскольку сгенерированный токен из данного appId один и тот же, сервер разрешит это. Как решается этот случай?


oauth-2.0
person Learner    schedule 05.03.2012    source источник
comment
Почему это помечено как oauth-2, а вы обсуждаете HMAC?   -  person Mukus    schedule 24.03.2017

Ответы (1)


arrow_upward
5
arrow_downward

Q1: Упорядочивание параметров запроса делает HMAC более разумным.

Допустим, у вас есть два параметра: «pointsToAdd» и «appId». Использование строки запроса pointsToAdd=X&appID=y создает HMAC, отличный от appID=y&pointsToAdd=X. Потому что и вам, и серверу необходимо сгенерировать один и тот же HMAC, чтобы убедиться, что запросы с неупорядоченными параметрами запросов просто терпят неудачу.

Q2: Это убережет вас от атаки, потому что только вы и сервер знаете, как подписать ваш запрос.

У вас есть секретный ключ, и только вы и сервер знаете его. Этот ключ подписывает запрос. Если HMAC не соответствует этому секретному ключу, запрос завершается ошибкой.

Поскольку для создания HMAC использовались все параметры, запрос защищен от MITM-атак — хакер не может изменить, добавить или удалить какие-либо параметры запроса, иначе сервер создаст другой HMAC при попытке авторизации, а запрос завершится ошибкой.

person tonyhb    schedule 07.03.2012
comment
А как насчет повторных атак? Если временная метка не используется в качестве компонента для создания токена, сервер будет воспроизводить его. - person Mukus; 24.03.2017