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/sessionauth7may.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]

Re: Reality Check: Session Hijacking

mrbog <dterrors@hotma il.com> wrote:[color=blue]
> The only way to prevent session hijacking is to NEVER store
> authentication information (such as name/password) in the session.[/color]

Wrong. Hijacking is independend of data contained in a session.
[color=blue]
> 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).[/color]

Ehhh, that is one of the things sessions are mainly used for (to
prevent)
[color=blue]
> 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.[/color]

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).
[color=blue]
> 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.[/color]

SessionIDs are nothing more than random data (standard PHP session
string is a 128bit hexstring (32chars)).
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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[/color]

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]

Re: Reality Check: Session Hijacking

"Daniel Tryba" wrote[color=blue][color=green]
> > 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.[/color]
>
> So instead of sendig it once and storing something in session you want
> to send the vulnerable data over and over again?[/color]

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]

Re: Reality Check: Session Hijacking

Daniel Tryba <news_comp.lang .php@canopus.nl > wrote in message news:<c7924c$t3 q$1@news.tue.nl >...[color=blue]
>
> 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).
>[/color]
(snip)[color=blue]
> 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.
>[/color]

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]

Re: Reality Check: Session Hijacking

dterrors@hotmai l.com (mrbog) wrote in message news:<cbd4bb52. 0405041244.2bfe b56a@posting.go ogle.com>...[color=blue]
> Tell me if my assertion is wrong here:[/color]

<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]

Re: Reality Check: Session Hijacking

"mrbog" wrote[color=blue][color=green]
> > 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[/color][/color]
....[color=blue]
> 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.[/color]

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]

Re: Reality Check: Session Hijacking

"R. Rajesh Jeba Anbiah" wrote[color=blue]
> Not an answer to your question. But, this logic is what I prefer
> <http://martin.f2o.org/php/login>[/color]

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]

Re: Reality Check: Session Hijacking

mrbog <dterrors@hotma il.com> wrote:[color=blue]
> 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).[/color]

This is actually worse since every page contains the necesary
credentials to create a new session.
[color=blue]
> 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.[/color]

Guess you did miss my suggestion to ask for additional credentials on
editing data?
[color=blue]
> Think deeper, don't click the respond button until you get it.[/color]

Duhhhhh!

Solution found: only use https.

--

Daniel Tryba

[Daniel Tryba]

Re: Reality Check: Session Hijacking

R. Rajesh Jeba Anbiah <ng4rrjanbiah@r ediffmail.com> wrote:[color=blue]
> Not an answer to your question. But, this logic is what I prefer
> <http://martin.f2o.org/php/login>[/color]

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]

Re: Reality Check: Session Hijacking

Daniel Tryba <news_comp.lang .php@canopus.nl > wrote in message news:<c7agct$b3 m$1@news.tue.nl >...[color=blue]
> R. Rajesh Jeba Anbiah <ng4rrjanbiah@r ediffmail.com> wrote:[color=green]
> > Not an answer to your question. But, this logic is what I prefer
> > <http://martin.f2o.org/php/login>[/color]
>
> 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).[/color]

I could be able to differentiate the proxy to some extent. And I
agree that it is not a 100% foolproof.
[color=blue]
> To bad this was fixed:
>
> http://www.computerbytesman.com/privacy/supercookie.htm[/color]

Will look at there later.

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

[mrbog]

Re: Reality Check: Session Hijacking

"Adriaan" <red@de.solidar eit> wrote in message news:<4098af60$ 0$14645$e4fe514 c@dreader19.new s.xs4all.nl>...[color=blue]
> 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.[/color]

No- I'm not saying to use SSL for every page. Use SSL for every page
of applications that are transmitting sensitive data- (in other words,
use SSL jsut as much as it was intented). If the entire site is over
https, then yea, there's no problems with any method (unless hackers
decode the ssl obviously).

As for the browser caching the HTML, that's solved easily enough- just
encode the name and password before you write it to the input
type="hidden" fields, and decode it when you get it back.

You've caused me to enhance my solution- So here it is again:

1. ALWAYS challenge the user for name/password when he BEGINS to use
an application that's over https, in other words, an application that
involves sensitive data. Do NOT store this data in the session.

2. On evey subsequent page of the given sensitive application, write
an encoded (encrypted) version of the authenication information
(name/password) into hidden fields, and re-authenticate using those
(unencoded) fields again when the form is submitted.

3. If the user LEAVES the secure application and goes to an http (no
s) part of the site, and then comes back to a secure part again, he
will be re-challenged for name and password and has to login again,
see step 1, because the app can't get his auth info from anywhere.

4. There is no possibility of session hijacking in the above, except
obviously if someone can decode SSL's 128 bit encryption.

