3 ms·

It's also a security issue and you should set up CSP to prohibit online CSS. See a random Google search result http://dontkry.com/posts/code/disable-inline-styl

It's also a security issue and you should set up CSP to prohibit online CSS. See a random Google search result http://dontkry.com/posts/code/disable-inline-styles.html http://dontkry.com/posts/code/disable-inline-styles.html or like I did read "The Tangled Web" Edit: that's obviously a non-issue in this particular case since everything is static. But as a best practice this needs to be considered and inline CSS doesn't make you a boss.

ejcx 10y ago
You are completely wrong. Inline styles on a static page is not a security issue. If you read that blog post you linked to, you would know this. CSP will do absolutely nothing for a single static html page containing all assets it needs as inline.
- ajmurmann 10y ago
  Yes, of course that's correct. And I wouldn't have felt that pointing out that it can be is necessary if he hadn't written that he is inlining it "like a boss". That makes it sound like it's some awesome best practices we all should be adhering to.
bigiain 10y ago
So if I'm reading that page correctly, the basic gist of the claim is: If we only do a half assed job of sanitising user input by attempting to blacklist whatever javascript we can think of, we'll still be open to XSS attacks from people smarter than us who put css into our user supplied data, so the answer is to prohibit inline CSS - not to properly sanitise user supplied data. I think there are better pieces of security advice around than that...
- ajmurmann 10y ago
  Why not do both and be safe if your sensitization has a bug?
  - always_good 10y ago
    I still don't understand what it accomplishes. Why does inline matter? The vulnerability means they can inject arbitrary markup including <link> or <script> that load offsite sources. You can use CSP to whitelist allowed offsite domains. But if you're not careful, "you never know" and "you might as well" are more likely to waste your time chasing low value things. For instance, inline CSS is valuable as an intermittent developer convenience, and disabling it takes that away while protecting your from an unlikely event. Also, you generally should be escaping-by-default and not sanitizing. A templating system should escape by default and make it obvious when you opt out.
    - Annatar 10y ago
      I still don't understand what it accomplishes. Why does inline matter? In the worst case scenario, where the server doesn't have all the blocks of the file cached in random acces memory, the server can fetch the single, inlined file with fewer input operations per second from local storage far faster than one's web browser can fetch multiple files over the network. This means that latency is lowered, and thus delivery time is accelerated.
      - always_good 10y ago
        Right, I meant in regards to this comment chain where "inline CSS is bad if you have an XSS vulnerability."
RubyPinch 10y ago
so, hoster doesn't escape anything the users provide, and is more concerned about CSS instead of JS? And then their site broke as soon as I clicked a link

ejcx 10y ago

You are completely wrong. Inline styles on a static page is not a security issue. If you read that blog post you linked to, you would know this. CSP will do absolutely nothing for a single static html page containing all assets it needs as inline.

ajmurmann 10y ago
Yes, of course that's correct. And I wouldn't have felt that pointing out that it can be is necessary if he hadn't written that he is inlining it "like a boss". That makes it sound like it's some awesome best practices we all should be adhering to.

bigiain 10y ago

So if I'm reading that page correctly, the basic gist of the claim is: If we only do a half assed job of sanitising user input by attempting to blacklist whatever javascript we can think of, we'll still be open to XSS attacks from people smarter than us who put css into our user supplied data, so the answer is to prohibit inline CSS - not to properly sanitise user supplied data. I think there are better pieces of security advice around than that...

ajmurmann 10y ago
Why not do both and be safe if your sensitization has a bug?
- always_good 10y ago
  I still don't understand what it accomplishes. Why does inline matter? The vulnerability means they can inject arbitrary markup including <link> or <script> that load offsite sources. You can use CSP to whitelist allowed offsite domains. But if you're not careful, "you never know" and "you might as well" are more likely to waste your time chasing low value things. For instance, inline CSS is valuable as an intermittent developer convenience, and disabling it takes that away while protecting your from an unlikely event. Also, you generally should be escaping-by-default and not sanitizing. A templating system should escape by default and make it obvious when you opt out.
  - Annatar 10y ago
    I still don't understand what it accomplishes. Why does inline matter? In the worst case scenario, where the server doesn't have all the blocks of the file cached in random acces memory, the server can fetch the single, inlined file with fewer input operations per second from local storage far faster than one's web browser can fetch multiple files over the network. This means that latency is lowered, and thus delivery time is accelerated.
    - always_good 10y ago
      Right, I meant in regards to this comment chain where "inline CSS is bad if you have an XSS vulnerability."

RubyPinch 10y ago

so, hoster doesn't escape anything the users provide, and is more concerned about CSS instead of JS? And then their site broke as soon as I clicked a link