Некоторые сайты (не будем показывать пальцем) запрещают пользователям использовать .svg-изображения в качестве аватарок.
Этот запрет их авторы обосновывают возможностью организации XSS-атаки через встроенный в SVG джаваскрипт.
Но вроде бы у них нет прав на оправдания. Распарсили бы, да вырезали. Или хотя бы
уведомили пользователя о том, что он
нарушает УК РФ, закон о преднамеренном злоумышленном использовании вычислительных средств:
159.6 УК РФ — Мошенничество в сфере компьютерной информации
272 УК РФ — Неправомерный доступ к компьютерной информации
272.1 УК РФ — Незаконные использование и (или) передача, сбор и (или) хранение компьютерной информации, содержащей персональные данные, а равно создание и (или) обеспечение функционирования информационных ресурсов, предназначенных для ее незаконных хранения и (или) распространения
273 УК РФ — Создание, использование и распространение вредоносных компьютерных программ
== Какая Java-библиотека вырезает JS из SVG? ==
ДипСик: «Для удаления JavaScript из SVG в Java существует специализированная библиотека: SVG Sanitizer от Borewit.
Она делает именно то, что вам нужно: удаляет теги , обработчики событий (например, onclick) и другие опасные элементы, предотвращая XSS-атаки»
«Другие альтернативы: OWASP Java HTML Sanitizer: Хотя он в основном для HTML, эта библиотека также умеет обрабатывать SVG-контент, распознавая его как «foreign content». JSVG: Это больше рендерер. Его можно использовать, если вам не нужен сам SVG как код, а только его отображение, потому что он не поддерживает скрипты и интерактивность по умолчанию.»
== для Rust ==
svg-hush от Claudflare
dom_sanitizer
== Вообще ==
Алиса: «Для полноценной защиты от XSS при загрузке пользовательских SVG дополнительно используют:
отдачу файлов без возможности выполнения как HTML;
Не вставляй SVG инлайн в HTML.
SVG становится частью DOM страницы.
Скрипты из SVG имеют доступ к странице — это классическая XSS‑угроза.
показ SVG через тег <img> (здесь тег = HTML element) вместо инлайн‑вставки
<img src="/uploads/avatar?id=123" />
Браузер загружает SVG как изображение, а не как документ.
В этом случае браузер вообще не выполнит скрипты из SVG .
Контекст изолируется: скрипты внутри SVG не выполняются, даже если они там есть.
Обработчики событий (onclick и т.д.) тоже не работают.
Браузер специально так спроектирован, чтобы картинки не могли исполнять скрипты и влиять на страницу.
с правильным Content-Type: „image/svg+xml”
Content-Type: image/svg+xml
Опасно, когда SVG отдают как „text/html” или „application/xhtml+xml”
Content-Disposition: inline; filename=«example1.svg»
- Content-Disposition: attachment; filename=«example2.svg»
(браузер не будет исполнять скрипты из SVG при предпросмотре, а файл сохранится на диск)
Content-Security-Policy (CSP), ограничивающий выполнение скриптов;
В Apache для установки заголовков есть mod_headers
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"
Это хорошо для статики, где JS не нужен вообще.
хранение загруженных файлов так, чтобы их нельзя было открыть напрямую в браузере как документ
(например, через скачивание или проксирование).
Иногда делают отдельный домен/поддомен только для пользовательского контента: usercontent.example.com
отключать выполнение скриптов (CSP);
не давать доступ к кукам основного сайта;
использовать SameSite;
использовать X-Content-Type-Options: nosniff, чтобы браузер не пытался «угадать» тип контента;
и прочие меры.
»
CVE-2017-8778 = нашли XSS через SVG в GitLab (q) Квен