Mike
Mike

Reputation: 21

Security concern when I transfer cookie session from HTTPS to HTTP

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

Answers (2)

rook
rook

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

Aaron Maenpaa
Aaron Maenpaa

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:

  1. User logs in over HTTPS (this is secure).
  2. The server sets a session cookie so that is can identify the user.
  3. The user starts browsing pages over HTTP, which by definition involves sending the session cookie to the server unencrypted.
  4. All of this is really common. Lots of sites (including Stack Overflow) only use HTTPS for log-in pages and then serve the rest of the site over HTTP. The nasty part is that an attacker on the same network can listen in for HTTP traffic, look for session cookies and then use them to impersonate the user they identify. This is what Firesheep does: You can go to a Starbucks, connect to the wifi, turn on Firesheep and hijack other people's Facebook and Twitter accounts.

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?

  • Set your cookies to be "Secure" so that they are only ever sent over HTTPS.
  • Set up your entire site to be served over HTTPS and redirect all authenticated users to the HTTPS resources.

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

Related Questions