Reputation: 21
On my website, I have several HTTPS pages and some HTTP pages. When a user logs in through HTTPS a cookie is stored containing email address etc. When a user clicks on a HTTP page of my website the cookie is lost since the cookie was created under HTTPS. So to solve that problem I added this PHP code in my HTTP pages:
session_start();
$currentSessionID = session_id();
I assume this takes the cookie that was stored for HTTPS pages and pulls it through so HTTP can see it? Is this a security flaw in any possible way? I am not sure if the cookie is actually being transferred over HTTP or if it is just pulling what the browser already stored in temp internet files?
Upvotes: 2
Views: 1008
Reputation: 67019
What you are trying to do is very insecure and a clear violation of OWASP A9. At no point can a session id that is authenticated or will become authenticated be exposed over HTTP.
Upvotes: 0
Reputation: 122880
Yes, if you ever set identifying cookies on an HTTP connection they can be hijacked and the account they identify can be compromised.
Sending session cookies over HTTP (which is actually a pretty common thing to do), is what allows Firesheep to work. The basic attack is:
The good news is that, the on-the-same-network-eavesdropping-attack is not a particularly practical attack for the most part. The only reason Firesheep works is because everybody in the entire world has a Facebook/Twitter/whatever account which means that when you connect to open wifi in a Starbucks there will be accounts to hijack.
What can you do?
If you don't what to do that you can rely on the fact that eavesdropping isn't a particularly practical attack and support for hijacking your site will probably only be implemented in Firesheep if your site is really popular ;-)
To address the specifics of your question a little more directly: If your HTTP pages can identify a user, then that user's account can be hijacked, since the only thing the server has to go on is the user's cookies.
Upvotes: 4