Имеет ли смысл эта система аутентификации сеанса / токена для моего веб-API?

Question

Сегодня я внедрил систему аутентификации сеанса / токена для моего веб-API (стиль http get / post rpc), следуя этому плану:

легенда : действие (param1, param2): returnvalue1, returnvalue2

• логин (имя пользователя, пароль): сеансовый ключ, токен
• requestA (сеансовый ключ, токен, paramA): токен
• requestB (сеансовый ключ, токен, paramB): токен
• Выйти (сеансовый ключ, токен): void

Действие входа в систему отправляется через https для защиты данных пользователей. Вы получаете комбинацию сеанс / токен, где один токен действителен только для одного запроса (вы всегда получите новый токен при обычных запросах). Мои мысли были направлены на то, чтобы уменьшить риск атаки типа «человек посередине», отнюдь ваш ключ сеанса: если вам «повезло», токен со взломом уже был признан недействительным по вашему собственному последующему запросу.

Мой бэкэнд и его юнит-тесты в порядке, но я не думал достаточно далеко - я наконец столкнулся с проблемами с асинхронными вызовами ajax, которые опровергают эту идею одноразового токена.

Стоит ли дополнительная безопасность не в состоянии обрабатывать асинхронные запросы?

Одна идея заключалась в том, чтобы ввести очередь запросов внутри моего ajax-приложения - кто-то делал что-то подобное, и вы бы порекомендовали это?

Возможно, менее безопасным, но более удобным способом было бы не обновлять токен для каждого запроса - разрешать асинхронную обработку, но сохранять исходный https-аутентификацию и добавлять строгий срок жизни к сеансу. Я также должен сохранить IP-адрес на стороне сервера сеанса.

Я пропустил другие ценные варианты?

Я привязан к существующим значениям имени пользователя / пароля, которые без исключения должны работать без изменений в новом приложении ajax.

Answer 1

Любые последующие запросы после аутентификации, которые выполняются в виде простого текста (чтение HTTP), следует рассматривать как небезопасные и подверженные любым атакам, которые вы можете себе представить.

Если ваша цель - обеспечить безопасность связи между клиентом и вашим сервером, HTTPS является обязательным для всего сеанса. Кроме того, вы захотите убедиться, что вы изменили куки-файл сеанса после того, как клиент перешел с HTTP на HTTPS (здесь я предполагаю, что вы делаете какое-то перенаправление, если исходный запрос на HTTP). Это распространенная ошибка, из-за которой клиент становится уязвимым для кражи сеанса.

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

Answer 2

Я думаю, что HTTPS и привязка сеанса к IP-адресу клиента и периодическая регенерация идентификатора сеанса (возможно, каждые 5 запросов) защитят ваш API. Добавление механизма запроса / токена улучшит безопасность, но больше не является обязательным, imho.

Одна проблема, с которой я столкнулся в системе запросов / токенов, заключается в том, что, если запрос не выполнен или ответ не получен, как клиент может возобновить связь? У него нет действительного токена запроса, и если ваш API работает правильно, он отклонит любой запрос:)

Answer 3

Мне кажется, что созданный вами механизм токенов на самом деле не защитит вас от атак "человек посередине". Представьте себе, что человек посередине перехватывает каждый (не HTTPS) запрос от клиента и заменяет его другим, который затем отправляется на сервер. Маркер, который сервер возвращает «посреднику», затем может быть просто возвращен клиенту, и клиент, вероятно, не сможет сказать, что его запрос никогда не поступал на сервер.

Есть ли способ, которым вы можете просто выполнять все запросы через https? Https обеспечивает достаточную защиту от атак «человек посередине», при условии, что вы используете надлежащие сертификаты и используете очень случайные ключи сеанса, которые недействительны слишком долго.