Now, is what I've come up with essentially the same thing as what you
two are talking about with setting a "PIN"- where isntead of storing
encrypted authentication info into hidden fields, you're saying I
could store a random number and then check for it again when the form
comes back? If so, I'll go with that, and we're essentially on the
same page, EXCEPT FOR THE FACT THAT THAT ZEND ARTICLE DOESN'T SUGGEST
THAT, and is therefore wide open for session hijacking, which is the
whole point of my post.

[Adriaan]

Re: Reality Check: Session Hijacking

"mrbog" wrote[color=blue]
> Now, is what I've come up with essentially the same thing as what you
> two are talking about with setting a "PIN"- where isntead of storing
> encrypted authentication info into hidden fields, you're saying I
> could store a random number and then check for it again when the form
> comes back?[/color]

We're not talking about setting a PIN. The PIN Daniel suggested and I
repeated (and that many sites use) is really a username and password. So
forget the word PIN, and whereever we were referring to it read "username
and password". The username could have been stored in the session. Whenever
something requires new authentication, the application can prompt for the
password.

Apart from that: I still don't see any reason to go with your difficult
solution, but well that's just me. You solution still allows for session
hijacking for those who're sniffing the data sent. When the hijacker gets to
the SSL he's stuck: little or no difference compared to using plain sessions
and prompting for the password when changing data. And if really that
important than I'd favor using SSL for each page rather than effectively
disabling the browser Back button by using your hidden FORM.

Cheers,
Adriaan

[Daniel Tryba]

Re: Reality Check: Session Hijacking

mrbog <dterrors@hotma il.com> wrote:[color=blue]
> You've caused me to enhance my solution- So here it is again:
>
> 1. ALWAYS challenge the user for name/password when he BEGINS to use
> an application that's over https, in other words, an application that
> involves sensitive data. Do NOT store this data in the session.
>
> 2. On evey subsequent page of the given sensitive application, write
> an encoded (encrypted) version of the authenication information
> (name/password) into hidden fields, and re-authenticate using those
> (unencoded) fields again when the form is submitted.[/color]

You are contradicting yourself. Where are you getting the user/passwd
data from? You have it stored somewhere, so you might just as well store
it in a session.
[color=blue]
> 3. If the user LEAVES the secure application and goes to an http (no
> s) part of the site, and then comes back to a secure part again, he
> will be re-challenged for name and password and has to login again,
> see step 1, because the app can't get his auth info from anywhere.
>
> 4. There is no possibility of session hijacking in the above, except
> obviously if someone can decode SSL's 128 bit encryption.[/color]

Our break the encryption on the data you're sending on every page....

BTW The biggest problem with privacy isn't in the session but in the
browser. Ligit user uses your application, logs out but leaves browser
open, the next person only has to do a couple of back's and can see
whatever is left in the history of the browser (and in your case the
encoded challenge responses).

If you want to the stuff you are proposing, DON'T USE static data. Use
random stuff to make URLs/forms unique and check for the correct unique
key in the session. But that solution was already suggested.

--

Daniel Tryba

[Daniel Tryba]

Re: Reality Check: Session Hijacking

R. Rajesh Jeba Anbiah <ng4rrjanbiah@r ediffmail.com> wrote:[color=blue][color=green]
>> 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).[/color]
>
> I could be able to differentiate the proxy to some extent. And I
> agree that it is not a 100% foolproof.[/color]

Sure, if you only look to the x-forwarded-for (or equiv) header you are
totally screwed.... with my own proxy/network I can put any IP address
in there I want :)

--

Daniel Tryba

[mrbog]

Re: Reality Check: Session Hijacking

"Adriaan" <red@de.solidar eit> wrote in message news:<4099caca$ 0$96072$e4fe514 c@dreader14.new s.xs4all.nl>...[color=blue]
> Apart from that: I still don't see any reason to go with your difficult
> solution, but well that's just me. You solution still allows for session
> hijacking for those who're sniffing the data sent.[/color]

The only way you can sniff the data in my solution is by decrypting
the ssl. If you don't see that, then you still don't understand my
method. You're forgetting the statelessness of the web. You only
prompt at the beginning of an SSL app session, and then get name/pw
from the session thereafter. What if the user logs in over SSL, views
the first page of your app, then the user leaves https and goes to
http. The hacker can see his sessid, create a duplicate request using
a fake session cookie, to the SECOND PAGE of your https app, and your
secure app will let him in because it gets name/pw from session.
[color=blue]
> And if really that
> important than I'd favor using SSL for each page rather than effectively
> disabling the browser Back button by using your hidden FORM.[/color]

That's where we differ. I'd rather not use SSL for my entire site to
prevent session hijacking. Instead, I use this method and both A.
prevent session hijacking and B. use SSL only as needed. Your saying
that you'd rather choose only one of those two, and I don't understand
why. But if you want to run your sites that way, so be it.