23

I've made a website which has registration/login. I can see the PHPSESSID cookie in Chrome's Developer Tools, so I'm wondering how can I use this session id value to hijack into the account I'm logged, from let's say a different browser, for simplicity's sake?

Should a secure website be able to determine that this session is being hijacked and prevent it?

Also, how come other big sites that use PHP (e.g. Facebook) do not have PHPSESSID cookies? Do they give it a different name for obscurity, or do they just use a different mechanism altogether?

Chenmunka
  • 685
  • 4
  • 21
  • 25
hesson
  • 1,812
  • 4
  • 23
  • 35

3 Answers3

20

Lots of good questions, and good on you for asking them.

First.. a session is just a cookie. A 'session' is not something that's part of the HTTP stack. PHP just happens to provide some conveniences that make it easy to work with cookies, thus introducing sessions. PHP chooses PHPSESSID as a default name for the cookie, but you can choose any you want.. even in PHP you can change the session_name.

Everything an attacker has to do is grab that session cookie you're looking at, and use it in its own browser. The attacker can do this with automated scripts or for instance using firebug, you can just change the current cookie values.

So yes, if I have your id.. I can steal your session if you didn't do anything to prevent it.

However.. the hardest part for an attacker is to obtain the cookie in the first place. The attacker can't really do this, unless:

  • They have access to your computer
  • They somehow are able to snoop in on your network traffic.

The first part is hard to solve.. there are some tricks you can do to identify the computer that started the session (check if the user agent changed, check if the ip address changed), but non are waterproof or not so great solutions.

You can fix the second by ensuring that all your traffic is encrypted using HTTPS. There are very little reasons to not use HTTPS. If you have a 'logged in' area on your site, do use SSL!!

I hope this kind of answers your question.. A few other pointers I thought of right now:

  • Whenever a user logs in, give them a new session id
  • Whenever a user logs out, also give them a new session id!
  • Make sure that under no circumstances the browser can determine the value of the session cookie. If you don't recognize the cookie, regenerate a new one!
double-beep
  • 5,031
  • 17
  • 33
  • 41
