Email or username:

Password:

Forgot your password?
Top-level
Андрей Ситник

@vitonsky но DOMPurify ровно это и делает, парсит DOM и вырезает всё ненужное по белому списку.

XSS-атаки в основном строятся на том, что парсер начнёт сбоить и не увидит тега или аргумента.

Все эти же атаки протащат эти невидимы аргументы до Markdown-генератора и попадут в HTML выход из него.

9 comments
Robert Vitonsky

@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-парсера и т. п.

Robert Vitonsky

@sitnik_ru Судя по `onerror` ты неправильно понял идею. В этих объектах есть только то, что туда положили руками. Свойство onerror не существует, как и других HTML аттрибутов. Поэтому валидацию написать нужно, но только на том же уровне как для обработки форм - проверить URL, найти маты в тексте и всё. Всё остальное будет вставлено как текст

Андрей Ситник

@vitonsky объясни подробнее, как ты будешь генерировать HTML, если тебе не нужно экранировать закрывающуюся кавычку ", чтобы onerror из значения не стал отдельным атрибутом?

Robert Vitonsky replied to Андрей

@sitnik_ru вот так:

```
const p = document.createElement('p');
p.innerText = `Text with "onerror='alert(123)'"`;
document.body.appendChild(p);
```

Точно так как генерируем обычные страницы сайтов

Андрей Ситник replied to Robert

@vitonsky ну у тебя просто экранирование делает `innerText =`.

Против такого есть красивые атаки с javascript: на ссылках, где экранирование не спасёт. Плюс раз ты тут собираешь HTML, то тут можно делать DOM clobbering атаку.

Robert Vitonsky replied to Андрей

@sitnik_ru ты правильно понял про то, что я предлагаю делегировать сборку HTML - HTML сериализатору.

Если мы не доверяем HTML сериализатору (что нормально, но только если у проекта очень много денег), то мы рассматриваем как вектор угроз, возможность XSS от любого комментария на сайте по вине браузера.

Я не знаю как можно защищаться в такой ситуации, но точно не санитайзингом HTML. Если мы учитываем что есть дыры аж в сериализаторе, то санитайзинг только добавит возможные комбинации атаки.

Андрей Ситник replied to Robert

@vitonsky как именно санитайзинг добавит векторы атаки? Какая была атака именно на санитайзер?

Robert Vitonsky replied to Андрей

@sitnik_ru добавит неожиданные изменения, которые сработают вместе с багом сериализатора.

Если ты рассматриваешь возможность багов в сериализаторе, то такие баги могут быть и в санитайзере

Go Up