0

I’m usingContent-Security-Policy: default-src 'none'; style-src 'unsafe-inline' and X-Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline' for ɪᴇ. Browsers which don’t support ᴄꜱᴘ can’t use the page.
The allowed html is

p, div, blockquote, summary, details,h1, h2, h3, h4, h5, h6, h7, h8, a, img, b, i, strong, em, tt, code, ins, del, sup, sub, kbd, samp, q, var, s, strike, `table`, thead, tbody, tfoot, tr, td, th, svg, style

The allowed attributes are

abbr, accept, accept-charset, accesskey, action, align, alt, axis, border, cellpadding, cellspacing, char, charoff, charset, checked, cite, clear, cols, colspan, color, compact, coords, datetime, dir, disabled, enctype, for, frame, headers, height, hreflang, hspace, ismap, label, lang, longdesc, maxlength, media, method, multiple, name, nohref, noshade, nowrap, open, prompt, readonly, rel, rev, rows, rowspan, rules, scope, selected, shape, size, span, start, summary, tabindex, target, title, type, usemap, valign, value, vspace, width, itemprop, style

So scripting and external resource loading is disabled. Can I safely allow arbitrary ᴄꜱꜱ in that case (I only care about xss here) ?
I see no reason to do so, but most web sites like GitHub and StackOverFlow strip them (comments are in iframes so<style>elements can’t change stylesheets of the parent).

Of course the best answer would be a small xss proof of concept.

user2284570
  • 2,891
  • 3
  • 26
  • 74
  • Are you aware of SanitizeHelper? http://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html –  Aug 13 '15 at 00:32
  • @Gen : yes, but the real point is to choose if arbitrary css inside comments is safe from xss without user interaction *(xss triggered by simply loading the page containing the comment)*. – user2284570 Aug 13 '15 at 09:44

1 Answers1

1

The following vulnerabilities are present with user controlled CSS and allowing style attributes and style tags:

  1. The use of an inline STYLE="..." parameter attached to HTML tags of any type; attributes specified this way apply to this and nested tags only (and largely defeat the purpose of the entire scheme when it comes to making it easy to alter the appearance of a document),
  2. Introduction of a block of CSS code with ... in any portion of the document. This block may change the default appearance of any tag, or define named rulesets that may be explicitly applied to specific tags with a CLASS="..." parameter,

presents the following risks:

  • The ability to freely position text. If user-controlled stylesheets are permitted on a page, various powerful CSS positioning directives may be invoked to move text outside the bounds of its current container, and mimick trusted UI elements or approximate them very accurately. Some examples of absolute positioning directives include z-index, margin, padding, bottom, left, position, right, top, or text-indent (many of them with sub-variants, such as margin-left).
  • The ability to reuse trusted classes. If user-controlled CLASS="..." attributes are permitted in HTML syntax, the attacker may have luck "borrowing" a class used to render elements of the trusted UI and impersonate them.
  • Script execution via -moz-binding is available on Firefox 2 and 3. The Google Browser Security Handbook doesn't appear to have been updated since Firefox 3. This post indicates this is now fixed so that the XML file has to be readable from your own domain. XBL doesn't seem to be possible in current versions of Firefox.
  • In Internet Explorer 10 and earlier HTML Components allow script execution in CSS.

Remember that allowing users to alter your CSS gives them the ability to freely position text. This would enable a malicious user to mimic trusted UI elements with their CSS code and possibly being able to trick users with the newly rendered page. This very much depends on the functionality present and the intent of the rest of your site. Definitely bear this in mind.

Community
  • 1
  • 1
SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
  • So basically no cross site scripting reasons without user interaction *(excluding getting password or session cookie)*. As I said in the question browsers which don’t support ᴄꜱᴘ can’t post comments, representing <5% of traffic *(excluding ꜰꜰ <13 and ɪᴇ <10)*. Comments are in iframes from a cookie less domain, I’m not aware of a way to change parent’s stylesheets from child` – user2284570 Aug 13 '15 at 11:04
  • How are you stopping browsers that don't support CSP from posting? Bear in mind that it is the user reading the comments that is the potential victim, not the poster. – SilverlightFox Aug 13 '15 at 11:08
  • By checking user agents and executing a piece of JavaScript that is otherwise not executed with ᴄꜱᴘ at log in *(javascript is required for logging in)*. There are also some manual checks as hate speech is illegal. Bear in mind that such web browser *(supporting html5 and not ᴄꜱᴘ)* are often not supported and have known unpatched vulnerabilities allowing remote code execution with raw text. Again this represent less than 5% of the traffic. – user2284570 Aug 13 '15 at 11:20
  • But again, as far I know, you can’t use parent’s stylesheets definitions inside child iframes without javascript. So it is impossible to mimic the site. – user2284570 Aug 13 '15 at 12:37