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

Question

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

Сейчас все бета и безопасности работает так:

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

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

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

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

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

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

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

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

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

Answer 1

У меня нет первой части. Если запрос на вход - https, как можно просто его скопировать?

Относительно второй части, t Это довольно стандартный сценарий захвата сеанса. См. this question. Конечно, у вас нет встроенных параметров браузера, но основная идея одна и та же: либо отправлять токен только по защищенному соединению, когда это имеет значение, либо каким-то образом ассоциировать токен с отправляющим устройством.

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

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

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

Answer 2

Одним из общих рекомендаций является - использование протокола HTTPS

Https человек в середине атаки в сторону, используя протокол HTTPS для всего сеанса должно быть достаточно надежным. Вам даже не нужно беспокоиться о токенах доступа - https заботится об этом для вас.

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

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

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

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

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

Answer 3

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

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