Recently I installed a certificate on the website I'm working on. I've made as much of the site as possible work with HTTP, but after you log in, it has to remain in HTTPS to prevent session hi-jacking, doesn't it?
Unfortunately, this causes some problems with Google Maps; I get warnings in IE saying "this page contains insecure content". I don't think we can afford Google Maps Premier right now to get their secure service.
It's sort of an auction site so it's fairly important that people don't get charged for things they didn't purchase because some hacker got into their account. All payments are done through PayPal though, so I'm not saving any sort of credit card info, but I am keeping personal contact information. Fraudulent charges could be reversed fairly easily if it ever came to that.
What do you guys suggest I do? Should I take the bulk of the site off HTTPS and just secure certain pages like where ever you enter your password, and that's it? That's what our competition seems to do.
I would take the bulk of the site off HTTPS with some exceptions of course:
- Any checkout or account editing screens.
- Any screens that would display "sensitive" information.
To deal with the session hijacking issue, I would add another layer of authentication where you prompt them for their username and password again at checkout or whenever they try to view/update account information - basicly whenever you make a transition from http to https.
Here's the issue, and why banks are still horribly vulnerable: their landing page is HTTP, so it can be man-in-the-middled. Then they have a link to the login, and the login page is HTTPS.
So if you go directly to the login page, you can't be Man-in-the-Middled. But if you go to the homepage/landing page, since I control that, I'm going to rewrite the login page link to be HTTP. Then I'll do a SSL handshake with the login page, and send you (the user) the insecure version. So now you're (the user) doing all your sensitive transactions - and the server thinks it's HTTPS - and I'm in the middle doing shenanigans.
This is a very hard problem to solve completely because it goes all the way down to the DNS level on the server-side, and all the way down to default actions in browsers on the client-side.
As a content provider, you could try putting in javascript to check that the secure areas of your site are being accessed securely (and hope that I, as a cracker, don't remove that js before forwarding it). You can also include your happy "Please make sure this site is accessed via https" banners.
As a user, NoScript has an option to make sure sites are in HTTPS.
There's a new technology (I believe it's a marker on DNS entries maybe?) not supported by all clients/servers that lets a server opt in and say it is only accessible via HTTPS and to die a fiery death if it's being MITM-ed. I can't for the life of me recall or able to find it on google though...
Yes, I would just use SSL to secure important elements such as input fields, passwords, etc. I believe that's what most sites do, including online banking sites.
来源：https://stackoverflow.com/questions/2899088/how-important-is-it-to-use-ssl-on-every-page-of-your-website