Comments 7
Вообще странно что причиной проблемы тут указывается отсутствие encoding.
Настоящая причина - весь пользовательский ввод, отображающийся в HTML, должен проходить через escape-фунцию, которая заменит <script> на < script >, а коды типа 0x1b на . Если так сделать, то и отсутствие encoding не позволит что-то эксплуатировать.
Просто добавление encoding не закрывает XSS-инъекции, при отсутствии экранирования пользовательского ввода. То есть, слона то вы и не заметили.
Вы много знаете escape-фунций, которые чистят ввод в японской кодировке? С точки зрения стандартной escape-фунции ввод абсолютно чист. В нём символ йены и пара иероглифов.
На SO этот вопрос разобран (к сожалению, ответ не помечен как верный)
OWASP recommends that "[e]xcept for alphanumeric characters, [you should] escape all characters with ASCII values less than 256 with the &#xHH; format (or a named entity if available) to prevent switching out of [an] attribute." So here's a function that does that, with a usage example:
function escapeHTML(unsafe) {
return unsafe.replace(
/[\u0000-\u002F\u003A-\u0040\u005B-\u0060\u007B-\u00FF]/g,
c => '&#' + ('000' + c.charCodeAt(0)).slice(-4) + ';'
)
}
По-моему, все топ фреймворки имеют санитайзеры из коробки, вставкой квери параметров напрямую в джс можно удивить студента на 1 курсе. В реальных же проектах все делается само и никакие экранирования не нужны.
Переменные из юрл отобразятся просто как текст, а не рендер html/js.
Написано косноязычно максимально, конечно...
Проблема-то изначальная в кривой фильтрации пользовательского ввода, а не в кодировке.
Атрибут charset и важность его использования