Что думает системный администратор о смягчении атаки «firesheep» на серверы, которыми он управляет?
Firesheep - это новое расширение для firefox, которое позволяет любому, кто установил его, участвовать в сеансе сайджека, который он может обнаружить. Он обнаруживает, анализируя пакеты в сети и ища файлы cookie сеанса с известных сайтов. Относительно легко написать плагины для расширения для прослушивания файлов cookie с дополнительных сайтов.
С точки зрения системы / сети мы обсудили возможность шифрования всего сайта, но это создает дополнительную нагрузку на серверы и винты с индексацией сайта, активами и общей производительностью.
Один из вариантов, который мы исследовали, - использовать наши брандмауэры для разгрузки SSL, но, как я упоминал ранее, для этого потребуется зашифровать весь сайт.
Что вы думаете о защите от этого вектора атаки?
Я задал аналогичный вопрос о StackOverflow, однако было бы интересно узнать, что думают системные инженеры.
Пока данные сеанса передаются между сервером и клиентом в открытом виде, вы уязвимы для какого-то взлома в незащищенных сетях. Отсутствие состояния HTTP в значительной степени гарантирует, что любой, у кого есть данные вашего сеанса, может выдать себя серверу за вас.
Так что делать? Вам необходимо безопасно передавать информацию о сеансе от сервера к клиенту, чтобы перехватчики не могли ее перехватить. Самый надежный и простой способ - сделать ваш сайт полностью HTTPS, то есть без незашифрованного трафика. Это очень легко реализовать, так как вам не нужно изменять приложение, а только серверы. Обратной стороной является то, что это увеличивает нагрузку на ваши серверы.
Если это не вариант, вам нужно каким-то образом скрыть данные сеанса, которые сервер передает клиенту. А клиенту нужен сценарий для «деобфускации» данных сеанса, чтобы передать их обратно на сервер при следующем запросе. Да, это «безопасность через неизвестность», и все знают, что это не работает. За исключением тех случаев, когда это происходит. Пока ваш сайт не является высокоэффективной целью, сокрытие данных сеанса предотвратит захват ваших пользователей случайными пользователями этой «огненной овцы». Только когда / если ваш сайт попадет в поле зрения кого-то, кто желает реконструировать вашу обфускацию, этот метод смягчения последствий не сработает.
Зачем вам нужно шифровать весь сайт?
Просто настройте поддомен, login.yourcompany.com, зашифруйте этот бит, установите безопасный флаг для cookie (предотвращает его передачу по чему-либо, кроме безопасного канала) и настройте сервер входа с внутренним доверием (однако вы хотите сделать это зависит от вас) остальной части приложения.
См. Предложение / код Бена Адиды для "SessionLock Lite". По общему признанию, он не предлагает защиты от активных атак или подслушивания и уязвим для краткосрочных атак. Но это может помочь в ближайшее время, пока вы разрабатываете настоящее решение SSL: http://benlog.com/articles/2010/10/25/keep-your-hands-off-my-session-cookies/
Учетные данные всегда должны быть зашифрованы и никогда не передаваться в открытом виде. Что в этом такого сложного?
С точки зрения местного администратора:
Чтобы firesheep работал в проводной сети, злоумышленник должен выполнить отравление ARP на вашей инфраструктуре коммутатора. Трафик к другим компьютерам и с других компьютеров никогда не достигнет ПК злоумышленников, если они сначала не воспользуются сетью.
С точки зрения поставщика услуг:
Я бы хотел, чтобы мой сайт или, по крайней мере, любой трафик аутентификации или файлов cookie был зашифрован SSL.
С точки зрения конечного пользователя:
Я бы хотел, чтобы провайдер обеспечивал безопасность моего сеанса, чтобы мне даже не приходилось думать о вводе «https: //». Это должно заставить меня быть в безопасности.