I read an article about bookmarklets which says that bookmarklets are so powerful they can be dangerous. For example, a malicious bookmarklet can collect your "cookies", "localStorage", the string in the password input box and then send it to a remote server, which is similar to "script injection".
I'm curious about that. Since this article was written in 2007 (8 years ago), is there any limitation for bookmarklets (as well as browser plugins) to improve the security in modern browsers?
Bookmarklets are scripts run by the user. Yes, they can do all of the things you mentioned (limited in the same way that any other code in the page you inject them into is limited), but only when the user triggers them. They are indeed script injection, but script injection by the person in charge of the machine. The user can do at least as much, and really quite a lot more, by opening the browser's developer's tools.
But answering the question you actually asked: No, I don't think any new restrictions have been put on bookmarklets in the last several years.
The Content Security Policy is not intended to affect bookmarklets:
Enforcing a CSP policy should not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets.
but has some unintended consequences:
Bookmarklets. People love them, and CSP breaks them.
Instapaper, for instance, injects a script tag to load instapapering code from Instapaper's origin. I suspect it would end up injecting CSS as well. Though the bookmarklet itself executes as expected, it's actions on the page are subject to the page's policy, so these loads are likely blocked. That's certainly the case on mikewest.org and github.com.
CSP blocks javascript: protocol URIs which load external scripts:
Whenever the user agent would execute script contained in a javascript URI, instead the user agent must not execute the script. (The user agent should execute script contained in "bookmarklets" even when enforcing this restriction.)
Fixing that would make most of my bookmarklets work, but it won't help with bookmarklets associated with services like Pocket and SubToMe. Those bookmarklets load external scripts which will be blocked by GitHub's script-src CSP directive.
script-src can be circumvented by running bookmarklet code through developer tools or userscripts, but that's besides the point
...although you are limited in what URL you can use to inject a script into certain CSP-protected documents, you can insert ANY text DIRECTLY into the document.
A userscript which converts bookmarklets to script tags would be another workaround
References
Content Security Policy Level 2
The Resurrection of Bookmarklets
Chromium Issue 233903: CSP: Bookmarklets should bypass pages' policies
Mozilla Bug #866522- Bookmarklets affected by CSP
Webkit Bug 149000 – Some extensions triggers CSP violation reports
333318 - Remove support for BeforeLoad event - chromium - Monorail
Related
I am not able to run my content script on the new tab page (where it is not assigned to any url).
I looked at various posts on the subject, ie, Does content script have access to newtab page?
and What is the URL of the google chrome new tab page and how to exclude it from manifest.json
which seem to suggest it is possible.
I enabled chrome://flags/#extensions-on-chrome-urls
I have:
"permissions": [
"http://*/*",
"https://*/*",
"chrome://*/*"
],
(also tried "*://*/_/chrome/newtab*")
still no luck ... what am I missing ?
this answer Can you access chrome:// pages from an extension? mentsions "wildcards are not accepted". Is this true ? and if so how to specify the newtab page ?
The problem is that Chrome 61 and newer explicitly forbids access to the contents of its built-in new tab page (NTP) via content scripts or any other API.
The solution is to create the entire replacement page as an html file in your extension and specify it in chrome_url_overrides.
As for why, here's quoting [source] rdevlin, one of the developers of chrome extensions API:
There's a few reasons for this change. One is to enforce policy,
the other is for consistency.
We've had a public policy for awhile now that states that modification of
the NTP through anything other than Chrome URL overrides isn't allowed (though
we didn't begin enforcing this policy in many cases until July 1st). This is
merely bringing chrome code more inline with that same policy to help prevent
surprise if an extension is modifying the NTP and is taken down for policy
violations.
This is also for consistency, since we've actually treated scripts on the NTP
differently for years now, due to certain NTP magic. For example, the URL seen
by the browser on the NTP is chrome://newtab, but the url in the renderer is
https://www.google.com/_/chrome/newtab. Since chrome.tabs.executeScript checks
the URL in the browser, the script would be denied, even though content scripts
(checked in the renderer) would be allowed. In theory, these permissions should
not be different. Similarly odd, if the user is using the local ntp
(chrome-search://local-ntp/local-ntp.html), injection would already be
disallowed in both the renderer and the browser. And, if we go waaaaay back,
the NTP used to be pure WebUI with an URL of chrome://newtab, where injections
were again disallowed. Rather than have inconsistent behavior depending on the
type of script injection the extension uses, we want to have consistency
throughout the system.
P.S. Please don't edit the quoted text.
Content Security Policy seems really robust, but I don't think it's perfect (and I've seen sources that refer to it as a "partial" prevention for XSS). My question is: what sorts of XSS attacks does it not prevent?
No all browsers have implemented it, so users using non-supported browsers it offers no protection.
http://caniuse.com/#search=csp
Even on supported browsers, unless the Content Security Policy is to disable all JavaScript (in-line, internal/external domain) then it still leaves areas open to where JavaScript can be run. Which means, if any malicious JavaScript can make its way into those zones, then Content Security Policy will not stop the XSS from happening.
Some examples of of where CSP will not stop XSS:
If an application is using inline (on the page) JavaScript and the CSP policy allows it. If unencoded/unvalidated/malicious values are put into the page then the browser will run the malicious JavaScript just like it will run the intented JavaScript. (Currently ASP.Net Web Form apps need JavaScript to run on the page, so any malicious input that is displayed will be executed by the browser.
If you are dynamically creating your JS files for your app and unencoded/unvalidated/malicious values are inserted into that file, that will cause a XSS vulnerability.
If you are sending pages and/or JavaScript files over http and not https an a MITM attack can modify the values over the wire.
If you are loading JavaScript files from a third party domain and their security gets compromised, malicious scripts could be sent to your app instead of the originally intended scripts (think CDNs).
These are just some of the examples I could think of off the top of my head.
Some of these concerns look like they can be mitigated through use of the CSP Level 2 directives, but there is limited support for them.
In short, CSP is a very nice layer of defense, but it should not be your only line of defense. Even though it will not cover everything and not all browsers currently supported it, it is an additional layer of security I can use to keep my application and users safe.
What are the application security risks of including a hidden 3rd Party iFrame?
If I understand correctly...
Click jacking isn't an issue for me because I own the parent page
Same-Origin Policy prevents 3p frame from interacting my dom/cookies/js
The frame is hidden, so I don't have to worry about anything that may be displayed in the frame
However I did some experiments in the Chrome console and...
3p frame can call things like alert/prompt
3p frame can redirect the parent via location.href
Malware inside the 3p frame (java/flash/activeX) could infect my user
I'd love to see a list of the possible issues and any mitigations, but I can't find a good source of information.
So...What are the application security risks of including a hidden 3rd Party iFrame?
If you are implementing Iframes on your website, you could use the sandbox tag in HTML5' iframe to prevent yourself/others on your website.
Source: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox
I don't know how effective it is (the sandbox feature), but it states it can restrict scripts, forms etc inside the iframe.
<iframe sandbox="" src="www.example.com"/>
Although not a guaranteed and effective method, it's one of many different ways. On your end though, you could use add-ons such as NoScript to prevent certain/all scripts from running.
It's possible that the 3rd party iframe, as you said, could use exploits such as drive-by-downloads, browser exploits to gain access to your OS and possibly more.
See also here: Why are iframes considered dangerous and a security risk?
Hope this helps.
I'm trying to make a bookmarklet to use on youtube and other video sites in order to easily get information from the video and store it elsewhere.
From today, apparently I can't do that anymore since youtube force itself on a https connection and from what I've read on chrome's console window, the bookmarklet doesn't run on a https page. Is there a workaround?
Here is the edited code:
javascript:(function(){var jsCode=document.createElement('script');jsCode.setAttribute('src','http://[mysite]/b/enter.php?i=userid&r='+Math.random());document.body.appendChild(jsCode);}());
Google Chrome (and possibly other browsers?) blocks HTTP resources from being accessed from an HTTPS document. This is to prevent "mixed content" attacks, in which insecure HTTP scripts could be intercepted by an attacker in transit over the network and altered to perform any kind of malicious activity (e.g., leak cookies or sensitive page information to a third party). Such a violation would undo any protection granted by HTTPS.
Chrome used to provide a prominent warning that an insecure resource was blocked, but now it no longer does so, and all insecure loads silently fail. The only solution available to you at this time is to use HTTPS yourself when you serve the script.
In Firefox, if you want to run a bookmarklet that references http on an https page, the way to get around this is to temporarily disable security.mixed_content.block_active_content. There are two ways to do this.
go to about:config in a new tab, search for security.mixed_content.block_active_content and then toggle the value to false. Run your bookmarklet and then toggle it back to true (since you probably want it turned on most of the time).
use an add-on / extension to toggle the block. A quick search turned up Toggle Mixed Active Content, and a quick test seemed to work well. There may be others.
Have fun and be careful. Here be dragons!
the bookmarklet doesn't run on a https page
Why not?
Try changing to a HTTPS domain yourself. Usually HTTP content is blocked when you're on a HTTPS domain.
I have created a work-around "fix" for this issue using a Greasemonkey userscript. You can now have bookmarklets on all CSP and https:// sites, plus have your bookmarklets in a nice, easily-editable library file instead of being individually squished into a bookmark.
The last months I read a lot about the Same Origin Policy of browsers and Cross Domain Requests.
All the time I am wondering, for what reasons the <script> tag is not part of it?
I found the question to be asked several times, also here on stackoverflow, but all replies didn't answer why it isn't part of it.
Is this due to historical reasons or what is the background behind this idea?
I hope somebody can help me with this question.
I don't know they reasons that it was decided that foreign <script> didn't need to be blocked, but there are many benefits of that decision.
Not all scripts have to be hosted on your own site, and, as a corollary,
scripts can be hosted by content delivery networks that can deliver them faster and allow the client to use cached versions of popular scripts.
Foreign scripts allow us to have cross-domain AJAX requests via JSONP.
Also, script tags historically predate the Same Origin Policy, so it would make sense that scripts could reference files not necessarily hosted by the same site, to be consistent with how the a, img, embed, frame and other tags also did.
Certainly part of the reason is that the <script> tag is much older than the same origin policy, so preventing its use would break a lot of web pages.
I believe the other reason is that the same original policy works to prevent information from being accessed by a different origin than it was created in. The script tag doesn't permit information to be sent to its origin, or at least, no more information than any other GET request such as <style> or <img> would.
Though there are likely ways around it, script tag src parameters are generally fixed values set in your static HTML. Both historically and even now in terms of security risks, there's not much concern over cross-domain script requests in this fashion. On the other hand, there is certainly a large benefit in allowing it — CDNs for script downloads, jQuery hosted on the cloud, etc. There's also backward-compatibility to consider.
This is not quite as true for AJAX requests, where the script URL may (and often does) come from user input or other dynamic state. On average, the barrier to entry for breaking this is much lower than for breaking a script tag, where "breaking" = "causing a security breach".
Source: guessing