6 replies [Last post]
shopaholic's picture
Offline
Joined: 09/24/2010
Juice: 32
Was this information Helpful?

I think I've now been able to setup a secure shopping site and I'm posting the experience here.

It's been a frustrating experience and I hope others can use this information while I'm open to any critique, especially if anybody can point out security deficiencies.

The shopping site should allow both http and https connections. I want visitors to default to http while any cart or checkout pages are to be served using https.

I've run into the situation where an anonymous user adds an item to their cart and the cart shows up empty. My anonymous user has uid == 0 (although the role id == 2 for anonymous).

I've been able to get the anonymous user to add items to their cart when accessing the site using https, however the cart shows up empty whenever the user accesses the site afterwards using http.

I've used the "Secure Pages" module, the "Ubercart SSL-module" and the "Secure Pages Hijack Prevention" module with varying levels of success.

First of all, if an anonymous user adds an item to their cart while using http and the cart shows up empty (in https), then it's possible that session.secure_cookie is on. This also occurs if anonymous adds an item to their cart using https and then switches back to http. The cart is emptied as soon as anonymous hits the site using http coming from https.

Explicitly disabling this in the (apache) site's configuration:

php_flag session.cookie_secure off

I have "Secure Pages" enabled but I'm not exactly sure if it's working. The fields for a secure and non-secure URL seem to be somewhat misleading. IIRC, http://fqdn is not a URL while http://fqdn/ is a (valid) url. "Secure Pages" seems to want a(n invalid) URL (without the trailing slash). Even if I enter http://fqdn and https://fqdn for non-secure and secure base URL (respectively), the module doesn't seem to do its job. I have enabled "Make secure only the listed pages." and the listed pages are:

node/add* node/*/edit admin* cart* user*

Still, the ubercart (cart & checkout) pages show up using http. It doesn't matter if I use '*cart*', '*cart/*' or even '*cart* *cart/* cart cart*', the ubercart cart & checkout pages are served using http.

I've used the ubercart ssl module but that lead to inconsistencies and the cart would frequently show up using http instead of the expected https.

With '$base_url' set to 'https://fqdn', I've setup apache to perform the following redirect:

<VirtualHost x.x.x.x:80>
ServerName http://fqdn
Redirect /cart https://fqdn/cart
...
</VirtualHost>

Now 1. anonymous users don't get an empty cart when adding an item to their cart, 2. anonymous users maintain their cart when they perform an http->https or https-> http switch and 3. all access to the cart (and checkout) is served using https.

I'm still a bit concerned about potential cookie-hijacking when alternating between http and https although the SP Hijacking Prevention module is enabled.

I'm sorry if I can't point out which module (setting) or apache directive causes this to break or what the exact behaviour is when one deviates from this setup, but at least this setup seems to do the job.

ergophobe's picture
Offline
Joined: 06/21/2010
Juice: 115
Re: Setting up SSL-secured shopping site

I thought I'd just add in some links to other people with similar solutions. I'm not sure these will help you, but they might give some additional context to future readers

http://www.missingubercartmanual.com/Configuring-Your-Site-For-HTTPS-whe...
http://www.runssl.com/content/how-redirect-drupal-or-ubercart-ssl-connec...
http://crackingdrupal.com/blog/greggles/drupal-and-ssl-multiple-recipes-...

Also the two modules you mention, linked up for others
http://drupal.org/project/securepages
http://drupal.org/project/uc_ssl

shopaholic's picture
Offline
Joined: 09/24/2010
Juice: 32
Redirect vs Modules

Thanks for the links.

What I'd like to highlight from my experience is that using modules to enforce certain sections of the site to be served using https is not very reliable. I'm more confident with the redirect in place. I have Secure Pages enabled because I want to enable the (cookie) Hijacking Prevention, but other than that it's not being used and hasn't been very predictable.

ergophobe's picture
Offline
Joined: 06/21/2010
Juice: 115
Re: Redirect vs Modules

Thanks for the heads up. I think the author of the first page I linked to reported similar issues and has a response from the author of Ubercart SSL saying that it works for "about 80%" of server configs, which leaves a pretty substantial 20% who will have issues. I guess you're one of those Sad

shopaholic's picture
Offline
Joined: 09/24/2010
Juice: 32
Rewrite

To avoid urls like http://www.example.com/cARt still going to the insecure version, use a rewrite instead of a redirect in apache. The rewrite allows the match to be case insensitive.

<VirtualHost x.x.x.x:80>
ServerName http://www.example.com
RewriteEngine on
RewriteRule ^/user(.*) https://www.example.com/user$1 [L,NC,R=permanent]
RewriteRule ^/cart(.*) https://www.example.com/cart$1 [L,NC,R=permanent]
#Redirect permanent /user https://www.example.com/user
#Redirect permanent /cart https://www.example.com/cart
...

ergophobe's picture
Offline
Joined: 06/21/2010
Juice: 115
Re: Setting up SSL-secured shopping site

Good catch shopaholic.

Another thing people don't realize is that .htaccess and httpd.conf rules do *not* execute in the order given in the file, but in the order the modules are loaded.

What this means is that if you mix Rewrites and Redirects, you can get unpredictable results, where you might have the Redirect last, but it will execute first.

Since you almost certainly have mod_rewrite enable and are using Rewrites with Drupal/Ubercart, it is best to avoid doing URL rewriting/redirecting with any other module.

hjmichael's picture
Offline
Joined: 10/05/2010
Juice: 12
SSL site

I have an SSL site working with secure pages, but in order to get it to work properly I had to apply a patch to secure pages. The attached file is the patch that I applied.

AttachmentSize
secure_pages.patch 900 bytes