Предотвращает ли кодировка HTML эксплойты безопасности XSS? - PullRequest
Новая
       39

Предотвращает ли кодировка HTML эксплойты безопасности XSS?

12 голосов
/ 25 февраля 2010

Простым преобразованием следующего («большая 5»): 

& -> &
< -> &lt;
> -> &gt;
" -> &#034;
' -> &#039;

Будете ли вы предотвращать атаки XSS?

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

РЕДАКТИРОВАТЬ Эта страница подробности it does not prevent more elaborate injections, does not help with "out of range characters = question marks" when outputting Strings to Writers with single byte encodings, nor prevents character reinterpretation when user switches browser encoding over displayed page. По сути, просто избежать этих символов представляется довольно наивным подходом.

Ответы [ 3 ]

9 голосов
/ 25 февраля 2010

Будете ли вы предотвращать атаки XSS?

Если вы сделаете это, избегая в нужное время (*), тогда да, вы предотвратите HTML-инъекцию. Это наиболее распространенная форма атаки XSS. Это не просто вопрос безопасности, вам все равно нужно делать экранирование, чтобы строки с этими символами в любом случае отображались правильно. Вопрос безопасности является подмножеством проблемы правильности.

Я думаю, вам также нужно занести белый список на уровень персонажа, чтобы предотвратить определенные атаки

Нет. Экранирование HTML будет отображать каждую из этих атак в виде неактивного простого текста на странице, что вам и нужно. Спектр атак на эту страницу демонстрирует различные способы выполнения HTML-инъекций, которые могут обойти «глупые» фильтры XSS, которые развертывают некоторые серверы, чтобы попытаться предотвратить обычные HTML-инъекции. Это демонстрирует, что «фильтры XSS» по своей природе утечки и неэффективны.

Существуют другие формы атаки XSS, которые могут или не могут повлиять на вас, например, плохие схемы для пользовательских URI (javascript: и др.), Внедрение кода в данные, отраженные в блоке JavaScript (где вам нужен JSON -стиль экранирования) или в таблицы стилей или заголовки ответа HTTP (опять же, вам всегда нужна соответствующая форма кодирования при перетаскивании текста в другой контекст; вы всегда должны быть подозрительны, если вы видите что-либо с неэкранированной интерполяцией, как PHP "string $var string").

Затем есть обработка загрузки файлов, политика происхождения Flash, слишком длинные последовательности UTF-8 в устаревших браузерах и проблемы генерации контента на уровне приложений; все это может привести к межсайтовому скриптингу. Но HTML-внедрение - это главное, с чем сталкивается каждое веб-приложение, и большинство PHP-приложений сегодня ошибаются.

(*: это при вставке текстового содержимого в HTML, и ни в коем случае. Не отправляйте HTML-экранированные данные отправки формы в $_POST / $_GET в начале вашего скрипта; это распространенная ошибка. ошибочность.)

5 голосов
/ 29 апреля 2013

У OWASP отличный шпаргалка.

  1. Золотые правила
  2. Стратегии
  3. 1008 * Etc. *

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md

4 голосов
/ 25 февраля 2010

Контрмеры зависят от контекста, в который вставляются данные. Если вы вставляете данные в HTML, замена метасимвола HTML на escape-последовательности (т.е. ссылки на символы) предотвращает вставку HTML-кода.

Но если вы находитесь в другом контексте (например, значение атрибута HTML, которое интерпретируется как URL), у вас есть дополнительные метасимволы с различными escape-последовательностями, с которыми вам приходится иметь дело.

...