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

Просто преобразуя следующее ( "большое 5" ):

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

Вы предотвратите атаки XSS?

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

EDIT Эта страница Детали 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. В сущности, просто избегать этих символов кажется довольно наивным подходом.

Ответ 1

Вы предотвратите атаки XSS?

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

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

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

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

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

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

Ответ 2

OWASP имеет отличный обманщик.

Золотые правила
Стратегии
Etc.

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Ответ 3

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

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