views:

295

answers:

4

I have a PHP-Apache application using mod_rewrite for clean URLs. I am having a lot of touble getting certain pages and paths forced to HTTPS while also ensuring all others will remain as HTTP.

Here is an example of what I mean:

// http://www.example.com/panel/ -> Should always redirect to HTTPS
// http://www.example.com/store/ -> Should always redirect to HTTPS

// Anything not in the above should always be HTTP
// so...
// https://www.example.com/not-in-above-rules -> Should always redirect to HTTP

Any ideas?

A: 

to do it:

RewriteCond %{HTTP_HOST}         ^www.example.com(:80)?$

RewriteRule ^/panel/(.*) https://www.example.com/panel/$1 [R=301,L]

the same for the other path

Hope it helps

Ass3mbler
This won't also redirect HTTPS that don't match the pattern to HTTP
Nat Ryall
put th :80 part out of the ()? quantifierRewriteCond %{HTTP_HOST} ^www.example.com:80$ORRewriteCond %{HTTPS} !=onORRewriteCond %{SERVER_PORT} !^443$
Ass3mbler
of course you can use any or all the three RewriteCond before the RewriteRule directive
Ass3mbler
Thanks for your help but I think you're missing the point. That rule will redirect HTTP to HTTPS but not HTTPS to HTTP for all URLs that don't have `/panel/` in.
Nat Ryall
+1  A: 

The general rule of good security is: if some of your site requires HTTPS, then all of your site requires HTTPS. If you will be using HTTPS in the payment section, then your landing page should be HTTPS as well.

Justice
I'd be interested to know why you say this? HTTPS hits performance significantly enough to be avoided when not required IMHO. Then again, you're probably right when it comes to sending and receiving any sort of data and not just payment details. I just don't see why it's necessary for pages where no data is transferred other than responding to the request.
Nat Ryall
The regular part of your site cannot be *trusted* if it is not delivered over HTTPS. One attack vector is to MIM if the regular part of the site is not delivered over HTTPS and rewrite the links to the payment part to an attack site. So the links are delivered by your site, but nevertheless are not trusted - they can be rewritten by an attacker.
Justice
That's fair enough but is the security payoff from MIM protection really worth the HTTPS requests? Amazon don't seem to think so.
Nat Ryall
I wouldn't be too worried about performance until you actually start having problems. Compared to parsing PHP scripts, opening database connections, rendering templates, etc., the overhead from an optimized SSL library is minimal. And yes, the security benefit is that: *your site is trustworthy as soon as the user visits it*.
Justice
+3  A: 

You can put something like this in your :80 vhost:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(panel/|store/payment) https://%{HTTP_HOST}%{REQUEST_URI}

And this in your :443 vhost:

RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule !^(panel/|store/payment) http://%{HTTP_HOST}%{REQUEST_URI}
tersmitten
Great answer, thanks!
Nat Ryall
A: 

None of these solutions works with pretty url's. One suggestion: we were getting browser security warnings just using the http_host in the rewrite. Evidently, Thawte is retarded and therefore prefixing with 'www' or not makes a difference as to the perceived validity of the certificate. Here are a few lines to ensure that redirects to the secure site are always prefixed with 'www':

RewriteCond %{HTTP_HOST} ^www\.mysite\.com [NC]
RewriteRule ^(login\.php|members\.php)$ https://%{HTTP_HOST}%{REQUEST_URI}
RewriteCond %{HTTP_HOST} ^mysite\.com [NC]
RewriteRule ^(login\.php|members\.php)$ https://www.${HTTP_HOST}%{REQUEST_URI}

Or to do it in a little less space, you could drop the 2nd line and hard-code the domain in the 4th. I'm sure there's a more elegant way of doing it, but htaccess is frustrating, and this works.