In extensions (I'm praticularly focused on Chrome's extensions), css identifiers and classes injected in a page may enter in conflict with other elements on the page.
I'm trying to define their name with an extension prefix, but it's not perfectly sure. So, is there a way to define scurely names of css ids/classes?
It's not possible if "perfectly sure" is your requirement. Someone could always download your extension, look at the classnames you're using, then change their website's CSS to conflict with (or more likely attempt to override) your classnames. This is a feature, not a bug; extensions extend web pages, so they're supposed to be able to commingle with and alter their DOMs.
If you wanted to invent a system where others would not intentionally conflict with yours, why not use the Java namespace scheme: take a domain you own, and use it as a prefix, like com-example-myclassname? Slightly less readable and no more secure would be either the ID of your extension or a randomly generated SHA-1 hexcoded hash:
abcdefghijklmnop-myclassname
da39a3ee5e6b4b0d3255bfef95601890afd80709-myclassname
I'm intentionally not including dynamic solutions here because CSS typically isn't dynamic in a Chrome extension or app. Moreover, CSP would probably make this approach anything but straightforward (which is a good thing).
Related
I've learn some about Content-Security-Policy, although not fully (and that's why I'm here), and now I want to implement CSP in a rather old existing project.
Problem is, many files has multiple javascript/css inlines. Both that I've created myself and some from third party libraries...
What is the best way to take care of these inlines, if any? There are plenty of files and I dont want to go into all the files and adjust them (if it's possible), especially not in the third party files.
From what I've understood, by using 'self' directive, it authorizes linked javascript files in the domain. Now some of the linked third party libraries in the project are containing inline css, or "innerHTML += someMarkUpCode;", which in turns gives
"Refused to apply inline style because it violates the following Content Security Policy directive:" in the browser.
I've also read you can use hash or nonce for inlines, Problem is; some third party files seems to be dynamic (like the example above), so I guess hashing cannot be used?
I've been looking into nonce, but it seems like it's not supported by IE? Not sure how it could be used with third party libraries either.
But I guess for constant pages hash or nonce could be used...
I dont want to use 'unsafe-inline' directive.
Have I missed anything obvious?
TL;DR:
What is the best way to manage third party libraries containing inlines when implementing CSP?
I'm making a website, using: MODx, SASS, Bourbon & Neat, jQuery, Bootstrap, Velocity, and some other minor libraries. The IDE used is PhpStorm, all files are encoded in utf-8, no BOM; It also includes search forms from 3rd party resources, some of them placed in iframe, and some are "native", with the standard html form. So, naming hell is near and I didn't yet establish any standardized CSS naming convention like BEM, SMACSS, etc., just some common good CSS recomendations (low nesting level, fine semantics, .class selectors everywhere)
I'm going to move to BEM, and looking for a namespace, but I don't want to stick to it, because it's my first BEM CSS project, and I'm not feeling 100% sure, that I'll perform fine with everything about it, and I'm afraid to break something, when doing any global operations (renaming, maybe something else). So, I want to use non-standard symbols combination, something like ☺☻ or ♥♦♣♠ or whatever. This should be 100% not busy by any project's libraries from 3rd party. After that, I can use, for example Grunt regexp, or custom post processing application, to replace that characters with normal namespace name, or no namespace at all (nice, small bonus). I'm not going to let this symbols remain in production code. Apache, PHP, SASS parser and the browser will receive "normal" code. Those symbols will be "visible" only to "Devend" items - Grunt, PhpStorm, etc.
However, I've never seen any articles and authors, on the Internet, recommending such approach. So, looks like, there are major issues with it. Are there any?
ADDED: And what are those issues?
PS: I'm aware, that a number of modern browsers are fine with unicode symbols for CSS class names (it's like Java allows unicode symbols for function/variable/etc. names), and therefore, I can theoretically leave them as is, but it doesn't look fine to me by the same reason: never seen anyone doing / recommending to do this way.
After some research I've sorted out the correct question and answer:
How to avoid troubles in the future, when choosing CSS namespace name for the project, with BEM naming convention.
A common good practice for CSS class naming is to use all lowercase letters. Maybe, in some naming methodologies, the rules can be different, but in BEM, it's a mandatory to use all lowercase letters. So I can use UPPERCASE letters with a couple of dashes, something like NS--. My own code is centralized enough to allow accurately define a search/replacement scope for Grunt, or PhpStorm, etc. And I can go develop my markup and don't bother about problems in the future. A major advantage is that it will work even without pre/post-processing, it's just a fine convention to use with BEM in my case.
The next challenge is how to deal with composed classname / selector strings in php and js. And here, the solution for the first part (static markup), doesn't restrict on how to solve this, "dynamic part" of the problem. And here we also can avoid pre/post-processing by introducing variables in PHP and JS.
I love pre/post-processors, but it is great that we can avoid using them in this case, since it's actually a naming convention problem, not a workflow enhancement issue, which is a primary purpose of webmaster's pre/post -processing tools.
I want to implement a simple feature into my node.js/express app that allows the users (registered and nonregistered) to quickly change some settings in the CSS theme.
Is there a way of implementing it in a way that I don't have to record the user's preference into the db, instead the app just remembers the preference of the current browsing session and shows a different CSS theme depending on what the user selected.
And I need these styles to not be in a separate CSS file, but some kind of adjustment to the existing ones.
What would be the best way to implement it?
I thought about adding a few style modifications in a separate CSS file and then when the user selects a different theme, recording it as the current preference and loading that additional css for those users.
Do you think it's a good way or there's a more efficient one?
Look into LocalStorage (available in just about every modern browser) for storing the preference, or instead store the preference in a non-expiring cookie. The first approach is best if your preferences are complex (like overriding individual elements) and the second if they're simpler (like just one file override).
As for the updated CSS, don't modify existing files. Use the cascading nature of the language, which is built for overrides. In other words, inline the changed CSS into your html. It will usually take precedence over separate CSS files unless individual rule weights are different for some reason (like more specific selectors, which increase rule weight/priority).
I am using insert-CSS node module for adding styles to DOM, internally this adds the embedded approach.
so far my understanding is using external style sheets is best way to do it. But while using insert CSS, css added to the js bundle and dynamically css embedded to the . so this also looks as same using external CSS.. and css will be cached with js and there will be one file(js+css) we can avoid one http request for loading CSS ?
I feel this insert-css is better than traditional approach(external css) am i correct? please suggest me your thought on the same and add some docs to refer.
so my question is which is the best approach among using "insert-css npm" or "external css"
I didn't find useful info on this question and sharing my experience.
My personal recommendation is not to use "insert-css" modules for the simple projects like dealing with forms and minimal amount of components.
"insert-css" - as mentioned above, "insert-css" add the embedded styles, in the network, its passed as base64 format. Though it's less weight in the network, browser needs to convert the base64 format to css and adds the embedded css, this conversion process will happen allays in js side, I guess which will cause the performance issues
Is there anything tricky someone could do with user-uploaded CSS to harm a site? If I wanted to allow users to upload/share their own CSS themes to a site, is there anything I should look for or disallow?
EDIT: Assume I know how to check if it's a valid CSS file etc. I'm looking for CSS specific exploits I need to avoid.
I believe standard CSS, parsed in a standard way is safe. However, through various non-standard extensions CSS is unsafe.
It's not just CSS that is unsafe, due to the fact that some browsers ignore RFC 2616 and sniff the content type instead of respecting the Content-Type header, it is possible to trick some browsers into embedding JavaScript hidden within static image files.
Even if you work around these particular issues, there's nothing stopping browser vendors from screwing you over in other ways without you realising.
As a general rule, I would not allow untrusted users to upload files unless I gave each user their own subdomain and ensured that any cookies on the main site were limited to the www host. This makes it look to the browser that each user has their own separate site with their own separate security context, so even if they manage to execute code, it doesn't compromise anything.
Even if you parse the file for valid CSS a hacker could still be malicious by using something like :before and :after. To ensure security you will want to whitelist a subset of css properties & selectors in your validation.
They can include an .htc file which is essentially Javascript. Actually, it doesn't even need to be in .htc file, you can write Javascript in CSS using expression(). And also (although this is given), they can mess with your site by hiding/showing stuff inappropriately.
You primarily need to be careful on what is being uploaded. If you do some kind of sanity check, that it is valid CSS, you should be fine, but if you just allow any old file to be uploaded, someone could sneak in some java script or other malicious code.
The actual type is not harmful, but the whole upload concept is the problem as it allows attackers to deliver a payload you wouldn't expect.
But I would say as long as you check off your security checklist and validate your content to be at least some css, you should be fine.