|
Top-level
 @vitonsky ну ты же строки из объекта объединяет с тегами и получаешь HTML. Ну базовый пример: { type: 'link', url: "javascript:alert(password)" … } Ну или { type: 'image', alt: 'text" onerror="javascript:alert(password)' … } В итоге ровно такие же защиты надо делать как в XSS. А дальше более хитрые атаки на стыке багов реализации Markdown-парсера и т. п. 7 comments
@vitonsky объясни подробнее, как ты будешь генерировать HTML, если тебе не нужно экранировать закрывающуюся кавычку ", чтобы onerror из значения не стал отдельным атрибутом? @sitnik_ru вот так: ``` Точно так как генерируем обычные страницы сайтов @vitonsky ну у тебя просто экранирование делает `innerText =`. Против такого есть красивые атаки с javascript: на ссылках, где экранирование не спасёт. Плюс раз ты тут собираешь HTML, то тут можно делать DOM clobbering атаку. @sitnik_ru ты правильно понял про то, что я предлагаю делегировать сборку HTML - HTML сериализатору. Если мы не доверяем HTML сериализатору (что нормально, но только если у проекта очень много денег), то мы рассматриваем как вектор угроз, возможность XSS от любого комментария на сайте по вине браузера. Я не знаю как можно защищаться в такой ситуации, но точно не санитайзингом HTML. Если мы учитываем что есть дыры аж в сериализаторе, то санитайзинг только добавит возможные комбинации атаки. @vitonsky как именно санитайзинг добавит векторы атаки? Какая была атака именно на санитайзер? @sitnik_ru добавит неожиданные изменения, которые сработают вместе с багом сериализатора. Если ты рассматриваешь возможность багов в сериализаторе, то такие баги могут быть и в санитайзере |
Gregory's Server
@sitnik_ru Судя по `onerror` ты неправильно понял идею. В этих объектах есть только то, что туда положили руками. Свойство onerror не существует, как и других HTML аттрибутов. Поэтому валидацию написать нужно, но только на том же уровне как для обработки форм - проверить URL, найти маты в тексте и всё. Всё остальное будет вставлено как текст