Oauth 2 - упорядочение параметров и целостность подписи
У меня есть два вопроса:
Q1: Почему OAuth2 требует, чтобы параметры были упорядочены и закодированы (для двухногих)?
Все, о чем нужно беспокоиться, - это согласованная подпись в конце для данных (строка запроса).
Мы можем просто проверить подпись, сгенерированную с использованием строки запроса (например, a = 1 & b = 2). Поскольку подпись создается на основе секретного ключа, который известен только клиенту и провайдеру, мы можем рассматривать строку запроса без какого-либо упорядочения/кодирования.
Итак, какое преимущество при выполнении заказа/кодирования, а затем создание подписи?
Q2: Как эта подпись может спасти меня от атаки "человек-в-середине"?
Если мне нужно сделать такой запрос на моем сервере с клиента:
increaseUserPoints?userId=1&pointsToAdd=5&appId=x&token=XYZ
Теперь токен XYZ будет всегда таким же, поэтому хакер может продолжить отправку одного и того же запроса, чтобы увеличить points. Так как сгенерированный токен из данного appId тот же, сервер разрешит это. Как обрабатывается этот случай?
Ответы
Ответ 1
Q1: Заказ параметров запроса обеспечивает разумность для HMAC.
Скажем, у вас есть два параметра: "pointsToAdd" и "appId". Использование строки запроса pointsToAdd=X&appID=y создает другой HMAC для appID=y&pointsToAdd=X. Поскольку вам и серверу необходимо сгенерировать тот же HMAC, чтобы проверить, что запросы с неупорядоченными параметрами parmeters не работают.
Q2: Это избавит вас от атаки, потому что только вы и сервер знаете, как подписать ваш запрос.
У вас есть секретный ключ, и только вы и сервер его знаете. Этот ключ подписывает запрос. Если HMAC не соответствует этому секретному ключу, запрос не выполняется.
Поскольку все параметры были использованы для создания HMAC, запрос защищен от атак MITM - хакер не может изменять, добавлять или удалять любые параметры запроса, или сервер будет создавать другой HMAC при попытке авторизации и запрос не работает.