Evert
  • 93,428
  • 18
  • 118
  • 189
  • Thanks, I was playing around with the cookies on facebook and found that after deleting the cookie called `c_user`, I was logged out on the next refresh, so I guess they use some kind of token. Weird thing I found though is that it is a 9 digit integer as opposed to the 26 digits (both letters and numbers) I found for my website's PHPSESSID. – hesson Aug 05 '12 at 20:47
  • 3
    facebook likely uses a combination of things. That may have just been some user id, and a different cookie to verify it's authentic – Evert Aug 05 '12 at 20:48
  • You're right. Facebook uses the `xs` cookie as verification in combination with `c_user` for the user id. Both expire on session end, so it makes sense. – hesson Aug 05 '12 at 21:00
  • -1 Your explanation is misleading when you say that “sessions are just cookies” or that “sessions are a convenient way to work with cookies”. Both is wrong. Cookies and sessions just have one thing in common: They can be used to store data over multiple requests. But that’s it. Anything else is different: cookies are stored on the client side while sessions are stored on the server side. And this is the most important difference as a cookie’s data is opaque and session’s data is transparent to the user. – Gumbo Aug 06 '12 at 05:27
  • @Gumbo: sessions are completely handled by cookies. When we're talking about sessions in the PHP sense, it's still a cookie that handles it. – Evert Aug 06 '12 at 13:37
  • @Evert No. The cookie is only used to store the session ID on the client to make it available on subsequent request. You could also use other means of transportation like the URL (see [.NET’s cookie-less sessions](http://msdn.microsoft.com/en-us/library/aa479314.aspx) for a well-known example). But the whole session management is done server-side, mainly maintaining the values and the session’s expiration. Have a look at [*Is my understanding of PHP sessions correct?*](http://stackoverflow.com/q/523703/53114) for some insights into PHP’s internals. – Gumbo Aug 06 '12 at 18:09
  • @Gumbo: I'm well aware of how sessions work. If you indeed use url-based sessions in PHP you're making a grave security mistake. 99% of the cases the session is cookie based, and you're just being pedantic at this point. – Evert Aug 06 '12 at 19:33
  • The only point I wanted to make really, was that sessions and cookies are not two completely different systems. Sessions use cookies to do their thing, so all cookie-related security issues apply here too. If you are actually using or suggestion url-based session keys you should get a better understanding of sessions yourself ;) – Evert Aug 06 '12 at 19:38
  • @Evert You’re right when saying that sessions and cookies are not completely different as both are some sort of data storage technique. But they aren’t that similar either. In fact, the main and most important difference is the storage location: cookies are stored on the client side and sessions on the server side. And this does also dictate the party who has control over it: Cookies are in control of the client while sessions are in control of the server. – Gumbo Aug 07 '12 at 00:16
  • Your kind of thinking that sessions and cookies are quite similar often results in thinking that for invalidating a session it suffices to delete the session’s cookie. But as the session is managed by the server, the session is would still available. – Gumbo Aug 07 '12 at 00:19
  • @gumbo: you just missed my point again, and then stating the obvious and repeating your previous points. I'll leave this discussion because I don't think anything will come from it. – Evert Aug 07 '12 at 00:51
  • "The attacker can't really do this, unless [...]" If the site has an XSS vulnerability, then it's pretty easy to grab the cookie remotely. No need to access the victim's computer or snoop in on his/her traffic. – jub0bs Nov 16 '18 at 19:23
6

If you're on the same IP and using the same browser, all you have to do is duplicating the session ID (and maybe other cookie values: not really sure if browser specific things like its agent string is tracked/compared; this is implementation dependant).

In general, there are different ways to track users (in the end it's just user tracking). For example, you could use a cookie or some hidden value inside the web page. You could as well use a value in HTTP GET requests, a Flash cookie or some other method of authentication (or a combination of these).

In case of Facebook they use several cookie values, so I'd just assume they use one of these values (e.g. 'xs').

Overall, there's no real 100% secure way to do it (e.g. due to man-in-the-middle attacks), but overall, I'd do the following:

  • Upon logging in, store the user's IP address, his browser agent string and a unique token (edit due to comment above: you could as well skip he IP address; making the whole thing a bit less secure).
  • Client side store the user's unique id (e.g. user id) and that token (in a cookie or GET value).
  • As long as the data stored in first step matches, it's the same user. To log out, simply delete the token from the database.

Oh, and just to mention it: All these things aren't PHP specific. They can be done with any server side language (Perl, PHP, Ruby, C#, ...) or server in general.

Mario
  • 35,726
  • 5
  • 62
  • 78
  • +1 for mentioning xs. Evert was right about the c_user cookie on facebook. It stores the user id. It works in combination with the xs cookie to verify a login. – hesson Aug 05 '12 at 20:56
2

Someone sniffs the session ID cookie and sets it for a subsequent request. If that's the only thing authenticated a user, they're logged in.

Most sites will use authentication based on cookies in some form. There are several ways to make this more secure such as storing info about the user's browser when they log in (e.g. user agent, IP address). If someone else naively tries to copy the cookie, it won't work. (Of course, there are ways around this too.) You'll also see session cookies being regenerated periodically to make sure they aren't valid for a particularly long time.

Check out Firesheep for a Firefox extension that performs session hijacking. I'm not suggesting you use it, but you may find the discussion on that page interesting.

Michael Mior
  • 28,107
  • 9
  • 89
  • 113
  • How come copying the cookie doesn't work, if say, the session ID hasn't changed since the copy took place, why wouldn't it work? I do use `session_regenerate_id(true)` regularly on my PHP pages for more security. I don't want to check the user's IP address, because for some users that changes frequently for legitimate reasons. – hesson Aug 05 '12 at 20:36
  • If the only mechanism you use is a session cookie, copying its value should work to authenticate the user. (It works here on StackOverflow for example.) You're right about checking the IP address, it's not the best method. – Michael Mior Aug 06 '12 at 12:11