Is it possible to make an XSS attack if you can inject an arbitrary file (any extension, like: .js, .html etc...) in background-image CSS property? If yes, how to do it?
-
Well, CSS is not scripting, so no.– dandavisJan 19, 2018 at 19:28
-
1@dandavis But CSS3 with HTML5 is turing-complete.– forestApr 13, 2018 at 9:16
Add a comment
|
2 Answers
No, that's not possible.
A value to background-image will be rendered as an image. Even an SVG with embedded script code would just be displayed as an image when loaded via background-image. So XSS isn't possible here (the same way an arbitrary value to <img src="..."> can never lead to XSS).
Even if you couldn't just change a background-image value but inject new CSS, you most likely wouldn't be able to get XSS. The techniques to inject script code via CSS expression(...) or url('javascript:...') don't work in modern browsers. In other words, even embedding an entire user-controlled CSS file can lead to severe side-channel leaks but not to plain XSS.
answered Jan 19, 2018 at 14:28
-
1Just want to add, that there was question on SO CSS injection: what's the worst that can happen?, are those links and answer still relevant in 2019? They are from 2009.– jcubicAug 16, 2019 at 11:18
-
@jcubic Good point! The answers over there are outdated and should be updated accordingly.– ArminiusAug 16, 2019 at 11:33
-
I agree that browsers behave this way and do not execute JavaScript in SVG in
<img>or CSSbackground-image. However, can anybody point to any specs that define this, or is this just a common sense to do from browser vendors? I'm also interested in CSSfilter: url("data:image/svg+xml,...")which seems to behave the same way but there, too, I cannot find a spec that requires/promises this behavior. Jun 16, 2021 at 8:13
In extreme cases, it might actually lead to issues, but not necessarily XSS, nor necessarily through the background-image style rule.
Extreme case number 1: Your browser vendor could have a vulnerability in the rendering engine for background-image which if exploited leads to code being executed. This is highly unlikely with modern browsers, but in theory it could be possible.
Extreme case number 2: the site could have nonstandard CSS modifications such as EQCSS that support eval('') or another way to execute Javascript. In this case, you effectively can inject Javascript into the page.
Extreme case number 3: if the site is designed in such a way that arbitrary CSS classes and accompanying rules can be added, it is possible to write clever rules that can leak data based on CSS attribute selectors. For example, screen reader attributes added by certain javascript frameworks containing part or all of certain page content could potentially be combined with images hosted on another site to leak data about the contents of the attributes.
Extreme case number 4: The ::before and ::after CSS rules support the "content" style rule that can be used to insert pretty much arbitrary strings before or after content. there is currently a draft (https://drafts.csswg.org/css-content/) which proposes to extend this content style rule beyond the before/after limitation.
