Комментарии 3
Вообще странно что причиной проблемы тут указывается отсутствие 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) + ';'
)
}
Атрибут charset и важность его использования