Является ли HTTPS единственной защитой от перехвата сессии в открытой сети? - PullRequest
Новая
       36

Является ли HTTPS единственной защитой от перехвата сессии в открытой сети?

37 голосов
/ 25 октября 2010

Таким образом, с Firesheep каждый в общедоступном Wi-Fi теперь имеет инструмент захвата сеанса одним щелчком мыши.

То, как он работает - насколько я понимаю, - это то, что он просто захватываетвесь трафик и захватывает файл cookie сеанса (чтобы он не крал пароли).

Насколько я понимаю, это также означает, что защищенный вход HTTPS не решает эту проблему самостоятельно, так как дальнейший трафик HTTP будет включать файл cookie сеансаснова в открытом тексте.

Привязка сеанса к определенному IP-адресу бесполезна благодаря NAT, а привязка его к пользовательскому агенту легко подделать.

Так же как и 100% HTTPSраз единственный способ предотвратить угон сеансов такого типа?Разве люди не могут просто понюхать весь трафик HTTPS, включая рукопожатие, или это безопасно?(Я имею в виду повторные атаки, но не знаю в этой области.)

Конечно, лучше не использовать общедоступные / открытые сети Wi-Fi, но мне все равно интересно, какой веб-сайтРазработчик может сделать, чтобы защитить своих пользователей.

Ответы [ 3 ]

40 голосов
/ 25 октября 2010

Firesheep - ничего нового .Перехват сеансов существует уже давно, пока веб-приложения используют идентификаторы сеансов.Обычно хакеры просто устанавливают свои собственные куки-файлы, вводя их в адресную строку: javascript:document.cookie='SOME_COOKIE'.Этот инструмент для сценаристов, которые боятся 1 строчки JavaScript.

Файлы cookie могут быть похищены, если вы не используете HTTPS в течение всего срока действия сеанса, и это является частью OWASP A9 - Недостаточная защита транспортного уровня .Но вы также можете захватить сеанс с XSS.

1) Использовать httponly cookie .

2) Использовать " secure cookies " (Ужасное имя, но это флаг, который заставляет браузер создавать cookie только для HTTPS.)

3) Сканирование вашего веб-приложения на наличие XSS.

Также не забудьте о CSRF !(Который Firesheep не обращается.)

12 голосов
/ 26 октября 2010

Ладья ответила на некоторые из них, я просто отвечу на другие части вашего вопроса.

Всегда ли 100% HTTPS - единственный способ предотвратить перехват сеансов такого типа?

Это верно. 100% HTTPS - единственный способ. И 100% - это ключ.

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

HTTPS имеет встроенную защиту от повторных атак. При правильной реализации HTTPS действительно безопасен.

Даже если HTTPS реализован правильно, есть способы обойти это. SSL Strip - один из таких инструментов. Инструмент не использует SSL, он просто использует тот факт, что люди всегда вводят mybank.com в URL вместо https://mybank.com.

1 голос
/ 12 мая 2016

Я считаю, что SSL - дешевое и полное решение.Но пока у вас его нет или вы ищете какие-то дополнительные слои, вот как защитить ваши данные СЕССИИ.

Как всегда, защита в отделе - это путь.1-е использование сессий для хранения данных для входа в систему. 2-е. Если администратор также вошел в систему и проверил наличие БД, он может немного замедлиться, но из-за небольшого количества администраторов, а остальные - пользователи, это реальный плюс безопасности.3-я ЗАЩИТА СЕССИИ <=! </p>

Защита сеанса: поместите начало сеанса в объектный файл, где вы вызываете функцию is_session_valid () для собственной конструкции.Эта функция проверяет (IP / TIME / Browser) на суперглобальный $ _SERVER и сохраняет их в сеансе.Наверх При следующей загрузке посмотрите, совпадают ли значения, если не просто не тратить больше ресурсов на выход пользователя из системы и покажите страницу индекса.

Это не полное решение, так как это может быть тот же браузер в той же сети, например, Wi-Fi с большим количествомпользователи и сеансы перехвата могут также быть недавними (вовремя).Но до тех пор, пока SSL не используется, это намного лучше, чем ничего.В любом случае редко случается, что жертва и угонщик используют одно и то же все .... так что это эффективно снижает шансы на успешную атаку даже без какого-либо SSL!

Оригинальная идея Кевина Скоглунда, если он не заинтересован в защите вашего приложения, посмотрите его безопасный PHPруководство.https://www.lynda.com/PHP-tutorials/Creating-Secure-PHP-Websites/133321-2.html

PS Необходимо использовать несколько других средств защиты (минимум CSRF), чтобы иметь достаточно защищенную точку доступа

Пока: -)

...