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

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

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

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

• Как вы справляетесь с неполным html, например, с отсутствующими закрывающими тегами?
• Как вы обрабатываете одинарную кавычку, двойную кавычку и обратную косую черту в пользовательском вводе?
• How do you handle user input that is output in different contexts - such as in url links, attribute values, etc.?
• Do you check that input actually matches input charset encoding?
• Вы явно устанавливаете Content-Type в заголовке ответа и в метатеге?
• Для умеренно чувствительных пользовательских страниц, обслуживаемых через HTTP, если таковые имеются, вы устанавливаете соответствующий заголовок Cache-Control?
• Как вы гарантируете, что пользовательский ввод изолирован? В частности, если вы разрешаете CSS, как вы гарантируете, что стиль применяется только к ограниченной области и не может изменять другие области?
• У вас есть сторонний javascript, включая рекламу на сайте?
• Защищен ли файл cookie сеанса от несанкционированного доступа, если он должен быть защищен?
• Вы очищаете все входные данные, включая заголовки HTTP, которые могут быть изменены пользователем?
• Является ли токен CSRF действительно случайным? Если да, то как вы генерируете случайный токен? Если нет, то как вы его строите?
• Используете ли вы подготовленные операторы и параметры привязки?
• Могут ли пользователи загружать файлы?
• Обслуживаете ли вы загружаемый пользователями контент, такой как изображения и т. д.? Если да, то как вы проверяете содержимое файла (ошибка GIFAR) и обслуживается ли файл из того же домена?
• Предоставляете ли вы доступ к API, и если да, то размещается ли он в том же домене? Какое междоменное ограничение у вас есть?

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

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

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

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

Лучший способ предотвратить 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, его также можно легко отключить.