I have an application where I am displaying some stuff in javascript modals using jquery.
It requires the user to login for certain flows; but the user never leaves the modal.
So here is what we do currently.
During user flow if the user needs to be logged in, we hide the current div and show a login div
Keep a hidden iframe with Source link as that of our SSO server.
Once user submits the form, we submit the hidden iframe to the SSO server
If user gets logged in we proceed with the flow.
Problem is when there is error logging in. We need to get the error codes from the hidden iframe of the page; but because we don't control the content inside iframe, and it's returned by SSO server; we don't know how to read it since it's cross domain.
Any insights?
So long as there is not client side script being executed from the SSO party you do not need the iframe. The point of using an iframe for security is to prevent AJAX methods from ignoring single origin policy and circumventing SSL encryption. The answer is to remove the iframe. Request the SSO data from the server side and send it to the client from your server as the page is built.
You can't get around x-domain restrictions unless you use the jsonp protocol.
Could the user simply see the error response on page? Why do you have the iframe hidden atm?
Are you trying to silently log in the user to another system using the iframe technique?
Even though that might work on most browsers - some browsers won't pass cookies in i-frames - making this approach not a good broad audience solution.
Let me know if I can clarify.
Use JSONP to callback the function you prevented in your website, then in the iframe, you just need to invoke the javascript function: "parent.callback()".
Related
Suppose I have a drawing html application that my users can use in their web pages. They include the widget setting its src in an iframe (with their generated key passed as query string), I send it with a frame-ancestors header to restrict use to their domain and their users can use the widget to draw.
Now suppose they want to load drawings saved on their servers and pass them to my iframe widget, and they want users to click a button (on their site) to save the current drawing on their server. In both cases, they can send a message to my iframe specifying a signed url, and my iframe can listen to the event and use fetch to, respectively, download or upload the desidered asset.
What are the security implications of my iframe downloading or uploading on their behalf? Is this setup solid or can it be abused? If it can be abused, how?
I am not sure of downloading and uploading , but it is possible to share/pass messages to and from iframe.
More details here - https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
Security concerns
If you do not expect to receive messages from other sites, do not add any event listeners for message events. This is a completely foolproof way to avoid security problems.
If you do expect to receive messages from other sites, always verify the sender's identity using the origin and possibly source properties. Any window (including, for example, http://evil.example.com) can send a message to any other window, and you have no guarantees that an unknown sender will not send malicious messages. Having verified identity, however, you still should always verify the syntax of the received message. Otherwise, a security hole in the site you trusted to send only trusted messages could then open a cross-site scripting hole in your site.
Always specify an exact target origin, not *, when you use postMessage to send data to other windows. A malicious site can change the location of the window without your knowledge, and therefore it can intercept the data sent using postMessage.
We want to get the html content of a page on another domain. The following considerations are present:
1- The login page has a I am not a robot recaptcha.
2- The load of page in iFrame is restricted.
3- Could not use jQuery get or load methods because of cross domain restrictions.
With these limitations is it possible to develop a crawler or even use some client side codes to get data?
Thanks
Actually.. NO
But you can take the help of a backend server.
Let the server download the page and send it to the client.
This would solve problems related to CORS restrictions.
Coming to the captcha part, if the page operations are restricted by the captcha, then again there aren't much you can do. If it was that easy, the captcha wouldn't be used in the first place.
So, I have this web application that shows network products for a specific network. The web server is not inside the network, so in order to show the visitor what network services he or she can order, I need to identify their computer inside the network.
So, I've been doing this with an iframe, which loads a specific in-network URL provided by my clients. This in-network URL will identify the visiting browser and then redirect it (inside the iframe) to a resource on my web service, with attached identification details.
For identification to occur, the in-network web server needs to receive a HTTP request from the visitor, but is this really the best way to handle this? Ajax cross domain is a bit of a mess as far as I'm aware, but I think iframe cross domain is equally shaky, or?
How would you solve this? The chain of events needs to be:
visitor visits my.web.com/services
visitor is sent to client.network.com/identify
Which redirects to my.web.com/identifier?id=XXYY
Now I can set a cookie for my.web.com on the user browser that their id is "XXYY" (or update member profile if logged in). Obviously this request needs to be asynchronous since the in-network web server may be slow to respond, so just a normal redirect is off the table.
I have an iframe that loads an external page, that needs to be logged to make appear what I want. Actually, if i set the iframe the normal way, the iframe loads the external-domain-login page. What I actually have is something like this:
What I need to do is to set some cookies for that source to make pretend the external domain I'm "logged". That can be done (or what I think this can be done) is setting to the request the cookies that the login response gave me.
I'm actually able to get those cookies, but don't know how to set them to the URL from the iframe.
Thoughts?
Thanks!
If the iframe is on a separate domain, you can't access it directly via javascript from your other domain so you won't be able to directly transfer your cookie from domain1 to domain2 using javascript.
If you control code in both domains, then there are some workarounds. Here's one method that uses a single place to login and the login credential is transferred via URL parameters: Cross Domain Login - How to login a user automatically when transferred from one domain to another
You could conceivably use the URL transfer mechanism by logging in on the first domain and then setting the .src URL in the iframe to have the login credential in the URL. When the second domain loaded in the iframe, it would see the login credential in the URL, grab it, turn it into a cookie value that it wrote on itself and the refresh itself (thus now looking logged in). You will obviously need to control javascript in both domains to use either of these techniques because one domain's javascript can't put a cookie into the other domain directly.
Another way that two cooperating domains can communicate is with window.postMessage() so the login credentials could be sent to the iframe window. It's javascript would have to receive the message and turn it into a cookie and then refresh it's page so that the server saw the login cookie on the 2nd domain.
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.