1

I'm working on browser automation tools (working at the JS level). It's pretty clear that loading external script can be considered an XSS attack. A few months ago I was able to run my scripts on Github.com so long as I served my js resources over HTTPS.

But this is no longer the case, i.e. Github has implemented an elegant standards-compliant barrier to this:

enter image description here

This is a great step forward I think: we can specify to the clients that we want them to put a more secure perimeter around our site's sandbox.

On the other hand it is making the options more limited on mobile platforms, though that's not entirely true because it's entirely possible to produce a standalone browser app which has these extension features built-in. Not exactly gonna be easy to accomplish compared to a browser extension, though.

Is it still possible to work around this with a (codesigned and reviewed) browser extension? What sort of user experience impact might this have? My hope is that it will be possible to set this up so that end-users only have to go through a short one-time setup. It's apparent to me that at least Google is making it so that Extensions published through their portal is distributed at least "reasonably" securely, and I imagine Apple (and eventually Microsoft) would be following suit for Safari and IE. I am only interested in Chrome and Safari for now (primarily Chrome for now).

If it turns out that somehow even extensions are subject to the content security policy, how might I write an extension that can reliably manipulate a page for me? I'm fairly sure this can't be the case as it would be the death of something like Tampermonkey.

Steven Lu
  • 41,389
  • 58
  • 210
  • 364

2 Answers2

0

Oh I just needed to read a little further (oh Github, you're awesome):

https://github.com/blog/1477-content-security-policy

The answer is yes! User configured scripts should always be granted clearance! (but we are off to a rocky start it seems)

I actually think there's significant opportunity for social engineering happening here; "Install this bookmark in your browser to use our cute emoticons in forums!" "oh bookmarks can't be viruses, right?"

Steven Lu
  • 41,389
  • 58
  • 210
  • 364
  • Can you explain what the link to this page is saying? I've got a bookmarklet to supply my user name and password to GitHub but it doesn't work because my script is being blocked. The page linked *sounds* like it is saying I need to do something on the GitHub server, but I don't have anything on the GitHub server that controls the login page... do I? – Michael Jan 15 '14 at 21:02
  • it may well be the browser applying a stricter policy than what is stipulated by the standards. – Steven Lu Jan 16 '14 at 00:41
  • Yeah that is apparently the case, and it makes me *mad* because I've been dead in the water over a year because of this. – Michael Mar 21 '15 at 18:14
  • Sounds like you just need to find a password manager extension. I was under the impression that there are a ton of those out there and many that supposedly work very well. I don't use them myself though, but still, it's probably less risky than rolling your own. – Steven Lu Mar 21 '15 at 18:24
0

As a workaround, you can tell your bookmarklet to load an external CSS stylesheet with your JS code injected. This bypasses CSP. Have a look at my answer to a similar question.

Community
  • 1
  • 1
niutech
  • 28,923
  • 15
  • 96
  • 106
  • Do you know if this is a vulnerability or a workaround that still prevents malicious code execution? (Actually on second thought, maybe this doesn't matter. if you make a bookmarklet you are responsible for what it does) – Steven Lu Aug 14 '14 at 22:07
  • @StevenLu It's not a vulnerability. The [spec](http://www.w3.org/TR/CSP/) clearly says: *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.* – niutech Aug 14 '14 at 22:26