PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Tue Aug 22, 2017 12:31 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 29 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Jun 15, 2005 9:59 am 
Offline
Forum Contributor

Joined: Wed Mar 12, 2003 1:52 pm
Posts: 198
Location: IL
When a session is hijacked, does this just mean that the hijacker now has access to the hijackee's webpages that only thier session allows? Or can the hijacker actually manipulate the session data? I have not yet found any article mention that.

The reason I ask is that I wonder if it's necessary to recalculate all critical data before storing to a database, rather than only calculate data the first time it's needed (and when user makes changes) and keep it in a session until ready to put in the database.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 15, 2005 10:07 am 
Offline
DevNet Resident

Joined: Tue Nov 18, 2003 2:09 pm
Posts: 1826
Location: Middlesbrough, UK
they take the persons 'identity' online.

anything the user could do, they can now do, such as login to priviliged area, post under there username etc etc


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 15, 2005 10:16 am 
Offline
BeerMod
User avatar

Joined: Tue Jan 13, 2004 5:58 pm
Posts: 2170
Location: Jax FL & Spokane WA USA
A good but not 100% accurate way to prevent session hijacking is to do an IP / Browser or Cookie check when you call the session vars.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 15, 2005 10:49 am 
Offline
Forum Contributor

Joined: Wed Mar 12, 2003 1:52 pm
Posts: 198
Location: IL
Ok, so they couldn't actually manipulate stored session data (except if they now have access to webpages that allows them to do so). The data that a hijacker would find in another user's profile on my website is not critically sensitive. But, don't get me wrong, I take the security of that information very seriously. My concern is less about a hijacker finding a user's information, then it is about a hijacker manipulating session data to be something it shouldn't be, right before it's stored in the database. Or even a user manipulating their own session data, is that possible?


Example Scenerio:
If I have page1.php which calculates $A + $B = $_SESSION['C'], and page2.php puts $_SESSION['C'] in the database, I will not have to worry about $_SESSION['C'] being changed by a hijacker somehow. Right? What I've done in the past is recalculate $A + $B on page2.php, instead of using $_SESSION['C']. But, if storing data in sessions is safe, I want to avoid using up valuable server resources because my calculations are getting much more complicated than $A + $B.

As for the IP checking... what if their IP changes during a session? I believe that is possible.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 15, 2005 10:52 am 
Offline
DevNet Resident

Joined: Tue Nov 18, 2003 2:09 pm
Posts: 1826
Location: Middlesbrough, UK
Swede78 wrote:
As for the IP checking... what if their IP changes during a session? I believe that is possible.


it is possible yes but so what, get them to log back in, it adds an extra dimension to your security at a slight cost that 99% of your users will never experience


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 15, 2005 11:35 am 
Offline
Forum Contributor

Joined: Wed Mar 12, 2003 1:52 pm
Posts: 198
Location: IL
Quote:
it is possible yes but so what, get them to log back in, it adds an extra dimension to your security at a slight cost that 99% of your users will never experience


I use sessions for much more than storing log-in information. I have a lot of multi-page forms that rely on sessions. I would be quite annoyed if I had to re-login and start over after filling out multiple pages of information for 15 minutes. I wouldn't want even 1% of my users to experience that.

Maybe for certain sites, I would accept that inconvenience in trade of security.


But, back to my original topic... any reason to worry about critical session data being manipulated?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 15, 2005 12:10 pm 
Offline
DevNet Master
User avatar

Joined: Tue Dec 28, 2004 6:57 pm
Posts: 2745
Location: Tallinn, Estonia
i don't believe it is possible for the user to change the session data, only to steal a users existing session but not change that users session information

ie they cant take $_SESSION['value'] that = 1 and change it to $_SESSION['value'] to = 2. i really dont believe this is possible


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 15, 2005 1:00 pm 
Offline
Forum Regular
User avatar

Joined: Fri Mar 19, 2004 2:51 pm
Posts: 873
Swede78 wrote:
But, back to my original topic... any reason to worry about critical session data being manipulated?

If that critical data depends on the user input and the session has been hijacked then wouldn't the answer be yes?

If $A or $B are supplied by the user then $_SESSION['C'] which equals $A + $B could be corrupted by a hijacker?

Swede78 wrote:
I would be quite annoyed if I had to re-login and start over after filling out multiple pages of information for 15 minutes.

If the data is critical then challenge the user for their password. It's just one more field to fill out on the last page of the form. No need for the username you should know that already. Your not logging them in. Your just confirming their identity before they perform a critical operation.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 15, 2005 1:39 pm 
Offline
Forum Contributor

Joined: Wed Mar 12, 2003 1:52 pm
Posts: 198
Location: IL
Quote:
If that critical data depends on the user input and the session has been hijacked then wouldn't the answer be yes?

If $A or $B are supplied by the user then $_SESSION['C'] which equals $A + $B could be corrupted by a hijacker?


Sorry, I should have been more specific. The data that I'm concerned about storing as a session (in my example $A + $B) is not derived from any user input. I understand that if a hijacker takes over a session, they would be able to access/manipulate anything that the hijacked user would be able to. And therefore, as Buddha suggests also, I do require to supply the password when the user wishes to change any personal information. I also send an email notification that changes have been made, to both old and new addresses.

