0

I'm using uploadify and the script (which uses adobe flash) creates a new session instead of using the current one when requesting the upload action url. To fix that I need to pass ahead the session id.

Is there a way to do this without permit session fixation (hijacking)?

Here are some details of the problem: Sessions and uploadify

Thanks!

Community
  • 1
  • 1
Keyne Viana
  • 6,194
  • 2
  • 24
  • 55

1 Answers1

2

Create a temporary upload session in your script (untested, but you get the point about being able to have several different sessions):

<?php
//normal session
session_start();
//store sessionid for retrieval
$oldsessionid = session_id();
if($_SESSION['logged_in']){ //or however you check for a valid user
    //stop old/normal session
    session_write_close();   
    //create a new sessionname
    $oldname = session_name('UPLOADSESSION');
    //create a new id (fixed here, you might want a random number/char combo:
    session_id('myuploadsessionid');
    //start the session
    session_start();
    $_SESSION['upload'] = true;
    $uploadid = session_id();
    //now you can use `'data: "artist="+$fi+"&UPLOADSESSION="'.$uploadid` in uploadify
    session_write_close();
}
//return to normal name
session_name($oldname);
//set old session id
session_id($oldsessionid);
//resume normal session
session_start();

So, in your receiving script:

<?php
session_name('UPLOADSESSION');
session_id($_POST['UPLOADSESSION']);
session_start();
if(isset($_SESSION['upload']) && $_SESSION['upload']){
   //accept files
   //invalidate session after this upload
   $_SESSION['upload'] = false;
}

The user will still have 2 cookies, and possibly UPLOADSESSION is fixated, but you don't use it for anything else then uploading, and only for 1 upload (although you might want to allow more).

Alternatively, you could just call a session_regenerate_id(); on the first request after an upload (just set a flag in the $_SESSION on upload).

Wrikken
  • 69,272
  • 8
  • 97
  • 136
  • Here the user still have the session id visible, but is the one used only for the upload action, right? What I didn't get is how this will prevent session hijacking since it will be displayed in the code. If the session is hijacked, the user still not able to be logged in, since it isn't the real session (used for login) but he can send files. The only trick that I can see here is the flag 'upload'. But in this specific case the user can send many files without reload the entire page (this is what uploadify does). – Keyne Viana Nov 04 '10 at 22:16
  • Also, lets say that the user has entered on the upload page, the session was genereted, and then he wait for some reason, at this point someone who hijacked the session can send files. Is it right? Am I missing something? – Keyne Viana Nov 04 '10 at 22:17
  • Your point was `session-fixation`, which this will be prevent (i.e: if someone gets sent to an url with a particular post/get var, it will not be the session-id of his/her logged in session). If you are however serving the page over non-HTTPS, all bets are of, and yes, the hijacker can see the session-id for upload, but then again: he can also see the session cookie at that time, so he can be logged in for real. Having it in HTML is not really less safe then having it in your header, and as easily hijacked. Point is: this prevents session-hijacking by fixation, not other kinds of hijacking. – Wrikken Nov 04 '10 at 22:27
  • So, when session_id through url is enabled without https I'll be always in trouble? – Keyne Viana Nov 04 '10 at 23:05
  • Without `HTTPS` you're always be in trouble, no matter which authentication and session scheme you're using, be it through URL, POST or the default COOKIE. The fact that you don't see the cookie-headers in your browser by default doesn't mean they don't get send as plaintext over HTTP just as the rest of the HTML. – Wrikken Nov 04 '10 at 23:07