As a web developer, is there any way to prevent a user's Chrome extensions from being applied to my site? i.e. a header, meta tag, anything? Additionally, if there is, is there also a way to whitelist particular extensions?
It's not possible. At the web server end, you are only only able to control what the browser will allow you to control. In simple terms, this means you can control the data (HTML, javascript, headers etc) that you send back to it. That's about it.
Can't you create a Content Security Policy (CSP) and block inline javascript and only allow javascript from specific domains? You could even create a CSP in report-only mode and collect violation reports via something like https://report-uri.io/
Related
I know the Stylus and Stylish (not recommended) browser extensions that can re-style a given website (basically by customizing CSS).
In this comment, the author states this can be done via "user stylesheets".
How is it possible to use "user stylesheets" to modify the style of www.example.com and a different style for www.example2.com?
Is it something that can be done without requiring a third-party browser extension, if so, how/where in the browser options should we add our custom CSS?
This seems to be deprecated nowadays:
https://codereview.chromium.org/66383005/
Remove the concept of user stylesheets.
-The support for this has been removed from Chromium already.
This is now just deleting dead code.
...
Really simple here but i am trying to generate a link within an email that popups a page but its not working it also is througing a security exception in outlook 365 how does one properly open a popup from email with correct height and width of window.
here
Using scripts is totally unsupported in emails.
"Scripting in Emails
The short answer is that scripting is unsupported in emails. This is hardly surprising, given the obvious security risks involved with a script running inside an application that has all that personal information stored in it.
Webmail clients are mostly running the interface in JavaScript and are not keen on your email interfering with that, and desktop client filters often consider JavaScript to be an indicator of spam or phishing emails.
Even in the cases where it might run, there really is little benefit to scripting in emails. Keep your emails as straight HTML and CSS, and avoid the hassle."
Source: https://www.campaignmonitor.com/dev-resources/guides/coding/
You can use target="_blank" instead.
You have to use the a tag this way:
Open page in new window
Hope it helps.
I want to know whether the APIs available to Google Chrome extensions enable changes the appearance (colors, styles, etc.) of page contents without modifying the HTML?
For example, when spelling or grammar support is enabled, Chrome will underline phrases that contain problems. The browser doesn't appear to change the markup of the page to accomplish this. Does the extensions API have that kind of feature?
I'm thinking of writing a sort of writing assistant extension that would behave similarly to the spelling or grammar checkers. I'd like my extension's display to be similar to those checkers.
I currently have a form that allows administrators to change basic CSS attributes on a website. I was thinking of creating a form for advanced admins that will display the entire CSS file inside a text area and allow them to edit it freely. Im not worried about the file being wiped as it can be easily restored. What i am worried about is that someone could add some code to the CSS file that could cause major damage to the web server. Is it possible to execute malicious code from a CSS file?
Yes, there are some XSS risks to consider. XSS doesn't attack your webserver directly with malicious code. It is an attack on other users of your system, via their own browser. Basically, it is a browser based code execution flaw, albeit limited via what JavaScript can do (quite a lot though, bar from escaping from the browser sandbox).
As you are letting them edit text presented in a CSS file, this mitigates some of the attacks that are only possible when CSS is embedded in an HTML document (such as via STYLE="" attributes and <style> tags).
However, the following risks are still present:
The JavaScript expression directive allows JavaScript to be inserted into a CSS stylesheet. Note that this only affects Internet Explorer version 8 and earlier.
The url directive can allow JavaScript: style URLs on Internet Explorer 6.
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.
Note 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.
It can if they have access to modify. The below link describes xss and css (cross site scripting). They can redirect your background as one example
http://www.acunetix.com/websitesecurity/cross-site-scripting/
If they have access to the css file they can link it to another file that contains malicious content
Potential xss vulnerability if style.css is served with the wrong content-type header.
style.css
<script>
alert(document.cookie)
</script>
attack.html
<iframe src="style.css"></iframe>
I heard that iframes are going away in newer versions of browsers. I might be wrong. How ever I have an application where you put in the url of a page of content and we will display that content for you.
How would this be achieved with or with out an iframe? what security risks or other issues are presented with an iframe? is there a way to do it with out an iframe? (last I checked this wasn't the 90's)
Iframes are not going away and are handy tools for isolating content withing a page. The Same Origin Policy prevents the Iframe contents from interacting with the parent page.
The other method to display off-site content is to make an AJAX call to a server which acts as a proxy to grab the page content and send it back to the client. In this case, scripts within the AJAX-loaded content can interact with the host page in any way possible.