Как стать автором
Обновить

Комментарии 3

Вообще странно что причиной проблемы тут указывается отсутствие encoding.
Настоящая причина - весь пользовательский ввод, отображающийся в HTML, должен проходить через escape-фунцию, которая заменит <script> на &lt; script &gt;, а коды типа 0x1b на &#27;. Если так сделать, то и отсутствие 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) + ';'
  )
}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории