Я пытаюсь понять, как использовать маркеры API для аутентификации запросов на сервер. Я понимаю общую концепцию, что токен отправляется с каждым запросом и сравнивается с токеном, хранящимся в каком-то сеансе, для аутентификации запроса. Я также понимаю, что токен никогда не должен отправляться «в диком виде», поэтому он обычно шифруется с использованием SSL.Что мешает MIM отправлять encypted API Token
Что я не понимаю, так это то, как он останавливает человека в средних атаках. Рассмотрим следующую ситуацию.
Предположим, я зашел в систему и хочу изменить свой адрес электронной почты. При входе в систему токен генерируется для меня, скажем, токен = 1234. Так что скажем, я пришлю следующую команду https://example.com/[email protected]&token=1234
Для простоты предположим, что [email protected] = xyz (зашифровано SSL), evilemail @ live.com = abc (зашифровано SSL) и 1234 = 4321 (зашифровано SSL).
Таким образом, MIM получает что-то вроде https://example.com/updateEmail?email=xyz&token=4321.
Что мешает MIM получить это и изменить его на https://example.com/updateEmail?email=abc&token=4321? Разве сервер не расшифровал бы с 4321 по 1234 год, скажем, что он соответствует и обновляет письмо по адресу [email protected]?
Примечание: я не передаю идентификатор пользователя, поскольку он хранит переменную сеанса на сервере.
Когда пользователь входит в систему, для них делается токен. '1234' будет уникальным для« [email protected] »и, следовательно, не соответствует« [email protected] ». –
Я голосую, чтобы закрыть этот вопрос как не относящийся к теме, потому что security.stackexchange.com - лучшее место, чтобы задать общие вопросы архитектуры безопасности. SO - для программирования вопросов, и вы не разместили какой-либо код. – Barmar
Также обратите внимание, что трафик через SSL полностью зашифрован между вашим браузером и сервером. Если у MITM нет ключа для дешифрования соединения, у них не будет доступа к переданным параметрам get. Таким образом, MITM не сможет получить адрес электронной почты/токен, чтобы изменить его. –