Secure form submittal

login,secure,form

[pmmenneg]

Have a potential silly/embarassing question, but it's late and I need a slap of reality right now.

Have a site I am working on that currently uses a pop-up style login method. Essentially, anywhere on the site the user can click 'login' ala Digg, etc and a dialog pops up that asks for user/pass.

Now, the problem with this is that the dialog contents will be the same protocol as the page that calls it, in that when the dialog is called from a non-secure page, the contents also are non-secure. The form then submits username/password to a secured via https script that processes the data and send them back out to wherever they were when they clicked login.

So I am having trouble getting my head around this for some reason... as it looks like lots of services, such as Facebook, Digg, etc send user/pass combos from non-secure input forms to secure authentication scripts... would the data not be exposed on it's way to the secure script, as we are just negotiating a secure connection? Wouldn't you want to have the input form secured as well, or am I missing something? And if you DO want the form itself secured, any ideas as to why Facebook, etc doing it the way they are? I only ask that last question, as it will be very tough to get away from the current method I am working on, and if a solution/workaround exists, I may need to employ it.

Sorry for the ramble, thanks for any help!

[incrediBILL]

would the data not be exposed on it's way to the secure script, as we are just negotiating a secure connection

The form data isn't sent until a secured connection is already negotiated by the browser.

[pmmenneg]

*slaps forehead*

Ok, of course, that makes sense, thanks for the response.

[rocknbil]

Just to make sure . . . you're on a non secure page, you do a new window (presumably by javascript or one of the open source thngamabobs, like lightbox) so it's this form that has to be via SSL.

it will be very tough to get away from the current method I am working on, and if a solution/workaround exists, I may need to employ it.

It's really quite easy. Presuming PHP, at the top of your login script,

if (! isset($_SERVER['HTTPS']) or ($_SERVER['HTTPS'] != 'on)) {
header("location:https://example.com/login-script.php");
}

You can apply that to the top of the script, or if you have non-secure functions, just where needed. That way you don't have to scramble around coding all your links to it for https, and lie awake at nights wondering if you missed one.

Second, **unless** you are using a method on your server where all secure content is housed in a different directory, always do

/path-to-images/test.jpg

Note the leading slash. This means you don't have to code a bunch of stuff to or from secure and non secure versions.

[pmmenneg]

rocknbil, thanks for the response. Here is a detailed version of what is happening:

User initiates login dialog (jQueryUI) from a non-secure page. jQuery then populates the dialog with the correct content via an ajax .load request. Due to XSS issues, this call is in the same format as the initiating page, thus non-secure. The load request goes to a .php script which responds with html content for the form.

So, now the user is looking at a popup dialog with form fields, all of which is non-secure. They eneter their data and it is submitted via form action to a secure [example.com...] script for processing.

I'm not sure where I could do as you say and redirect the php... when the script gets an ajax request, can I really redirect to a secure form of the script, then respond?

Paul

[Fotiman]

pmmenneg, as I think you've realized, as long as the form action goes to an "https://" address, then the form is secure. It doesn't matter if the page that serves up the form is secure or not, it's the transmitting of the form data back to the server that needs to be secure.

With that said, it's worth noting that browsers will usually identify secure connections somehow (with a lock icon in the status bar for example). Some users might not feel comfortable entering in secure data on a form that was not served over https (even though that's not what matters). Just something to keep in mind.

[pmmenneg]

Thanks for the clarification Fotiman. Consider this issue resolved... I of course, deep in the recesses of my mind had at one point know all this, but after 12+ hours of coding seemed to forget it :-|.