11-23-2007, 08:54 AM
I've to use an SSL to my login page, and I wish to use the shared SSL provided by the host(ipower).
my login page is located at http://mydomain.com/login.php, and through SSL my site can be accessed as https://host298.ipowerweb.com/~mydomain/
I've a intermediate page (for validation) and after a successful login the user will be redirected to his profile page.
I can access my pages through the above https link, but all my current links are just href="login.php". (and there are some header() redirects from some other pages to this.)
In this scenario please give some guide lines to effectively use this SSL to make my login system secure. (How can I ensure that the login.php is accessed only through SSL)
11-23-2007, 07:46 PM
Here is a little SSL cookie/session id cookie 411 to get you started -
You are probably using either a cookie or a session (defaults to passing the session id in a cookie between pages) to remember that a visitor is logged in. Cookies (regular or session id) are not passed back and forth between pages reached through the http and https protocols (browsers don't permit it), and in your case where the domain changes, cookies cannot be passed between domains.
A common, but improper way to do this is to pass a piece of information as a parameter on the end of the URL (a session id or an other unique ID that identifies the visitor and indicates they are logged in.)
The problem with the above method is that the whole purpose of using SSL to encrypt data going back and forth between the browser and the server is so that if someone is monitoring data packets they cannot get a copy of the data and use it.
Using the above method, as soon as a page is visited just using the http protocol, any parameter on the end of the URL could be seen and someone could immediately make a request to your web site and appear to be that logged in visitor. They could even make a https request with that parameter on the end of the url and do or view anything on the pages that are normally reached using the https protocol.
The reason why browsers don't pass cookies/session id cookies between the http and https protocols is to prevent the above problem with security. The expected method is - 1) you NEVER pass any session id on the end of the url back and forth (either direction is bad) between pages reached through the https and http protocols, and 2) if you have some information that needs to be sent using https, keep using the https protocol for all the necessary pages (you can pass cookies and session id cookies between pages that are reached using the https protocol.)
If using sessions on a page that was reached using the https protocol, you must make sure you don't deliberately or allow PHP to automatically append a session ID on the end of the url. So, if you accidentally link to or redirect to a http address, you don't expose the session id.
PHP receives a $_SERVER['HTTPS'] (non-empty if the request was made through https) variable so that you can check which protocol a page was reached by. You need to check on any pages that you only want to be reached through the https protocol and either display a message that the page was reached incorrectly and/or redirect to the correct https URL. You always need to do this in case someone manually types a URL to your site but leaves off the https:// or leaves the "s" off of the http://.
You also need to make all of your links and redirects to the proper absolute https URL. If you don't do this and rely on redirecting non-https address to the corresponding https address, the browser's address bar (made worse due to the completely different URL when using a shared ssl certificate) and the "lock" symbol, will keep changing, causing your visitor additional concern about how secure your site is.
I recommend using a configuration variable or defined constant that you use in all the links and redirects, that holds the root/base portion of the https://URL, so that if it should change (you change hosts or get your own SSL certificate), you can just change it in one place.
11-24-2007, 09:07 AM
Many thanks CFM, your explanation is perfect and I've been facing an unexpected logged-out problem due to this switching of domain and protocol.
Now I'm more clear about the problem. When I post data from my login.php (https://host298.ipowerweb.com/~mydomain/login.php), the validate.php also take the same domain name and protocol and create a session here(on success). Since I don't want to use this domain name and protocol in any other pages, I used a header("location:http://mydomain.com/profile.php') , but this caused the above mentioned logged-out problem as there is no valid session to access profile.php (using mydomain.com and http protocol)
Now let me ask one more question. I believe only the login.php requires https, can I call my validate.php like
<form action="http://mydomain.com/validate.php" method="post">
so as to create the session in http://mydomain.com instead of https://host298.ipowerweb.com/
11-24-2007, 03:55 PM
When a form that was gotten through the https protocol submits to a http url, you get a nasty browser popup security message warning you that you are attempting to submit secure data over a non-secure connection.
If you submit to a https address, then the form information will be sent over a secure connection, which is probably what you want. If you submit to a http address, ignoring the security popup, then the protocol changes, then the form data is sent, which is probably not what you want.
Using https to log someone in and then switching to http and passing a cookie/session id cookie back and forth so that it could be stolen in transient and used by someone else to start a browser session and appear like they are the person who logged in. defeats most of the point of logging them in using https. Consider the case of your online banking. They log you in over a https connection and you continue using a https connection until after you log out.
11-24-2007, 04:23 PM
Is there any cache issue(heard that browsers don't cache https pages) to use https all over the site? (websites like gmail and yahoomail use https only for the login page)
11-25-2007, 11:56 AM
Well, my website has a simple CMS, where users can manipulate some contents and admin-user has some extra privileges as in the case of every system. The login form is located in the home-page itself and users have limited access to some pages without a login and get more powers after they get logged in.
But the problem is, due to some poor design issues, an intruder can make severe damage to the system (though it is not an online banking ;)). So in research of adding security I just came to SSL. But I know almost all public forums are running on http (including CF). Is there any other way?
11-25-2007, 04:05 PM
...the whole purpose of using SSL to encrypt data going back and forth between the browser and the server is so that if someone is monitoring data packets they cannot get a copy of the data and use it.But the problem is, due to some poor design issues, an intruder can make severe damage to the systemIs there any other way?Let me see. SSL encrypts data going back and forth between the browser and the server. You have a problem with a poor design and coding that make it possible for an intruder to inject content and/or take over the system. Probably correcting the design and coding problems would be the way to go. Using SSL for your login would only mean that the intruder would need to enter https://your_site.com instead of http://your_site.com in his browser to login (assuming that it is even necessary to login to accomplish what ever is being exploited in the design and code.)
Slapping SSL onto a login page is not going to fix an insecure design and insecure coding. SSL, just being a protocol to connect to the server, has got nothing to do with what code on the server is doing.
You have got to find and address the real problem instead of trying to slap a band-aid on it.
11-25-2007, 04:46 PM
Sorry, what I meant is, if admin delete a thread, all related data and files will get lost. So if admin account gets hacked, my data will become irrecoverably lost. And I donít think there is any sql injection problem.
Iíve heard about website sniffing (donít know the details though ;)), and SSL can prevent this by encrypting data before sending to server. Here I just want to ensure the username and passwords are secure from such people. Please correct me if I'm thinking in wrong(stupid) way.