I'm a bit confused on how JavaScript is able to load external libraries. Is it doing a GET request to the url I specify in the script tags? Does the browser handle the storage of the library or is it kept somewhere in the DOM?
It seems like most things that the browser might be doing with loading external libraries would violate the same-origin policy. Is there any extra security modern browsers enforce when loading scripts from external sites? Is it possible to load an external library and then print its source to the screen?
Thanks!
I'm a bit confused on how JavaScript is able to load external libraries.
JavaScript has no native means to load libraries. That is a feature provided by the host environment (such as a browser or node.js).
Is it doing a GET request to the url I specify in the script tags? Does the browser handle the storage of the library or is it kept somewhere in the DOM?
The browser will make a GET request, load the script into the JavaScript environment for the viewport, but only keep the HTMLScriptElement DOM Node in the DOM.
It seems like most things that the browser might be doing with loading external libraries would violate the same-origin policy.
The same origin policy is designed to protect non-public data on third party sites. Scripts aren't data (although they can be written so they have embedded data in them, JSON-P depends on this as a way to avoid the same origin policy).
Is there any extra security modern browsers enforce when loading scripts from external sites?
No
Is it possible to load an external library and then print its source to the screen?
No (although you can use XHR to make a separate HTTP request to get the script source — which is subject to the same origin policy).
Related
I used a iframe to load a external sites but some of the sites are not load due to a security header x-frame-options:[deny/sameorigin] .
Is there any alternative way to load any external sites in our app.
In a single sentence, it is impossible to make it work with all the external sites within your html using security compliant browsers.
You can try calling an ajax call, get data and use innerHTML to upload content. But it requires CORS enabled on the external site and also actions might not work as you only load html content. Angular might block innerHTML, you might need to relax that exception as well in angular.
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.
I was using PDF.js , good to know another plugin finally developed using JS. Another step toward that famous quote " if sth can be implemented using JS, eventually it will be implemented using JS".
I tried right away to open a local DEMO page, but it didn't work. and the introduction on PDF.js page indicated that some browser ( in my case: chrome ) don't allow open PDF file under URL file:///a.pdf
is this because of some security concerns ?
If it's using ajax to load the file, yes, it's the browser's interpretation of the Same Origin Policy. Some (most?) browsers don't allow ajax access to file:// origins, even from documents loaded from file:// origins.
I'm reading about the same origin policy. I understand that the js on my page should not have access to methods (and more) defined in a js resource on a different domain. However, I must be misreading this. In my website, I have a script reference to the jquery library at the code.jquery.com domain,
<script src='http://code.jquery.com/jquery-1.8.2.js'></script>
and everything in that library is available to the js scripts on my site.
So, what am I misunderstanding here?
The same-origin-policy says that you are not allowed to use objects etc. declared in another domains i.e. in an iframe.
It does not forbid to load a script from a domain and run the code locally. The variables in the jquery script are not from another domain, you just loaded the source code from there.
Same Origin Policy affects iframes and XHRs, img and canvas, among other things.
Pointing a script src to a different host, protocol or port is not in violation with this. This is useful, as we can use a CDN to serve the files and use JSONP for data transfer (before CORS can be used everywhere - thanks < IE8).
I want to serve my JavaScript scripts from a CDN like cloudflare.
Now my scripts communicate with my app server via ajax. Wouldn't the same-origin policy restrictions come into play when I load these scripts from a CDN?
Let's say my app is on the domain:
http://app.com
And I load my scripts from
http://cdn.com/xyz/all.js
Now, since my scripts are loaded from a different domain than the domain my app is running from, I guess the same origin policy would prevent me from doing ajax communication with my app.
Am I getting something wrong?
No, it will work. That's why JSONP works. The "origin" of the script is the page it is executed in, not where it comes from.
As you asked for it, here's a reference (I couldn't find any better, but Crockford is well known)
The src attribute, surprisingly, is not constrained by the Same Origin Policy. This means that a script element can be created which can go to any server, fetch a script, and execute it. If the script causes the delivery of JSON-encoded data, then this is a very useful thing. Unfortunately, there is no way to constrain the script or to inspect it before it executes. It runs with the same authority as scripts from the page. So the script can access and use its cookies. It can access the originating server using the user's authorization. It can inspect the DOM and the JavaScript global object, and send any information it finds anywhere in the world. The Script Tag Hack is not secure and should be avoided.
http://javascript.crockford.com/script.html
Not really a reference: If this wouldn't work, nobody could include jQuery from Google's CDN and then use it's $.ajax method.