Is window.parent.postMessage(message, window.parent.origin) more secure than window.parent.postMessage(message, '*')?
We have an iframe component that is loaded by a parent frame. That frame can be from anywhere (our web application is a shared component and can be accessed from any client installation of our main product). So we can't know in advance who loaded us unless we keep some kind of database with allowed origins which we don't.
We are sending a postMessage() to our parent frame, and we can't know the target origin in advance, so I put '*'. I colleague of mine suggested I use window.parent.origin instead, but as far as I understand this has the same effect - postMessage will check that the target origin is the same as itself! Not to mention that it fails when cross-domain.
So am I missing something here? Does using window.parent.origin confer any greater security than a wildcard?
The wildcard "*" could be dangerous if parent page gets redirected to a malicious site that could receive your message with sensitive data.
In this particular case, the parent.origin wouldn't give any security benefits. Ideally, the component's server should be used to detect and the validate the origin of the parent window.
Is window.parent.postMessage(message, window.parent.origin) more secure than window.parent.postMessage(message, '*')?
It depends on what the danger is for you. And what do you consider safe use of your app.
Imagine that your iframe is hosted on domain A, and it is called from domain B. If in this case, sending messages from your iframe to the parent is considered dangerous, then yes - window.parent.postMessage(message, window.parent.origin) more secure than window.parent.postMessage(message, '*').
Using window.parent.origin as targetOrigin will not provide any data to the parent that hosted on a domain other than the iframe domain.
Related
I'm having a hard time understanding the security issues when using a wildcard for the targetOrigin of the postMessage() method. Doesn't the window you call postMessage() on already have an origin that we are sending data to? How would someone be able to interfere with that? Would it be bad to set the targetOrigin to the window's origin using window.location.origin?
I understand the importance of checking the event origin on the receiving end (as illustrated here), but I can't seem to wrap my head around why it is bad for the sending end to use the wildcard as the targetOrigin when the window already has a specific origin.
It isn't a risk per se. It just means that anybody can embed your content in a frame and read the messages you send over the API. If the information is safe to trust anyone with, then that is fine. If it is data that should be kept private between your site, your visitor's and specific partner sites then you should be more cautious about whom you trust with the contents of the message.
Explicitly giving permission to whatever origin the request comes from is effectively the same as using '*'. You should filter on a whitelist of origins if the data needs to be kept private.
I was trying to get the value from my child.jsp to my parent.jsp using
window.opener.document.getElementById("parentId1").value = myvalue;
Even though there were no errors found in the console the value is not getting in the parent page.
The child popup window has the url starting like,
https://safe.cresecure.net/securepayments..... and the parent page url starts with http://.... is there any issue in communicating with a secure child window and a parent page which is not secure?
If so how can I solve this issue?
is there any issue in communicating with a secure child window and a parent page which is not secure?
Yes. HTTP and HTTPS make for separate script origins. (If they were not separate origins then an unprotected page could script into an HTTPS page and change all its content, defeating the purpose of HTTPS.)
If so how can I solve this issue?
Same origin. Serve the parent page through HTTPS, and either put them on the same hostname or set document.domain to a shared parent domain on both documents.
Cross-origin messaging. window.postMessage; if you need to support older browsers (primarily IE<8) then there are horrible backwards compatibility hacks (like communicating through document.cookie or hash navigation).
Server interaction. One document sends the information to the server and the server shares it back with the other document (eg using XMLHttpRequest).
I understand that to access the parent properties of an iframe it has to be the same domain/scheme/ports, but being this only an ssl/non-ssl issue, is there any workaround?
No. SSL/non-SSL means a different scheme and a different port.
Worse, if you could do this, then all an attacker has to do is inject some code into the non-SSL page, and that could access the SSL data, rendering it insecure.
What can cause my website to not have access to a child IFrame's DOM via Javascript? Are there cross-domain restrictions in place? Does HTTPS play a role?
You can only access iframes if they are coming from the same domain. If you are hosting www.mysite.com and the iframe inserted is from www.yahoo.com you cannot access it. Trying to do that will get an access denied javascript error. This is one of the checks to avoid cross site scripting I believe.
You can't do it across domains, and this extends to subdomains as well as across SSL. The child however can access the parent.
Webpage A is embedded in an iframe inside of webpage B. A and B are on two different domains and therefore the same origin policy prevents A from accessing properties of B like so;
location = window.top.location.href // emits a "Permission denied" error
Is there any other way for A to get B's url?
No
If you have control over both domains, you can try a cross-domain scripting library like EasyXDM, which wrap cross-browser quirks and provide an easy-to-use API for communicating in client script between different domains using the best available mechanism for that browser (e.g. postMessage if available, other mechanisms if not).
Caveat: you need to have control over both domains in order to make it work (where "control" means you can place static files on both of them). But you don't need any server-side code changes.
In your case, you'd add javascript into one or both of your pages to look at the location.href, and you'd use the library to call from script in one page into script in the other.
Another Caveat: there are security implications here-- make sure you trust the other domain's script!