Может ли эта защита XSS с помощью файлов cookie HttpOnly работать?

Question

Я провел некоторые исследования файлов cookie HttpOnly и проблемы, которая существует с возможностью использования XHR-запроса в сочетании с методом TRACE для получения значения cookie, возвращаемого с сервера.

Для безопасного веб-приложения у меня в настоящее время есть следующие настройки:

• Файл cookie сеанса отправляется при входе в систему с установленными безопасными и httpOnly свойствами
• Метод TRACE http отключен для всего домена (возвращается «Метод 405 не разрешен»)

Чтобы избежать подделки межсайтовых запросов, я добавил в формы случайный ключ в скрытом поле. Этот ключ должен быть возвращен в каждом запросе POST, чтобы запрос был принят.

Помимо этого весь HTML по умолчанию экранируется с использованием белого списка для выбора разрешенных тегов и атрибутов, но для иллюстрации, почему этого недостаточно: ранее мы разрешали использовать атрибут style в span (например, для цветного текста ), который можно использовать для передачи JavaScript в Internet Explorer следующим образом:

<span style="width: expression(alert('Example'));"> </span>

И затем к последнему вопросу: может ли кто-нибудь указать на какие-либо недостатки или предположения на возможные недостатки в этой настройке? Или вы используете одинаковые или совершенно разные подходы?

Известные проблемы:

• Не все браузеры поддерживают httpOnly
• Недостаточно фильтрации JS-выражений css, @import (external-style-table) также может работать

Answer 1

Исходя из вашего поста (заголовок немного вводит в заблуждение), я предполагаю, что вы понимаете, что атрибут Httponly предотвращает доступ к cookie-файлам через document.cookie и не делает ничего другого для защиты от других неприятных вещей, которые XSS позволяет включать в себя, выдавая себя за пользователя (т.е. не нужно красть куки и использовать извлеченный токен CSRF), проверять наличие в браузере уязвимых плагинов для установки вредоносных программ, устанавливать регистратор ключей javascript, сканировать внутреннюю сеть и т. д., переписывать страницу и т. д.

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

Неполный список других вещей, которые следует учитывать, пара из которых не имеет прямого отношения к XSS или CSRF:

• Как вы справляетесь с неполным HTML, таким как отсутствующие закрывающие теги?
• Как вы обрабатываете одинарные кавычки, двойные кавычки и обратную косую черту в пользовательском вводе?
• Как вы обрабатываете пользовательский ввод, который выводится в разных контекстах - таких как ссылки URL, значения атрибутов и т. Д.?
• Проверяете ли вы, что ввод действительно соответствует кодировке входного набора символов?
• Вы явно устанавливаете Content-Type в заголовке ответа и в метатеге?
• Для умеренно чувствительных пользовательских страниц, обслуживаемых по HTTP, если есть, установить ли вы соответствующий заголовок Cache-Control?
• Как вы гарантируете пользовательский ввод в песочнице? В частности, если вы разрешаете CSS, как вы гарантируете, что стиль применяется только к ограниченной области и не может изменять другие области?
• Есть ли у вас сторонний javascript, включая рекламу на сайте?
• Защищен ли сессионный cookie от взлома, если это необходимо?
• Санируете ли вы все входные данные, включая заголовки HTTP, которые могут быть изменены пользователем?
• Действительно ли токен CSRF является случайным - если да, как вы генерируете случайный токен? Если нет, то как ты это делаешь?
• Используете ли вы подготовленные операторы и параметры привязки?
• Могут ли пользователи загружать файлы?
• Обслуживаете ли вы загруженный пользователем контент, например изображения и т. Д.? Если да, как вы проверяете содержимое файла (недостаток GIFAR) и обслуживается ли файл с того же домена?
• Предоставляете ли вы доступ к API, и если да, размещен ли он в том же домене? Какое междоменное ограничение у вас есть?

Answer 2

HttpOnly Cookies - это хорошая мера безопасности, но она не предназначена для остановки XSS, а только усложняет для злоумышленников использование уязвимостей xss. Позвольте мне уточнить.

Систему безопасности xsrf на основе токенов можно обойти с помощью XSS, поэтому злоумышленнику не нужно знать cookie-файл для использования уязвимости xss.

Во избежание подделки межсайтовых запросов I добавили случайный ключ в скрытый поле для форм. Этот ключ должен возвращаться в каждом запросе POST для запрос должен быть принят.

Например, используя XSS, злоумышленник может выполнить JavaScript, который может прочитать любую страницу в домене, используя xmlhttprequest. Таким образом, используя xmlhttprequest, злоумышленник может прочитать токен XSRF, а затем использовать его для подделки запроса POST. Это связано с тем, что одним из свойств XSS является то, что он допускает перерыв в Same Origin Policy . Например, Здесь - это реальный эксплойт, который я написал и который делает то, что я только что объяснил.

Лучший способ предотвратить XSS - преобразовать мерзкие символы, такие как <>, в соответствующие им HTML-сущности. В PHP я рекомендую:

$var=htmlspeicalchars($var,ENT_QUOTES);

Это исправит одинарные и двойные кавычки, чтобы остановить Большинство XSS. Даже если результирующий укус находится в HTML-теге. Например, злоумышленник не может использовать этот эксплойт, если вы замените кавычки. Это потому, что злоумышленник должен выйти из кавычек, чтобы выполнить «onload =».

$var="' onload='alert(document.cookie)'";

в этот HTML:

print("<img src='http://HOST/img.php?=".$var."'>");

ОДНАКО , конкретный случай, который вы перечислили с помощью тега <span>, все еще потенциально является проблемой, поскольку злоумышленнику не нужны кавычки! У вас также будет xss уязвимость, если вы поместите внутрь тега <script>. Просто будьте уверены в том, где размещается пользовательский ввод, не существует «поймать все» или «серебряная пуля» для всех уязвимостей.

Атака "XST", использующая метод HTTP "TRACE", на практике не является реалистичной. Причина в том, что злоумышленник не может заставить веб-браузер выполнить http-запрос «TRACE». Злоумышленники могут принудительно вызвать методы «GET» и «POST», используя javascript или тег <img> в случае «GET», но остальная часть заголовка HTTP запрещена. Имейте в виду, что TRACE включен по умолчанию почти во всех системах Apache, если он действительно опасен, он будет удален все вместе. Многие инструменты тестирования безопасности, такие как Nessus, выдают ошибку, если Apache поддерживает TRACE, его также можно легко отключить.