Gregory's Server@sitnik_ru для решения каких задач люди используют эти библиотеки?
Рендерить недоверенный HTML в браузере клиентов - это выстрел в голову, как вы его не очищайте
|
14 comments
@sitnik_ru парсить HTML и трансформировать в свой шаблон. Телеграм делает это идеально, потому что пользуется аутсорсингом для написания селекторов для всех крупных сайтов, если у проекта уровень попроще, можно обойтись алгоритмами выявления контента.  @vitonsky что-то я не понимаю. Вот есть пост ЖЖ — там идут картинки, выделение жирным, ссылки, видео, списки, абзацы, MathML-формулы (как пример максимальной сложности). Речь не про OG-карточку с текстом без форматирования, а про текст со сложным форматированием. Как ты видишь «трансформировать в свой шаблон», чтобы логика отличалась от «очистить от опасных тегов и аттрибутов»? @sitnik_ru распарсить HTML AST любым DOM парсером, взять все как текст с фичами уровня markdown, вставить в свой шаблон. Грубый пример - превратить весь текст в обычный текст (без форматирования и стилей), из картинок брать только урлы и тайтлы, из ссылок только текст, урл и тайтл. Принципиальное отличие в том, что мы берем данные (а не разметку) и потом их как-то форматируем. От исходного HTML не берем ничего @vitonsky но DOMPurify ровно это и делает, парсит DOM и вырезает всё ненужное по белому списку. XSS-атаки в основном строятся на том, что парсер начнёт сбоить и не увидит тега или аргумента. Все эти же атаки протащат эти невидимы аргументы до Markdown-генератора и попадут в HTML выход из него. @sitnik_ru как именно они протаскивают, если мы не используем оригинальный HTML, а только текст нод? Из `<a href="/foo">Hello</a>` мы имеем только данные `{type: 'link', url: '/foo', text: 'Hello'}`, который потом превращаем во что-то @vitonsky ну ты же строки из объекта объединяет с тегами и получаешь HTML. Ну базовый пример: { type: 'link', url: "javascript:alert(password)" … } Ну или { type: 'image', alt: 'text" onerror="javascript:alert(password)' … } В итоге ровно такие же защиты надо делать как в XSS. А дальше более хитрые атаки на стыке багов реализации Markdown-парсера и т. п. @sitnik_ru Судя по `onerror` ты неправильно понял идею. В этих объектах есть только то, что туда положили руками. Свойство onerror не существует, как и других HTML аттрибутов. Поэтому валидацию написать нужно, но только на том же уровне как для обработки форм - проверить URL, найти маты в тексте и всё. Всё остальное будет вставлено как текст @vitonsky объясни подробнее, как ты будешь генерировать HTML, если тебе не нужно экранировать закрывающуюся кавычку ", чтобы onerror из значения не стал отдельным атрибутом? @sitnik_ru вот так: ``` Точно так как генерируем обычные страницы сайтов @vitonsky ну у тебя просто экранирование делает `innerText =`. Против такого есть красивые атаки с javascript: на ссылках, где экранирование не спасёт. Плюс раз ты тут собираешь HTML, то тут можно делать DOM clobbering атаку. @sitnik_ru ты правильно понял про то, что я предлагаю делегировать сборку HTML - HTML сериализатору. Если мы не доверяем HTML сериализатору (что нормально, но только если у проекта очень много денег), то мы рассматриваем как вектор угроз, возможность XSS от любого комментария на сайте по вине браузера. Я не знаю как можно защищаться в такой ситуации, но точно не санитайзингом HTML. Если мы учитываем что есть дыры аж в сериализаторе, то санитайзинг только добавит возможные комбинации атаки. @vitonsky как именно санитайзинг добавит векторы атаки? Какая была атака именно на санитайзер? @sitnik_ru добавит неожиданные изменения, которые сработают вместе с багом сериализатора. Если ты рассматриваешь возможность багов в сериализаторе, то такие баги могут быть и в санитайзере |
@vitonsky ну а как ещё RSS-читалку, например, сделать?