Secure login block

Just wondering... To go around the problem of getting all the pages on HTTPS when using the default Log in block...

Could we create a new block in this module that creates an IFRAME for the Log in? I know that the size of an IFRAME can be set to 100% in width, so we should be able to match any column. The height is a different problem though.

The IFRAME would then be on HTTPS, but not the full page.

Thank you.
Alexis Wilke

I have the same kind of problem :

I use the block login on my home page, but i don't want my home page to use HTTPS.
But here the module use session443_form_user_login_alter to redirect to HTTPS, so my home page is redirect automaticaly to HTTPS.

If I remove that, the users will login on HTTP and the cookie is created on HTTP and even if I redirect to HTTPS the cookie is not created for HTTPS and my user appear not loggued.

I'm looking for a solution. I think the iframe login block should fix that but it seems that it's a big work for me.

This seems to work, if I'm not missing a security issue.

function session443_form_user_login_block_alter(&$form, $form_state) {
  if (!$_SERVER['HTTPS']) {
   // _session443_redirect(); // redirects session to https.
   // Change block form urls instead
   global $base_url;
   $form['#action'] = str_replace('http','https',$base_url).$form['#action'];
  }
}

Derived from https://drupal.org/node/577696

This looks correct to me. But since this is a security issue someone else should weigh in as well.

We should use a preg_replace() so we can be sure to change the first occurrence of http and not any occurrence.

$form['#action'] = preg_replace('/^http/', 'https', $base_url) . $form['#action'];

Although it is very unlikely that $base_url includes 'http', it is possible. http.com exists, for instance.

Another potential problem, the $form['#action'] already includes a full URL. I think that there is an option you can use to do that in Drupal... Actually, wouldn't $form['#action'] already include $base_url?

Something like this maybe?

  // The form action points to a secured path.
  if (strpos($form['#action'], 'https://') === 0) {
    // Do nothing, we're in the clear.
  }
  // The form action points to an unsecured path.
  elseif (strpos($form['#action'], 'http://') === 0) {
    $form['#action'] = preg_replace('/^http/', 'https', $base_url) . $form['#action'];
  }
  // The form action points to a relative or internal URL.
  else {
    // Form action is a relative path previously passed through url().
    if (strpos($form['#action'], base_path()) === 0) {
      // Strip off the base path.
      $form['#action'] = preg_replace('/^' . str_replace('/', '\/', base_path()) . '/', '', $form['#action']);
    }
    // Compile an absolute URL.
    $form['#action'] = preg_replace('/^http/', 'https', url($form['#action'], array('absolute' => TRUE)));
  }

From a security point of view, it is considered poor practice to ask the user to fill in sensitive information on a form on an unsecure page even if that form submits to a secure page. While the information itself is encrypted and "secure" the setup as a whole is not - users need to be able to check for the padlock/certificate in their browser before submitting the form (of course, many users will not even do that - but we should give them a chance!). Unless users are going to read the source code (oh, and the javascript too), they have no idea if the form is really going to submit securely or not. If they are on a hijacked connection, the attacker simply needs to alter the form on the unsecure page to submit to an unsecure destination, and they are in. If the initial form is on a secure page and users know to expect that, then this attack is much much harder to do without at least causing SSL warnings.

Owen,

That's what I do with all my forms. And I have to remember to edit the secure page settings to add the URL of each page with a form that I want to be secure (i.e. the search form is not secure... sorry!)

Thank you.
Alexis

Thanks for your input everyone. In the latest dev version (only D6 for now) there are admin options to choose how to handle the login block. I based the form action altering off of Damien's version.