Is there a particular reason to submit to https from http in this instance? As far as I'm aware that is generally seen as a bad idea, at least as far as login forms are concerned.

Quote:Original post by superpig
Though it is frustrating that a request from the http version of a site to the https version of a site is considered cross-domain; the domain name and thus the set of IP addresses used in each case is the same, so I don't see any scenario in which you could control one but not the other, at least, not one that would otherwise be winnable (e.g. malicious router on the backbone routing things at the application level - it could do that for different file paths within an application, let alone different protocols).

My web hosting package allows you to serve content out of one directory on http:// and another on https:// (thankfully disabled by default), though even if one took advantage of that situation with malicious intent it's still a server-side issue, and I can't really see the point in trying to block that on the client.

Quote:When a cross-domain XHR fails under Firefox, there's no feedback as to why. There's no exception, no console message. The Net panel shows the requests that have been made - so you might see the OPTIONS preflight request, if one is made - but it doesn't tell you if/when it's discarding the results of a request (in response to security policy bits not being satisfied), or why. All you get is an empty XHR object in an error state.

Which is... difficult... to debug.

This is my finding with Firefox in general; it's generally quite unhelpful when it comes to security problems in JavaScript. [sad] Good luck finding a solution!

Quote:Original post by benryves
Is there a particular reason to submit to https from http in this instance? As far as I'm aware that is generally seen as a bad idea, at least as far as login forms are concerned.

Fact is, simply making the login page HTTPS isn't sufficient either to mitigate the problems he's describing. The examples he gives - of somebody messing with the login page to redirect or intercept the secured submission - those techniques can be applied to any page prior to the point where you go secure. All I need to do is get my own SSL cert that 'looks' like the real deal, set it up on a site which acts as a proxy to the real one, and then I can tamper with any HTTP page served to you and have it direct you to my proxy (at which point you can browse for as long as you like before handing over the sensitive data). If you're not checking out the cert closely, you'll still get caught; the only solution is to make the entire site HTTPS, which is too computationally expensive.

I'm doing this mainly because I want the ability to do logins from every part of the site, dynamically (and indeed perhaps from other apps as well); what I can do as well is to offer a 'secured login' page which is served over HTTPS and which points to the things that people should be checking to see that the page is secure. Most people won't bother with it but particularly security-conscious people could do.

Quote:My web hosting package allows you to serve content out of one directory on http:// and another on https:// (thankfully disabled by default), though even if one took advantage of that situation with malicious intent it's still a server-side issue, and I can't really see the point in trying to block that on the client.

Right; the fact that there's separate content under each protocol isn't really significant, because you still control both directories. It's decidedly difficult to conjure a scenario in which your HTTPS has been compromised and your HTTP hasn't. (The inverse is perhaps easier...)

Quote:This is my finding with Firefox in general; it's generally quite unhelpful when it comes to security problems in &#106avascript. [sad] Good luck finding a solution!

Indeed; thanks. As it stands I've actually abandoned the Access-Control header stuff for now, and have just gone with a jsonp approach instead - cross-browser and generally more robust. Probably worth doing the full solution later on as it's slightly more performant, but I'll wait until such a time as the tooling is there to help me out.