6

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?

Bob
  • 63
  • 1
  • 4

2 Answers2

7

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.

Arminius
  • 43,922
  • 13
  • 140
  • 136
  • 1
    Just want to add, that there was question on SO [CSS injection: what's the worst that can happen?](https://stackoverflow.com/q/718611/387194), are those links and answer still relevant in 2019? They are from 2009. – jcubic Aug 16 '19 at 11:18
  • @jcubic Good point! The answers over there are outdated and should be updated accordingly. – Arminius Aug 16 '19 at 11:33
  • I agree that browsers *behave* this way and do not execute JavaScript in SVG in `` or CSS `background-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 CSS `filter: 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. – Mikko Rantalainen Jun 16 '21 at 08:13
0

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.

Nzall
  • 7,313
  • 6
  • 29
  • 45