I'm trying to load some external JavaScript, but Chrome isn't having it.
To be clear, I'm using a bookmarklet to create a new script element, change the src attribute to my source code, and then append it to the header.
Here's the code:
javascript:var script=document.createElement("script");script.src="URL";document.getElementsByTagName('head')[0].appendChild(script);
Unfortunately, Chrome's Cross-Origin Read Blocking algorithm is preventing me from injecting the source into the header. I believe that this is due to the fact that said source document is simply plain text, and not an acceptable JavaScript file.
Is there any workaround for this?
There are many websites that because of CSP (Content Secrutiy Policy) not let you load scripts from other URLS. You should check the CSP headers of the website you trying to inject scripts into.
More info on CSP:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
UPDATE
I see that your edit your question (after my initial answer) and now your asking specific about CORB issue. In that case you have to ensure that your script returing the correct content-type header. If you script doens't return text/javascript chrome will not execute it.
How do you serve the JavaScript file? if you will give more details we can try to help.
Usually servers are giving the correct header to JS files. There are some exception. For e.g. when user upload JS file to GitHub, GitHub will serve it without the content type header. This is because they don't want that a webmaster that trust only GitHub will have a risk that a user will execute user uploaded script (to GitHub) on his website.
More info:
https://www.chromium.org/Home/chromium-security/corb-for-developers
Related
I have a JavaScript code snippet embedded inline on a page that downloads and appends to body my main JavaScript code from a different CDN, cdnjs.com/xyz/main.js. So far this has worked fine for my customers. main.js is able to make AJAX calls and perform normally.
Is my assumption correct that clients must have allowed in their CSP policy the cdnjs.com domain? And this process is a required for a setup like mine?
If I change my main JavaScript to additionally download and run new JavaScript code from another domain, cdnjs2.com/abc/new.js, will this new JavaScript code run fine and be able to make AJAX calls?
Is my assumption correct that clients must have allowed in their CSP policy the cdnjs.com domain?
Well, since by default there is no CSP policy for a page, it would be truer to say they must not forbid that domain if they have a CSP.
If I change my main JavaScript to additionally download and run new JavaScript code from another domain…
When there is a CSP, every location that JS is sourced from must be allowed, even if the code that sources it is from an allowed location.
I am looking for recommendations on how to implement our CSP policy. We have an Angular SPA application, that has an iframe without any src attribute. We populate the content of the iframe dynamically based on markup that we receive from an API. The markup that is returned from the API could have scripts that are not controlled by us. The SPA application will render the markup, including executing the scripts that get returned from the API as part of the markup.
The issue here is that a potentially malicious script could get returned from the API, which could hijack user information from the parent SPA application.
In this situation, how do we go about implementing CSP policy for the SPA application? I understand that there might not be a way to restrict hijack without doing some major architecture changes in the way that the content is rendered by the SPA. Any suggestions are welcome.
If the remote source returns specific scripts, you might be able to set a hash policy that allows that specific script. If they're returning a script that changes, you have to either a) block it, or b) trust them.
Example hash:
Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='
Putting it another way: If it's a known script, you can allow that exact, known script. If it's an unknown script, how can you possible write a policy for the unknown?
There is also strict-dynamic, which basically says "allow unknown scripts that are loaded by this known script (e.g. Google APIs)", but indeed in that case you are trusting that other source to not serve you malicious code. What this does do is prevent other random unknown stuff from loading from other sources; it's a partial restriction.
I'm working on an extension that injects script in a page.
The extension is basically a content script that injects another script into the DOM. ( Why not just a content script? )
(There aren't any issues with my code, it works fine. The main purpose here is to learn about security issues in web development only)
The injected script is a source file in my extension and I get it with JQuery.get, using the address from chrome.extension.getURL('myscript.js').
Are there any security issues I should be aware of?
The page is not https, can this get return something different from my script?
I also insert HTML content using the same method. The HTML file is from my extension, just like the scritp. Is there any possibility of the responsetext be corrupted by a man in the middle??
What are the common practices to avoid such security issues if they exist?
Differently, if I create a script (document.createElement('script')) and set its source to my file. Would it be possible for someone to interfere when I inject this cript into the dom? (document.documentElement.appendChild(myScipt))
Also, what are the security issues involving this approach? Injecting a script that changes the XMLHttpRequest methods open and send in order to capture ajax calls, add listeners and send them with the same exact original arguments.
So, namely, say I have these:
var myScript = document.createElement('script');
myScript.src = chrome.extension.getURL('myscript.js');
var page = chrome.extension.getURL('mypage.html');
In such context, can a $.get('mypage.html') return anything different from my page due to a man in the middle? (In other words, could I unknowingly inject a malicious page?)
Could a document.documentElement.append(myScript) inject a different script? Could a supposed man in the middle get between the .src and change the actual script?
Since the script is meant to change the XMLHttpRequest prototype as described in the linked approach, could I ever send with arguments different from those passed by the original call?
Thank you!
First of all, Chrome is both the client and the server when you fetch a file from an extension, so you don't need https, it's worthless in this scenario. There is no man in the middle here.
One can think of another extension intercepting the ajax, but to do so that extension should already have proper permissions granted by the user, so it won't be an unauthorized interception. At least it won't be any less secure than any https ajax.
And, as you say, another man in the middle attack consists in redefining XMLHttpRequest, which you can do with an extension (with proper user authorization) or any other way to inject a script in the page (specially if the page is not a secure one).
I wonder if you can inject and run a script before the page loads, or at least before any other script execute, with the only purpose to "secure" the original XMLHttpRequest object (with something like mySecureAjax = XMLHttpRequest;)
You can execute before any script on the page, but you can't guarantee to execute before another extension's injection.
I'm using a method of creating a .js file on server #1 which contains document.writes to write html code, then a simple js include inside html code on server #2 to load that html code (there are multiple server #2's). This is basically replacing an iframe method with the advantage being that each server #2 owner controls their own css.
The method works perfectly as is. My question has to deal with caching. Each time the page is loaded on server #2 I want the .js reloaded, as it will change frequently on server #1. This appears to be the case on each browser I tested, but can I rely on this as being the default case, or is it dependent on browser settings? Despite all I've read on caching I can't figure out what triggers the load for a case like this.
You can control browser caching using HTTP headers on the server side. Like cache-control and cache-expiration. More here - http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html
In a case like this, the caching is triggered by the cache policy of the js file. Not the html file.
The browser doesn't cache the rendered page (well, it does for back buttons but that's not what we're talking about). The browser caches the source file. Therefore even if the html page is configured to be cached for a long time the javascript injected content will only be cached as long as its been configured to.
To configure caching policy you need to set specific headers on the server side. Sometimes you can do this in a CGI script. Sometimes you can do this in the server configuration files.
Google "http caching" and read up on how to configure a page to be cached or not cached (also google "json disable caching" or "ajax disable caching" because this issue crops up a lot with ajax).
Ok so my question title may have been a little confusing.
Here's my example:
www.WebsiteA.com is hosting MyFile.js at http://www.WebsiteA.com/MyFile.js. This file makes an AJAX request for http://www.WebsiteA.com/location/file
When this Javascript file is included on WebsiteB through the script tag, will the Javascript run into cross-domain issues or is it based upon where the actual Javascript file is hosted?
Hopefully you understand me ok, thanks for any responses :)
Mike
The same origin policy applies to the domain of the site (ie. the URL you see in your browser's address bar). The JavaScript file can be hosted on any domain. The <script> tag is exempt from the same origin policy.
If the address bar in the browser is showing www.websiteB.com, you will bump into the same origin policy if you make a request to a file on www.websiteA.com. This is irrelevant of where the .js file is hosted. If this is the case, you may want to check out the following Stack Overflow post for a few workarounds:
Ways to circumvent the same-origin policy
You can do this - this is how most javascript based analytics trackers work (Google Analytics etc)
It depends on if you're using a relative path or a full path.
If it's relative, the hosting server will look relative to the URL that is being called
If it's full, you can specify any domain/host