Кража идентификаторов куки - контрмеры

Question

Легко украсть куки с идентификатором сессии с помощью функций javascript, установленных другими пользователями на доверенных сайтах. Каковы возможные контрмеры для такого рода атак?

Отклонить все сценарии JavaScript на стороне клиента, вероятно, сложно, потому что почти все сайты используют js. Каковы возможные контрмеры на стороне сервера? Можно ли включить хэш IP-адреса клиента в значение идентификатора сеанса, чтобы предотвратить использование действительного идентификатора сеанса с другого хоста? Имеет ли этот подход смысл?

В одном из ресурсов, упомянутых в ваших ценных ответах, предлагается решение, в котором идентификатор сеанса изменяется после каждого запроса. Такая функция уже поддерживается серверами приложений / фреймворками? В частности, как насчет Django / Python?

Answer 1

Действительно неудобно делать IP для сопоставления сеанса, потому что у вас нет гарантий, что люди не используют прокси, и эти прокси могут легко изменить IP.

Лучшее, что вы можете сделать, это использоватьSSL, и сделайте ваши куки только для HTTP .

Answer 2

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

Я не думаю, что вы можете получить доступ к файлам cookie с других доменов.

Answer 3

Это называется XSS . Лучшее решение для предотвращения внедрения кода JavaScript на клиентах в первую очередь.

Интересным решением является обеспечение аутентификации на основе токенов для каждой пользовательской операции. Посетите страницу OWASP CSRF для получения дополнительной информации.

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

Answer 4

• Устанавливайте только тот Javascript, которому вы доверяете. Проверьте исходный код (возможно, используйте какой-нибудь сканер XSS), если вы не уверены в коде.

• отфильтруйте ваш javascript (из ввода), используя, например, этот простой фрагмент javascript:

  функция sanitize (html) {
  `возвращаемая строка (html)
  .replace (/ & (?! \ w +;) / g, '&')
  .Надеть (/ .replace (/> / g, '>')
  .replace (/ "/ g, '"');
  }

Вы ДОЛЖНЫ также иметь хорошую фильтрацию (входную) на стороне сервера. Например, PHP имеет расширение фильтра .

• Использовать файлы cookie только для http .
• Использовать SSL.

Answer 5

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

Это может блокировать перехват сеанса в некоторых ситуациях, но в ситуации, когда компьютер-злоумышленник и компьютер-жертва находятся в одной сети, он ничего не сделает, поскольку соединение происходит с одного IP-адреса.

Каковы возможные контрмеры на стороне сервера?

Использование SSL поможет предотвратить перехват сеанса, если человек подключен к публичной сети.

Вы можете просмотреть свой код и убедиться, что в вашем коде нет XSS недостатка.

Вы также можете убедиться, что файл cookie, используемый для хранения сеанса, имеет флаг HTTP Only .