38

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).

Update

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.

symcbean
  • 18,278
  • 39
  • 73
  • 3
    If you allow inline styles, you're [also allowing inline JavaScript](http://www.jr.pl/www.quirksmode.org/css/javascript.html). – Polynomial Jun 21 '13 at 12:54
  • This link describes javascript embedded in a CSS *file* not javascript in inline styles? – symcbean Jun 21 '13 at 14:25
  • You can put them in inline too. – Polynomial Jun 21 '13 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 Jun 21 '13 at 15:25
  • 3
    Here's a demonstration of scriptless-XSS; essentially XSS attacks using only CSS, HTML, SVG, and fonts. http://channel9.msdn.com/Events/Blue-Hat-Security-Briefings/BlueHat-Security-Briefings-Fall-2012-Sessions/BH1203 – Xander Jun 21 '13 at 17:35

1 Answers1

28

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.

copy
  • 1,939
  • 1
  • 16
  • 13
  • 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 Jun 21 '13 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 Jun 21 '13 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 Jun 21 '13 at 15:48
  • 1
    Knowing the right words to type into Googe is a big help too :) - found this: http://openmya.hacker.jp/hasegawa/security/expression.txt – symcbean Jun 21 '13 at 16:03
  • I also checked `behavior` on inline style and got it working in IE 7, using this htc: ``. This makes modern IE unsafe, too – copy Jun 21 '13 at 17:22
  • 5
    `CSS parsers often follow the principle "garbage in - CSS out".` that quote made my day. – kasperd Jun 29 '15 at 11:03
  • Real CSS parser have *forward compatible parsing* defined in the specs. To test if your browser actually follows the spec, see if you get all green in this test: http://www.hixie.ch/tests/evil/css/css21/tests/t0402-c71-fwd-parsing-00-f.htm – Mikko Rantalainen Jun 15 '21 at 08:12