What security issues exist when using inline CSS? I’m not up to date with this stuff.
You’re not alone, I had to Google it myself.
I was was surprised and humbled to see that it has been a thing for at least 3 years.
https://www.owasp.org/index.php/Content_Security_Policy
Good news is it has wide browser support
Why should websites use it?
https://w3c.github.io/webappsec-csp/
Content Security Policy (CSP), a tool which developers can use to lock down their applications in various ways, mitigating the risk of content injection vulnerabilities such as cross-site scripting, and reducing the privilege with which their applications execute.
[quote=“Mittineague, post:22, topic:234640”]You’re not alone, I had to Google it myself.
I was was surprised and humbled to see that it has been a thing for at least 3 years.
[/quote]
Well, I haven’t used CSP yet but I understand what it does. But this still doesn’t answer my question - in what ways is inline CSS unsafe?
I’m not a malicious hacker so my knowledge is limited.
But my take is that as long as the inline CSS is from the page author, not so much a problem.
If I want to have a mess of
<span class="warning" style="color: #F00">
type of tags in my HTML and deal with the troubleshooting and maintainability problems (or go to a forum and get others to do the work ) that’s my problem but AFAIK security isn’t one of the problems.
AFAIK the main risk is injected content that takes advantage of the way browsers deal with various
image: url()
styles.
Fetching remote untrusted URLs can pull in stuff that is not what one would want in their page.
<off topic>
Not that I have ever been an untrusted url, but at one time I had trouble with untrusted people hotlinking to my images. I swapped out the images (left the filenames the same) with a giant image that said —
I’m a thief, I steal people’s images and bandwidth!
It took them a while to figure it out, but they eventually stopped.
I have since adjusted the settings on my server to prevent hotlinking.
</off topic>
I am not sure what harm can be done by injecting CSS into a web page by itself but if JavaScript is injected as well then all sorts of nasty things become possible. CSP headers block inlining of both.
I believe that is the problem.
Browsers can call in a file identified as something other than the JavaScript code it contains
I tried putting together an example. but though it worked back in IE6 days, it didn’t inject JavaScript this time.
I know I didn’t configure my Apache to send CSP headers but looking in dev tools showed a file in-page-script.js
and a response header
Content-Security-Policy:script-src 'self' 'unsafe-eval'; object-src 'self';`
A best as I can determine it’s from a content script in the Ember Inspector extension.
EDIT
I also found this June 2015 SitePoint article
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.