Reality Check: Session Hijacking

[mrbog]

Tell me if my assertion is wrong here:

The only way to prevent session hijacking is to NEVER store
authentication information (such as name/password) in the 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). 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.

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.

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.

If you agree, then look at this from the zend site, and isn't it
fundamentally wrong?:

http://www.zend.com/zend/spotlight/s...y.php#Heading5
------------------------------------------
Signature:
Never buy the services of newsfeed.com. I am a paying customer but
I'm using google to post messages, so that I can avoid their damn
advertisement showing up in every post I make.
------------------------------------------

[Daniel Tryba]

mrbog <dt******@hotma il.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/s...y.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

[Adriaan]

"Daniel Tryba" wrote

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?

A single (even GET) parameter can be usefull: simply store some random value
in both session and that parameter, and compare the two. This makes random
session hijacking (where one would try to guess a session id without any
sniffing, which indeed is difficult) a lot more difficult. And when
refreshing the random value for each page this can be used to control the
use of the Back button or avoiding multiple hits on a submit button (but
that is not session or security related).

Adriaan

[mrbog]

Daniel Tryba <ne************ ****@canopus.nl > wrote in message news:<c7******* ***@news.tue.nl >...

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).
(snip) 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.

No, you're not thinking deeply enough. Think this through. There IS
"much one can do about the hijacker reading userdata". If you do it
my way- always challenge the user for name and password when he's
viewing secure data, and then pass name/password on hidden form
fields, then you can prevent session hijacking. (With the one
exception of those rare hackers than can actually decript 128 bit ssl,
obviously, which I don't think is what you're arguing here).

With your way, and the way recommended by that zend site, sessions
are wide open to be hijacked. If you challenge the user for
name/password, and then store some "authentica ted" bit in the session
(even if it's not name/password, whatever it doesn't matter), then
someone else can see the session id, and create a duplicate request,
going into secure https with that session id, just as user would, and
do whatever he wants (whatever the user could). And neve be
challenged for the password.

Think deeper, don't click the respond button until you get it.

------------------------------------------
Signature:
Never buy the services of newsfeed.com. I am a paying customer but
I'm using google to post messages, so that I can avoid their damn
advertisement showing up in every post I make.
------------------------------------------

[R. Rajesh Jeba Anbiah]

dt******@hotmai l.com (mrbog) wrote in message news:<cb******* *************** ****@posting.go ogle.com>...

Tell me if my assertion is wrong here:

<snip>

Not an answer to your question. But, this logic is what I prefer
<http://martin.f2o.org/php/login>

--
| Just another PHP saint |
Email: rrjanbiah-at-Y!com

[Adriaan]

"mrbog" wrote

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

.... No, you're not thinking deeply enough. Think this through. There IS
"much one can do about the hijacker reading userdata". If you do it
my way- always challenge the user for name and password when he's
viewing secure data, and then pass name/password on hidden form
fields, then you can prevent session hijacking.

But then you're always using SSL, for otherwise you method is simply
decreasing security. In essence, the session id *is* a way of authentication
just like user name and password, but at least one that's only valid for the
current session. But in your solution the authentication is no longer
temporary valid! If you're indeed using SSL for each page, then there's
simply no need for your worries, and no need for your solution. Even more:
some browsers *do* save SSL pages to disk -- so repeating the user name and
password in hidden form fields is *very* bad practice, even worse than
saving them in the session itself (which you should not do either).

By the way: your solution makes your pages much more difficult to create, as
all pages suddenly need to be a FORM, which is also a pain for the visitor
when using the browser's Back button. I would hate such a site!

Your solution only helps for shared servers (such as Apache's virtual
hosting) where other webmasters could read all the session IDs (and
contents) from the temp folder. But that setup can be changed, and shared
servers should simply never be used for sensitive applications (and those
webmasters could also read your code and as such get your database password
and open that database). Daniel's solution to prompt for the PIN is right,
and is implemented on many sites -- if not for hijacking then for avoiding
someone actually using *your* computer to change such details after you
logged in and left the browser open (maybe showing a different site, but the
Back button might take that person back to your sensitive pages) when going
for lunch -- which is not taken care of by your solution either.

Adriaan.

[Adriaan]

"R. Rajesh Jeba Anbiah" wrote

Not an answer to your question. But, this logic is what I prefer
<http://martin.f2o.org/php/login>

So you're storing the IP address in your database. But HTML being stateless
by design, doesn't this break when using dial-up networking (totally valid,
especially for ISDN that might drop the connection after a timeout that is
much shorter than the timeout of your session) or proxy servers?

Adriaan.

[Daniel Tryba]

mrbog <dt******@hotma il.com> wrote:

No, you're not thinking deeply enough. Think this through. There IS
"much one can do about the hijacker reading userdata". If you do it
my way- always challenge the user for name and password when he's
viewing secure data, and then pass name/password on hidden form
fields, then you can prevent session hijacking. (With the one
exception of those rare hackers than can actually decript 128 bit ssl,
obviously, which I don't think is what you're arguing here).
This is actually worse since every page contains the necesary
credentials to create a new session.
With your way, and the way recommended by that zend site, sessions
are wide open to be hijacked. If you challenge the user for
name/password, and then store some "authentica ted" bit in the session
(even if it's not name/password, whatever it doesn't matter), then
someone else can see the session id, and create a duplicate request,
going into secure https with that session id, just as user would, and
do whatever he wants (whatever the user could). And neve be
challenged for the password.
Guess you did miss my suggestion to ask for additional credentials on
editing data?
Think deeper, don't click the respond button until you get it.

Duhhhhh!

Solution found: only use https.

--

Daniel Tryba

[Daniel Tryba]

R. Rajesh Jeba Anbiah <ng**********@r ediffmail.com> wrote:

Not an answer to your question. But, this logic is what I prefer
<http://martin.f2o.org/php/login>

Like Adriaan suggested, this actually locks out some users (those behind
loadbalancing proxies at least). Also it only limits the number of users
that can hijack to the users that can product the same
$_SERVER['REMOTE_ADDR'] (eg everyone on the same proxy).

To bad this was fixed:

http://www.computerbytesman.com/privacy/supercookie.htm

:)

--

Daniel Tryba

[R. Rajesh Jeba Anbiah]

Daniel Tryba <ne************ ****@canopus.nl > wrote in message news:<c7******* ***@news.tue.nl >...

R. Rajesh Jeba Anbiah <ng**********@r ediffmail.com> wrote:

Not an answer to your question. But, this logic is what I prefer
<http://martin.f2o.org/php/login>
Like Adriaan suggested, this actually locks out some users (those behind
loadbalancing proxies at least). Also it only limits the number of users
that can hijack to the users that can product the same
$_SERVER['REMOTE_ADDR'] (eg everyone on the same proxy).

I could be able to differentiate the proxy to some extent. And I
agree that it is not a 100% foolproof.
To bad this was fixed:

http://www.computerbytesman.com/privacy/supercookie.htm

Will look at there later.

--
| Just another PHP saint |
Email: rrjanbiah-at-Y!com