Fail to understand session hijacking etc

PHP
1

Hi,

I’ve read so many articles on session hijacking / fixation in php and people were discussing techniques also to avoid them but after reading almost all articles / discussions I only think that if session hijacking / fixation was successful then it only happened because the user’s PC / device was compromised in some way and that’s how the attacker got the session id.

Am i correct ? Is that the nutshell or am I still not getting it ?

Thanks.

1 Like
2

That’s not entirely correct. In order to hijack a user’s session, the hijacker must have the session identifier. In order to get the session identifier, the hijacker needs to use one of the following three method:

  • Prediction. This is where the attacker guesses the session identifier. This really shouldn’t be too much of a worry.
  • Capture. This is where an attacker gets a user’s session identifier. Cookies are the prominent way to propagate a session’s identifier (since URI’s are the only other method, and they definitely aren’t as secure due to their exposure), and so cookies are a primary target of the hijacker. Cookies can be hijacked via browser vulnerabilities (like those seen in earlier versions of Internet Explorer), or via XSS attacks if the web developer didn’t bother to explicitly create the cookies as HTTP only (making it so that JavaScript cannot get them). Another method to capture a user’s session identifier (as you have already said) is having a compromised PC.
  • Fixation. This is where the attacker tries to fixate the user’s session by using PHPSESSID in the query string of the URI. This method used to be a lot easier when sessions identifiers were propagated via URIs. In newer versions of PHP, the php.ini value for session.use_trans_sid is not turned off by default, making session fixation of little-to-no worry to the end user.

Thus, there’s a number of ways an attacker can get at your session ID, though it is becoming increasingly difficult.

On another note, I wrote a security-based article for another forum that you may be interested in looking at (a subsection is dedicated to session security): The PHP Security Series. (I believe you require an account to view it though.)

2 Likes
3

Hi,

Thanks for the info. Just need to clarify some points:

  1. As you say that Prediction and Fixation are little-to-no worry now a days.
  2. And in Capture method you pointed that earlier version of IE had the issue which led to hijacking etc. So this shows that the script was fine, it was the user’s browser that led the attacker to get the session id and hijack etc.
  3. Can you please shed some more light on this “via XSS attacks if the web developer didn’t bother to explicitly create the cookies as HTTP only (making it so that JavaScript cannot get them)”. I want to know how a developer did’nt borther to create the cookies as HTTP only ? Any example please ?

Thanks.

4

It doesn’t have to be the browser that is hacked.

If the session is running using HTTP instead of HTTPS then the sessionid is passed back and forth to the server in plain text even if it is stored in a cookie. It can then be captured without needing to access the computer running the browser.

1 Like
5

Hi,

I am presuming that the reply is in context to my point number 3 ? So putting website on https solves all XSS and Session Hijacking attacks ? So why do coders do database token’s confirmation etc ?

Thanks.

6

No - doing that just prevents anyone intercepting the information in between the server and the browser. It still leaves open the possibility of hijacking within the browser itself.

7

Yup, exactly. Sending a session ID unsecured across the Internet is almost as bad as sending the user’s password unsecured across the Internet. If intercepted, either will allow an attacker access to your account.

When a user is logged in, all traffic should be over HTTPS… cough, cough SitePoint

8

HTTPS encrypts the data so it cannot be intercepted, correct ?
How do we tackle the possibility of hijacking within the browser itself ?

Thanks.

9
  1. validate user input
  2. don’t reuse the same field for tainted and untainted data (tainted means it hasn’t - or may not have - been validated)
  3. Sanitize and data that the user isn’t supposed to be able to access and change but where they could if they knew how.
  4. Keep data and code completely separate where ever possible (eg. using prepare and bind for database calls where the code goes in the prepare and the data goes in the bind).
  5. escape data where you can’t avoid it being jumbled with code (eg escape any data that is allowed to contain a < or & character if you are going to jumble it with HTML)

There are more precautions to take to cover specific security issues but those 5 will cover most of the possibilities (even though all 5 are related more to good programming practices rather than being specifically for security).

While those actions are more appropriate to server side code than to JavaScript running in the browser, there is nothing you can do with JavaScript that is security related. Not only is security built into the browser to block JavaScript from creating security issues except via the server but your visitors can also turn JavaScript off or write their own and add it to your page so any security issues for the browser are done through server side processing.