36

As discussed in this question on Meta.Security.SE, the SE OpenID provider seems to be using some sort of AJAX call to replace part of the page. The outer page uses plain HTTP, whereas the OpenID part (when the SE provider is chosen) seems to be using HTTPS (only visible if you use Firebug or similar).

This is a bad use of HTTPS, as detailed here or, as OWASP puts it:

The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location.

Whether SE uses HTTPS globally is a different matter, but the login page should visibly use HTTPS.

Improve this question
1

2 Answers 2

Reset to default
4

An easy fix for this, which would put the SE OpenID provider at the same level as the other OpenID providers with an icon on that login page would be to make that SE button redirect to https://openid.stackexchange.com/account/login, instead of putting it all within an iframe.

That's better than asking users (who'd be unaware about these issues) to fill in openid.stackexchange.com manually.

(Of course, the link in the button could possibly be altered by an MITM attacker too, but the point of this is also to get users used to the fact they should expect the full page to be visibly using HTTPS when they enter their passwords.)

Improve this answer
3

This isn't invalidating your point, but two things should be noted.

  1. You write

    the SE OpenID provider seems to be using some sort of AJAX call to replace part of the page.

    which is just plain wrong. It's not using an AJAX call; the login form is embedded in an IFRAME. Just inserting content you get from an AJAX call into the DOM is a totally different ballpark of vulnerability.

  2. You can, if you want to, achieve what you're asking for (for yourself anyway). While clicking the "log in with StackExchange" button shows the email/password form embedded in the page, you can instead enter openid.stackexchange.com in the "manually enter your OpenId" field (part of the "more login options").

    That will treat SE OpenId like any other OpenId provider and thus redirect to https://openid.stackexchange.com/account/login.

Improve this answer
3
  • 1
    I must say I used the expression "some sort of AJAX" precisely to stay vague, if that makes sense. I just noticed it was making some asynchronous requests (perhaps due to elements included in the iframe), but didn't look into the code. Since the choice page itself is in plain HTTP, a MITM could alter it via AJAX, by changing the iframe target and/or by changing the page before it was first loaded. The programming technique doesn't matter that much here.
    – Bruno
    Apr 10, 2012 at 10:21
  • 1
    It matters a lot. "Staying vague" to make an issue you point out (the sentiment of which is valid) sound worse than it actually is is insincere. The problem with a cross-protocol IFRAME is that its security is not immediately visible and thus not easily verifiable by the user. I agree with that. However it is verifiable and thus exists, while what you're hinting at is that there is no security in the first place.
    – balpha StaffMod
    Apr 10, 2012 at 10:54
  • 7
    I just didn't want to enter into a debate about what's AJAX and what's not. It might not involve any XHR, but it does involve some JavaScript and makes asynchronous requests. Actually, I've just checked the code. It does insert an iframe element in the DOM that wasn't there when the page was initially loaded. I'd put that under the AJAX umbrella (even without XHR).
    – Bruno
    Apr 10, 2012 at 11:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .