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

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

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

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

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

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

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

Ответ 1

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

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

1) Используйте httponly cookies.

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

Я действительно считаю SSL дешевым и полным решением. Но до тех пор, пока вы его не найдете или не найдете дополнительные слои, как защитить ваши данные SESSIOn.

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

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

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

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

P.S. Несколько других защит (наименьшее количество CSRF) необходимо использовать, чтобы иметь несколько безопасный AP

Пока: -)