Безопасное соединение между клиентом и сервером

Question

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

Сейчас все находится в стадии бета-тестирования, и безопасность работает следующим образом:

1. клиент отправляет имя пользователя/пароль через https.

2. сервер возвращает токен доступа.

3. клиент отправляет дальнейшие запросы через http с токеном доступа в настраиваемом заголовке.

Это нормально для демо-версии, но есть некоторые проблемы, которые необходимо исправить перед выпуском:

• Любой может скопировать login запрос, повторно отправьте его и получите обратно токен доступа. Как ответили некоторые пользователи, это не проблема, поскольку все работает через https.Виноват.

• Любой может прослушать и получить ключ доступа, просто проверив заголовки запроса.

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

Большое спасибо за понимание.

ПС:На всякий случай я использую Java для сервера, а клиент написан на C++.

Answer 1

Я не понимаю первую часть. Если запрос на вход по протоколу https, как его можно просто скопировать?

Что касается второй части, т. Это довольно стандартный сценарий перехвата сеанса.Видеть этот вопрос.Конечно, здесь нет встроенных опций браузера, но основная идея та же — либо отправлять токен только через безопасное соединение, когда это необходимо, либо каким-то образом связать токен с отправляющим устройством.

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

Редактировать:Здесь вам может просто повезти, и вы сможете исключить изменение IP-адреса за прокси-серверами и фактически использовать его для этой цели.

Но в конце концов, это много безопаснее использовать https из известной и проверенной библиотеки, а не пытаться создать здесь свою собственную.Я понимаю, что https — это накладные расходы, но использование собственного протокола сопряжено с большими рисками, связанными с пропуском очевидных вещей, которыми может воспользоваться злоумышленник.

Answer 2

Первый вопрос, просто чтобы уточнить:если вы достаточно обеспокоены гнусным доступом к клиенту-имитатору, почему бы не провести весь разговор через HTTPS?Является ли минимальное снижение производительности настолько значительным для этого приложения, что оно не стоит дополнительного уровня безопасности?

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

Answer 3

Одна из распространенных рекомендаций — используйте https.

Атака «человек посередине» https, кроме использования https для всего сеанса, должна быть достаточно надежной.Вам даже не нужно беспокоиться о токенах доступа — https позаботится об этом за вас.

Использование http для дальнейших запросов, похоже, создает некоторые уязвимости.Теперь любой, у кого есть сетевой анализатор, может перехватить ваш трафик, украсть токен и подделать ваши запросы.вы можете построить защиту, чтобы предотвратить это - шифрование токенов, использование одноразовых токенов и т. д.но при этом вы заново создадите https.

Возвращаясь к атаке «человек посередине» https: она основана на чьей-то способности вставить себя между вашим сервером и вашим клиентом и направить ваши запросы через их код.Это все выполнимо, т.е.в случае, если злоумышленник имеет доступ к физической сети.Проблема, с которой столкнется такой злоумышленник, заключается в том, что он не сможет предоставить вам правильный цифровой сертификат, поскольку у него нет закрытого ключа, который вы использовали для его подписи.Когда доступ к https осуществляется через браузер, браузер выдает предупреждение, но все равно может пропустить вас на страницу.

В вашем случае ваш клиент будет общаться с сервером.И вы можете убедиться, что все необходимые проверки сертификата выполнены.Если ты это сделаешь, с тобой все будет в порядке

Редактировать

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