Re: Reality Check: Session Hijacking

From: Daniel Tryba (news_comp.lang.php_at_canopus.nl)
Date: 05/04/04 

Date: Tue, 4 May 2004 21:31:56 +0000 (UTC)

mrbog <dterrors@hotmail.com> wrote:
> The only way to prevent session hijacking is to NEVER store
> authentication information (such as name/password) in the session.

Wrong. Hijacking is independend of data contained in a session.

> Well, to never authenticate a user from information you got from the
> session. Each secure app on a site must challenge the user for name
> and password, each and every time the user accesses it (not just once
> and then store it in the session).

Ehhh, that is one of the things sessions are mainly used for (to
prevent)

> If a secure app is multi-page, then you must only pass session data in
> hidden form fields between each page, on forms that POST over https.

So instead of sendig it once and storing something in session you want
to send the vulnerable data over and over again? (Note that I said
something instead of login/password).

> That's my assertion. Is that right? If you disagree, consider this
> scenario:
>
> 1. User goes to a web site's homepage, over http. The site remembers
> him, Welcome, Joe. In other words, there's his session ID, travelling
> over insecure http in a plain text cookie that anyone can read with a
> packet sniffer.

SessionIDs are nothing more than random data (standard PHP session
string is a 128bit hexstring (32chars)).

> 2. User goes to edit some private data, such as his name and address
> or cc number or whatever, over https, and IS NOT CHALLENGED for his
> name/password, because the site knows who he is from his session.
>
> 3. The above is security breach. Someone with a packet sniffer could
> see his session id, as well as everything else about his requests-
> browser, ip address, etc, in plain text, when he was making requests
> over http. Then with that, the sniffer could make an https request to
> the same application that displays his private information. The
> sniffer doesn't know the user's loginname/password, and he doesn't
> have to, he's never asked for it. All he needs is the sesid cookie.

Correct. So this has to be prevented. At this point there isn't much one
can do about the hijacker reading the userdata, only thing that has to
be prevented is the hijacker changing data, The most simple way to do
this is to ask for a PIN at these points, offcourse transactions that
ask for a PIN should only be done over secured (eg ssl) connections.

> If you agree, then look at this from the zend site, and isn't it
> fundamentally wrong?:
>
> http://www.zend.com/zend/spotlight/sessionauth7may.php#Heading5

I dont' see anything wrong with this. $authdata doesn't contain a
user/password combo, it's either false or an array (containing
loginname). 

-- 
  Daniel Tryba

Relevant Pages

  • Reality Check: Session Hijacking
    ... authentication information (such as name/password) in the session. ... on forms that POST over https. ... Someone with a packet sniffer could ...
    (comp.lang.php)
  • Re: Session Hijacking over HTTP
    ... yahoo.com protect their users from session hijacking when they use ... the server-side session. ... This way when an attacker hijacks the session he should also spoof ... Another nice thing to do is to alert the real user that there were ...
    (Pen-Test)
  • RE: Repost: Re: User authentication over the web (was: Secure Password in database)
    ... Subject: Repost: Re: User authentication over the web ... As long as the REAL USER is actively using his session, ... >> hijacking difficult or impossible. ...
    (SecProg)
  • Re: Page load frequency
    ... updated session cookie, and provides a workaround. ... I was unsure if you wanted to protect against a single user or against ... a sessionid with each request and response. ... Hijacking can also be blocked if you use safe transport via https/ssl. ...
    (comp.lang.php)
  • Re: generating a session id
    ... > I have made an effort to understand a process by exploring it in its ... > most basic form, as if I had to create for the first time. ... I could predict what the next session ID ... and start hijacking your customer's sessions. ...
    (comp.lang.perl.misc)