Is XSS possible via an @import, and if so how? Are there ways to protect against it?
We allow the use of @import via a custom CSS editor in our CMS, but I want to know if we've opened ourselves up to potential security risks by doing that, can it be used to XSS?
If so, how would that work, and further, how do we go about protecting ourselves against such an attack?
FYI, we don't actually leave the @import statements in the custom CSS when it's served, they are stripped out via preg_replace_callback() and replaced with their actual target content via file_get_contents(). This is so the CSS can still be cached and not block page loading, but potentially gives us an opportunity to filter the URL's that are used, or even the content that's returned.
After the quick education from @duskwuff it's obvious there are lots of potential problems with offering the service, but it looks like a similar question and answer (here: https://stackoverflow.com/a/5209050/1058733) shows that it can be done pretty safely using HTMLPurifier + CSSTidy to sanitize CSS input which would fit perfectly in our script after file_get_contents() and before caching, and additionally during the save object process for good measure.
- Dynamic properties (expression() - in Internet Explorer 7 and earlier)
- DHTML behaviors (behavior - in Internet Explorer)
- XBL bindings (in Gecko-based browsers)
Depending on the nature of your site, unrestricted CSS may also be used to steal passwords from your users by reformatting page content to appear like a password prompt, or to deny access to the site by reformatting or hiding vital components of the page (e.g, hiding a "log in" link).
Do not allow users to enter CSS that will be used on your site unless you're prepared to fully parse it and validate it against a whitelist of approved properties and selectors.