Quote:
i don't believe it is possible for the user to change the session data, only to steal a users existing session but not change that users session information


That anaswers my question then. I'm not going to recalculate $A + $B multiple times, when I know $A + $B does not change, out of paranoia. I suppose a hacker could get in the server, find the session file and change some values, but then I got more serious issues :)

Thank you all for the responses!


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 15, 2005 2:22 pm 
Offline
DevNet Master

Joined: Tue Jan 20, 2004 12:11 am
Posts: 4897
Location: Leuven, Belgium
This is how i build a "fingerprint" of a visitor..

Syntax: [ Download ] [ Hide ]
// get the fingerprint of the user

    function getFingerprint()

    {

        $fingerprint = $this->secret;

        if (array_key_exists('HTTP_USER_AGENT', $_SERVER))

        {

            $fingerprint .= $_SERVER['HTTP_USER_AGENT'];

        }

        if (array_key_exists('HTTP_ACCEPT_CHARSET', $_SERVER))

        {

            $fingerprint .= $_SERVER['HTTP_ACCEPT_CHARSET'];

        }

        $fingerprint .= session_id();

        $fingerprint = md5($fingerprint);

        return $fingerprint;

    }


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 15, 2005 9:07 pm 
Offline
Tutorials Group

Joined: Sun Jan 04, 2004 11:30 pm
Posts: 2692
malcolmboston wrote:
Swede78 wrote:
As for the IP checking... what if their IP changes during a session? I believe that is possible.


it is possible yes but so what, get them to log back in, it adds an extra dimension to your security at a slight cost that 99% of your users will never experience

I'd say that statistic is 99% pulled out of the air.

A *large* number of users go through proxies, concentrators, and web content engines that end up changing their IP address during a session. Entire *countries* have their access forced through such devices, and to say that only affects 1% of the population is a little inaccurate in my experience. (Of course, if your webapp market is 99% people that use static IP addresses in the US only, then yes, it would be 99%)

In my experience, its a significant amount - over 15% for people playing BNT, TKI, and other various games I've contributed to.

A much more reliable method to preventing session hijacking is to use a one-time pad. By sending a one-time secret to the user, and forcing them to respond with a different secret (password?) hashed with that one-time secret, you seriously reduce the possibility of session hijacking.

Now the attacker has to get a working session cookie in the narrow window of time that a user is logged in, which quite literally may only be 10 minutes out of a day (1440 minutes, or less than 1% of the time).

Just a thought.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 25, 2005 6:05 pm 
Offline
Forum Contributor
User avatar

Joined: Sun Feb 06, 2005 12:22 pm
Posts: 124
timvw wrote:
This is how i build a "fingerprint" of a visitor.

Very nice. If I may make one suggestion, you might want to consider adding some bit of information that never leaves the server - a secret string of some sort.

For example, if you append 'SHIFLETT' to your fingerprint before you hash it, then an attacker who is able to snoop a user's request (and has access to all of the HTTP headers) is more unlikely to be able to reproduce the fingerprint. Of course, the attacker may be able to snoop a user's request sent to your site, exposing the fingerprint, but this particular risk can be mitigated with SSL.

Hope that helps.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 25, 2005 7:18 pm 
Offline
Forum Newbie

Joined: Sat Jun 25, 2005 7:13 pm
Posts: 1
Location: Vermont, USA
shiflett wrote:
timvw wrote:
This is how i build a "fingerprint" of a visitor.

Very nice. If I may make one suggestion, you might want to consider adding some bit of information that never leaves the server - a secret string of some sort.


The fingerprint starts with:
Syntax: [ Download ] [ Hide ]
$fingerprint = $this->secret;

and then builds the fingerprint by appending to that string. Isn't that what you're describing? Or did I miss something?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 25, 2005 7:29 pm 
Offline
Forum Contributor
User avatar

Joined: Sun Feb 06, 2005 12:22 pm
Posts: 124
weierophinney wrote:
The fingerprint starts with:
Syntax: [ Download ] [ Hide ]
$fingerprint = $this->secret;

and then builds the fingerprint by appending to that string. Isn't that what you're describing? Or did I miss something?

You didn't miss anything - I did. :-)


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jun 27, 2005 6:42 pm 
Offline
Forum Newbie

Joined: Mon Jun 27, 2005 5:46 am
Posts: 1
timvw wrote:
Syntax: [ Download ] [ Hide ]
// get the fingerprint of the user
    function getFingerprint()
    {
        $fingerprint = $this->secret;
        if (array_key_exists('HTTP_USER_AGENT', $_SERVER))
        {
            $fingerprint .= $_SERVER['HTTP_USER_AGENT'];
        }
        if (array_key_exists('HTTP_ACCEPT_CHARSET', $_SERVER))
        {
            $fingerprint .= $_SERVER['HTTP_ACCEPT_CHARSET'];
        }
        $fingerprint .= session_id();
        $fingerprint = md5($fingerprint);
        return $fingerprint;
    }



Chris, what are your recommendations for variables to include in a "vistor fingerprint"? Users can modify their HTTP_USER_AGENT, HTTP_ACCEPT_CHARSET can change between requests, etc. AOL for example use weirdly configured proxy servers to proxy web traffic so AOL's users web requests always come from random IP's of AOL's various proxy servers.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 29 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group