Последствия безопасности, позволяющие пользователям создавать собственные SVG-файлы

Я планирую, чтобы пользователи сайта загружали свои собственные документы SVG и отображали их с помощью inkscape или svg2pdf . Пользователи будут либо неаутентифицированы, либо пройдут тривиальный процесс регистрации, поэтому я ожидаю некоторые попытки взлома. Поэтому я должен оценить любые указатели на то, какую фильтрацию я могу сделать, чтобы свести к минимуму угрозы безопасности.

  • Inkscape, похоже, не беспокоит теги JavaScript onload и с радостью отображает контент без каких-либо неприятных последствий (при этом я не могу заставить Firefox 10 опрокинуть окно предупреждения или использовать этот подход).
  • Я обеспокоен тем, что <image xlink:href /> может ссылаться на огромное или искаженное растровое изображение с использованием внешнего URI, что теоретически может привести к сбою службы. Есть ли простой способ переместить документ XML для их фильтрации? Конечно, я могу сделать это с помощью XMLReader, но задаюсь вопросом, может ли я иметь дело с вещами вроде onload для 'onload' (хотя Firefox просто отклонил его как недопустимый, поэтому, возможно, это бесполезное беспокойство). Sidenode: изображения сами по себе приемлемы, но я думаю, что я либо потребовал бы, чтобы они были либо встроенными data: либо допустимыми URI-адресами для белых списков с ограничениями размера файла.
  • Существуют ли какие-либо директивы SVG (в частности, текст рендеринга), которые могут включать текстовое содержимое системных файлов, например /etc/passwd т. Д.?
  • Один из подходов, который я мог бы принять, – это проверка на соответствие спецификации SVG. Это вопрос другого вопроса, который я задал здесь .

Я использую PHP 5.2 с XMLReader и XMLWriter, хотя другие поточные системы PHP будут приемлемыми. Системы – OS X 10.6.8 для dev, а LAMP – для производства.

Существуют ли какие-либо директивы SVG (в частности, текст рендеринга), которые могут включать текстовое содержимое системных файлов, например / etc / passwd и т. Д.?

Вам необходимо убедиться, что атаки на XXE не возможны для конкретной реализации, см. Здесь .