I'm currently working on a plugin for a CMS which should allow content editors to write inline style tags.

I'm looking for advice / links on how inline styles could be abused.

Part of the reason for the plugin is to allow for a strict content security policy (no inline javascript, but inline styles allowed) - which should mitigate the impact of anything nasty which might be added to the page, but not for older browsers.

Do Microsoft behaviours work for inline styles?

I know that the best solution to make this work would be to validate/sanitize the CSS against a whitelist - but this requires implementing a CSS parser and producing/maintaining a whitelist of properties. Would a blacklist of properties / patterns be feasible? (I'm aware of the relative merits of whitelisting/blacklisting - but it's somewhat skewed here in that there should only be a finite number of attack vectors).


Just to clarify, since the content editors should to some extent be trusted, mitigation of attacks might be a more pragmatic solution than prevention.

Also, just found a specific example in CVE-2011-0232, although I'm more interested in cases where there is not an intrinsic vulnerability in an implementation, but rather a design flaw.

  • 3
    If you allow inline styles, you're also allowing inline JavaScript.
    – Polynomial
    Commented Jun 21, 2013 at 12:54
  • This link describes javascript embedded in a CSS file not javascript in inline styles?
    – symcbean
    Commented Jun 21, 2013 at 14:25
  • You can put them in inline too.
    – Polynomial
    Commented Jun 21, 2013 at 14:36
  • 1
    ...as per conversation below, Javascript in CSS files is there by design in MSIE - where it's described as 'behaviours'. But inline styles are very different. OWASP says the javascript in inline styles WILL execute in MSIE 6 - but when I tried (6.0.2900), it did not.
    – symcbean
    Commented Jun 21, 2013 at 15:25
  • 3
    Here's a demonstration of scriptless-XSS; essentially XSS attacks using only CSS, HTML, SVG, and fonts. channel9.msdn.com/Events/Blue-Hat-Security-Briefings/…
    – Xander
    Commented Jun 21, 2013 at 17:35

1 Answer 1


Regarding JavaScript:

In Internet Explorer and some very old browsers, it's possible to inject JavaScript into stylesheets. Several ways to do this are described in the XSS Filter Evasion Cheat Sheet. The three major issues are:

  1. background-image and similiar: background-image: url('javascript:alert(/XSS/);')
  2. JavaScript expression: width: expression(alert(/XSS/)) - confirmed working in IE 7
  3. Loading .htc files: behavior: url(/evil.htc) - confirmed working in IE 7 through 9

Other issues with CSS:

Basically, every downloadable resource (image, font, ...) can take the visitors network capacity and can be used to run CSRF attacks, spy on visitors or run DDOS attacks on smaller websites.

There might be some ways CSS can be used to crash the browser, take a lot of memory or spin the CPU at 99% for some time. CSS 3 will support many weird things that you want to disallow, including 3d stuff and transitions.

The layout of the website can be altered freely. This includes fun things like exchanging the positions of the search and the password input. It might not be possible using inline styles, just be aware of it.

Regarding blacklisting:

A pattern blacklist is a very bad idea. There is a high number of ways to encode CSS, browsers do it all differently. CSS parsers often follow the principle "garbage in - CSS out". Moreover, it should be noted that CSS parsers generally don't stop on errors, but try to continue parsing the text.

In a short test, I could find a whole bunch of valid background-color definitions: \62ackground-color:, \062ackground-color:, \000062ackground-color:, \62 ackground-color:, bac\k\g\r\o\u\nd-c\o\l\or:.

The pragmatic solution:

  1. Write your own parser. Don't make it full-blown or standard compliant, keep it simple and have a whitelist of properties. There are way more properties that you don't want then that you want. Throw any garbage away.

  2. Keep out browsers that run JavaScript in CSS. You'll have to do some research here, but IE 8 and higher don't support JS expression anymore. The other issues remain.

  • Knowing about the problem of MSIE 'behaviours' I had already tested this on MSIE 6.0.2900 - where any javascript in inline files was studiously ignored, while any javascript in CSS files was parsed and executed. While I've not tested every version of MSIE, it seems that neither has OWASP. Since the content editors can already add img and href tags with impunity (a fairly common feature on CMS) excluding the ability to do this via my plugin seem moot. Good point about the escaping/encoding though.
    – symcbean
    Commented Jun 21, 2013 at 15:21
  • 3
    @symcbean I just tested quickly, width: expression(alert(/XSS/)) works in IE 7. I would also assume that img and href are sanitized in your CMS
    – copy
    Commented Jun 21, 2013 at 15:35
  • Thanks copy - yes, I tried again and got an alert from expression too (I'd only tried url() and behaviour before).
    – symcbean
    Commented Jun 21, 2013 at 15:48
  • 1
    Knowing the right words to type into Googe is a big help too :) - found this: openmya.hacker.jp/hasegawa/security/expression.txt
    – symcbean
    Commented Jun 21, 2013 at 16:03
  • 5
    CSS parsers often follow the principle "garbage in - CSS out". that quote made my day.
    – kasperd
    Commented Jun 29, 2015 at 11:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .