3

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!

Seth
  • 6,240
  • 3
  • 28
  • 44
  • 2
    Why would you go back to HTTP after authentication?? Isn't the whole point to establish a secure encrypted session? – Pointy Jun 29 '11 at 13:54
  • While Pointy is pretty spot-on with his comment, I'd also add that you should make sure the iFrame that you drop onto the page has the proper src attribute by the time it makes it inline. Should it not have an https src when it is dropped onto the page and you then try to change it to an https src browsers will throw obnoxious pop up boxes at you. – MoarCodePlz Jun 29 '11 at 14:02

1 Answers1

2

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.

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
  • I've just remembered [this question](http://stackoverflow.com/questions/3144986/http-https-iframe/3183176#3183176) (almost a duplicate). – Bruno Jun 29 '11 at 17:07