Мы разрешаем использование @import с помощью специального редактора CSS в нашей CMS, но я хочу знать, открыли ли мы себя потенциальными рисками для безопасности, выполнив это, можно ли его использовать для XSS?Возможно ли XSS через @import, и если да, то как? Существуют ли способы защиты от этого?
Если да, то как это будет работать, и дальше, как мы будем защищаться от такой атаки?
FYI, мы фактически не оставляют @import заявления в пользовательском CSS, когда он служил, они раздели через preg_replace_callback() и заменяли их фактического целевого контента через file_get_contents(). Это значит, что CSS все еще можно кэшировать, а не блокировать загрузку страниц, но, возможно, дает нам возможность фильтровать используемые URL или даже возвращаемый контент.
EDIT:
После быстрого образования от @duskwuff это очевидно есть много потенциальных проблем с предлагая услуги, но это похоже на подобный вопрос и ответ (здесь: https://stackoverflow.com/a/5209050/1058733) показывает, что можно сделать довольно безопасно, используя HTMLPurifier + CSSTidy для санирования CSS-ввода, который идеально поместился бы в нашем скрипте после file_get_contents() и до кэширования, а также во время процесса сохранения объектов для хорошей оценки.
ничего себе! У меня нет ответа на это ... но если вы так беспокоитесь об этом, вы должны сначала спросить ... – Leonardo
Для чего это стоит, кто-то может просто поставить фактический оператор '@ import' в файл передается через HTTP. Вы можете заменить '@ import' на что-то еще злонамеренное. – Brad
@Leonardo, @Brad FWIW, я упоминал в FYI, что у нас есть возможность фильтровать/проверять возвращаемый код. Также не то, что это защита, так как они не являются моим выбором тестов, но вы можете сделать то же самое в Wordpress через свой собственный редактор css, так что это не так, как будто я изобретаю новые способы закрутить себя. На самом деле, наша возможность фильтровать и проверять из-за 'file_get_contents()' довольно уникальна. – oucil