Я прошу об этом, потому что я работаю над приложением, в котором X-AUTH-TOKEN можно копировать с одного запроса другому и выдавать себя за другого человека. Это заставляет меня нервничать, но мне говорят, что мы будем использовать HTTPS, нам не нужно ни о чем беспокоиться.Достаточно ли SSL для защиты запроса и его заголовков?
Итак, мой вопрос: достаточно ли доверия SSL для защиты от кражи заголовков, используемых для авторизации/сеансов?
Спасибо,
стандартные орудия HTTPS HTTP полностью поверх SSL/TLS. Из-за этого практически все, кроме DNS-запроса, зашифровывается. Поскольку заголовки являются частью запроса и ответа и отправляются только после создания защищенного канала, они точно так же безопасны, как и реализация HTTPS на данном сервере.
HTTPS - это сквозное шифрование всего сеанса HTTP, включая заголовки, поэтому на его лице вы должны быть в безопасности от подслушивания.
Однако это только часть истории: в зависимости от того, как клиенты фактически подключаются (это веб-сайт или служба API?), Все равно можно будет обмануть их в отправке данных в неправильное место , например:
Никто не может быть уверен в безопасности, чтобы предотвратить все атаки. Основное соображение должно заключаться в компромиссе между тем, насколько сложными будут дополнительные меры для реализации против ущерба, который может быть нанесен, если злоумышленник использовал вас, не делая их.
Спасибо за ответ. Услуга предназначена для api для нашего интерфейса html или если кто-то хочет написать собственный клиент и использовать наш apis. – 2Real
Использование HTTPS-шифрования действительно не позволит кому-то украсть ваш токен аутентификации, если они могут перехватить трафик. Это не обязательно предотвратит нападение «человек в середине», хотя клиент не может проверять сертификаты сверстников.
This question from the security stackexchange описывает, как реализовать атаки MITM против SSL. Если я могу убедить клиента, использующего HTTPS для подключения к моему серверу, и , они принимают мой сертификат, тогда я могу украсть ваш токен аутентификации и повторно использовать его. Проверка валидного сертификата иногда немного больна для настройки, но это может дать вам более высокий шанс того, к кому вы подключаетесь, - это те, кто они говорят.
«Достаточно хорошо» является относительным определением и зависит от вашего уровня паранойи. Лично я был бы рад, что мое соединение достаточно безопасно, и HTTPS и проверка сертификатов сверстников включены.
Предположительно также время аутентификации для токенов, поэтому окно атаки будет ограничено по времени. Например, токен аутентификации OpenStack по умолчанию действует в течение 24 часов до истечения срока его действия, а затем вам необходимо получить новый.
Спасибо. Я вижу, поэтому я не должен беспокоиться о проблеме безопасности, потому что она будет закрыта HTTPS.Мне было интересно, лучше ли использовать передовые методы управления сеансами вместе с использованием HTTPS (IMO, если HTTPS не используется, это был серьезный недостаток безопасности, и именно поэтому я нервничаю). – 2Real
Я не говорю, чтобы не беспокоиться об этом, но что HTTPS обеспечивает уровень безопасности и защиты от типов атак MIM. Лучшая практика для управления сессиями обязательно должна соблюдаться! :) – davidalger
Спасибо, дает мне хорошее представление о том, как действовать :) – 2Real