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).
Related
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.
I have a web app http://embed.myapp.com that is intended to be embedded on a few whitelisted sites. The frame access is controlled with X-Frame-Options ALLOW-FROM
However, I do not want users to access it by putting in the above link directly in the web browser.
What is the best way to block plain (non-embedded) access?
I can determine whether the site is embedded with javascript, but by that point a session is already created and certain sensitive information such as CSRF tokens can be seen.
You may not quite get an absolutely foolproof way of stopping users from looking at the content directly.
A simple way to catch most cases would be to look at the referer header ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section 14.36) on the server side and only serve the content when it is referred from the correct pages.
I'm working on a user login system and I have come up with a solution that I wanted to run past you fine folks to make sure I wasn't about to create a giant security flaw.
Here is what we have.
You start on an HTTP page that when you click a link will open a modal window. The first link from an HTTP page when clicked will repopulate the modal with an iFrame that links to an HTTPS page. Since I can't have the HTTPS talk to the HTTP page I'm using a document.location setting on the HTTPS iframe page to make the success page HTTP. Then the HTTP page talks back to the parent window.
So:
HTTP (click) -> Opens iFrame in HTTPS -> Login over HTTPS secure on Success document.location -> HTTP success page -> window.parent.success_msg(deferred); calls to the parent window.
It's working great in all browsers so far...haven't tested IE yet, but I wanted to verify this wasn't a really terrible practice before I present it.
Thanks!
An iframe to an HTTPS URL within an HTTP page is really bad practice because it makes it hard for the user to get more detailed information (in particular security-related information) about that page. (Sure, you can probably right click and find a way to check the properties of the iframe, but even users who'd know how to do that probably wouldn't do it).
With an HTTPS iframe like this, you prevent the browser from displaying the usual security symbols: lock, green/blue bar and, more importantly, the address of the site (an attacker could just put their own link to their www.some-other-site.example instead of the indented site; www.some-other-site.example could have a legitimate certificate and the browser wouldn't give any alert message).
This practice is especially bad as an HTTPS iframe within a page served over HTTP, but it's not good either when the containing page is served over HTTPS. You can't easily verify the identity of the server serving the framed page either. (Sadly, this is (or at least was) what's recommended by 3-D Secure...)
If you want to do the authentication over HTTPS, switch the full page to HTTPS and then back, by giving a non-secure cookie. Of course, this isn't very secure (someone could intercept that security token, as popularised by FireSheep), but this is better in that at least, the user will be able to check that the page where they enter their credentials is the legitimate one. (This should be done carefully too, see this question.)
The best way is to stay over HTTPS without iframes after authentication if you can.
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!