Session fixation attack replication, term paper (php)

Question

I'm trying to replicate session for my term paper and I've found quite a bit tips here, but can't replicate an attack on my localhost.

I've tried an example from here: http://www.devshed.com/c/a/PHP/Sessions-and-Cookies/2/

fixation.php:

  <?php 
  session_start(); 
  $_SESSION['username'] = 'chris'; 
  ?>

test.php

  <?php 
  session_start(); 
  if (isset($_SESSION['username']))
  { 
    echo $_SESSION['username'];
  }     
  ?>

Article says I should be able to fixate session with:

http://example.org/fixation.php?PHPSESSID=1234

But inspecting the request headers it doesn't seem to work:

Cookie  PHPSESSID=0avpo8ttlmg35apkjaovj6dgd3

Also, there is an "sess_0avpo8ttlmg35apkjaovj6dgd3" file in tmp folder.

I'm kind of lost here and have tried more than a few similar examples that didn't work...

---

A little update
in php.ini, setting these values:

session.use_trans_sid = 1 
session.use_cookies = 0 

and commenting out session.save_handler disables saving session in cookie and generating tmp file (i presume, please correct me if I'm wrong). Now I'm able to fixate the session (there is a file in tmp folder named sess_1234) and hijack it too (open in another browser, resume state). Again, corrent me if I'm wrong - was session fixation completley patched in recent php versions or just this simple attack? My current version is 5.3.4

Answer 1

Try changing the cookie in your browser. Using firefox, install the "Web Developer" tool bar extension. Then from the Cookies menu, choose "Edit Cookie" and change the value for your domain or create the new cookie that your trying to replicate.

Answer 2

From the article and what you have updated us with, this is what I can tell.

PHP didn't completely patch the attack, but it has given the developer the choice to not allow the server to accept PHPSESSID from the URL and force it to only accept it from the cookie. This way, examples which are shown in the article you linked become much more difficult to commit (but this doesn't mean impossible by any means!). In a way it is a very simple attack and is dependent on certain configuration options to be enabled, but if they are enabled the attack is very legitimate.

This reminds me a little bit of magic quotes. A feature which was suppose to help people thwart SQL injections, but in the end just made some new PHP developers write SQL injection prone code. Magic quotes (until PHP 5.4) can still be enabled allowing people to write code with SQL injections, but just like the PHPSESSID the developer can decide if they want these options enabled or not.