Смягчение атаки «firesheep» в прикладном уровне?

Какие методики рекомендуют для смягчения метода «Firesheep» для веб-приложений?Смягчение атаки «firesheep» в прикладном уровне?

Мы подумали об этом и с точки зрения удобства использования, кроме шифрования всего трафика на сайт, смягчение атаки может быть проблемой для веб-разработчиков.

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

Есть ли у кого-нибудь другие предложения по смягчению этого вектора атаки при сохранении полезного уровня юзабилити?

источник

2010-10-25 pobk

Кстати, если один из модераторов хочет добавить к нему тег 'firesheep', потому что это весьма актуально. – pobk

Один x-ref для [Firesheep] (http://gizmodose.com/firesheep-firefox-plugin-allows-users-to-steal-passwords-hack-facebook-accounts.html). –

Возможный дубликат [Является ли HTTPS единственной защитой от захвата сеанса в открытой сети?] (Http://stackoverflow.com/questions/4017344/is-https-the-only-defense-against-session-hijacking-in- a-open-network) – rook

Firesheep is ничего нового. Удержание захвата продолжается уже более двух десятилетий. Вам не нужно «шифровать» ваш файл cookie, который обрабатывается вашим транспортным уровнем. Файлы cookie всегда должны быть cryptographic nonce.

Обычно хакеры просто устанавливают свой собственный файл cookie, введя его в адресную строку javascript:document.cookie='SOME_COOKIE', FireSheep предназначен для сценаристов, которые боятся 1 строки JavaScript. Но это действительно не облегчает выполнение этой атаки.

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

1) Использовать httponly cookies. (Делает это так, что JavaScript не может получить доступ к document.cookie, но вы все еще можете делать сеанс с помощью xss)

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

3) Сканирование веб-приложение для XSS с помощью Sitewatch(free) или wapiti (open source)

Также не стоит забывать о CSRF! (Какой пожарный реестр не адресуется)

источник

2010-10-25 18:04:36 rook

Да. Это ничего нового. «Новый», как вы говорите, - это то, что дети из skript могут войти в действие. Вот почему это потенциально такая проблема. Я хочу защитить своих пользователей. – pobk

@pobk Вы должны включить эти функции безопасности перед Firesheep. Этот инструмент ничего не меняет. – rook

Наше приложение настолько же безопасно, насколько мы можем это сделать (оно соответствует PCI DSS) ... Мы просто смотрим дальше на защиту наших пользователей. – pobk

Кто-нибудь попытался воспользоваться «Хранилищем веб-страниц» в HTML 5 для хранения общего ключа (переданного во время SSL-зашифрованных ответов во время аутентификации), который используется javascript для изменения файла cookie сеанса со временем?

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

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

источник

2010-10-26 20:10:40 arscan

Затем злоумышленнику нужно вставить некоторый javascript в один из ответов HTTP, который показывает общий ключ. – caf

Ну, я нашел интересную статью о GitHub, которая описывает метод смягчения атаки на огневую атаку.

https://github.com/blog/737-sidejack-prevention

источник

2010-11-04 22:32:44 pobk

-1

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

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

источник

2010-11-14 14:31:39

Боюсь, что это не сработает. Удаленный IP-адрес будет разделяться в случаях, когда firesheep будет преобладать – pobk

Даже если вы также сохраняете значение заголовка X-Forwarded-For HTTP вместе с IP-адресом? –

Смягчение атаки «firesheep» в прикладном уровне?

ответ

Смежные вопросы