RE: How can i protect against session hijacking?

["Debasis Mohanty" <debasis.mohanty.listmails () gmail com>]

> > Typical. automated web assessment tools reporting 300 critical 
> > vulnerabilities...all located in one URL, one parameter. Result: a 500-
> > pages report that makes the client suffer just as he sees it. ;)

Yeah that true for security folks who just rely completely upon tools! 

This is where even an average skilled resource will filter out false
positives and suppress un-necessary duplicate warnings by the tool. 

Although your statement is heading into a different context but for your
information most of the leading tools I have used does report multiple
variant of an issue but do group it under a single category. For example: If
there are 5 different variant of an XSS issue affecting the same parameter
then the tool group it under a single XSS category but does shows all the
possible variants. I believe, even an average skilled security folk will not
argue that the issue is just one XSS not 5 XSS. Right? 

-d

-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On
Behalf Of AF
Sent: 03 April 2009 10:28
Cc: webappsec () securityfocus com
Subject: Re: How can i protect against session hijacking? 

Debasis Mohanty wrote:
> So in your opinion if an application is vulnerable to one XSS but an
adverse
> can exploit the XSS to do 10 different malicious operations, then the app
is
> vulnerable to 10 issues not 1 XSS?? Won't it give a misleading/vague
> assessment of vulnerability? No offence but I have seen this before in
many
> fake consultants reports where they try to blow up an XSS and exploit in
> more than one ways to increase the vulnerability count in an report.
>
> -d
>   
Typical. automated web assessment tools reporting 300 critical
vulnerabilities...all located in one URL, one parameter. Result: a
500-pages report that makes the client suffer just as he sees it. ;)

Concerning the session security debate, I usually require, at least,
the following measures to be applied:



Chris,

According to your original question "how can I protect from
session hijacking", I would say that you can't. The inherent nature
of letting a client, which is not under your complete control,
access your application involves accepting the risk of session
hijacking. That's it. End of discussion. No magic receipt.


Now, there is, of course, a nice set of measures you can implement
in order to reduce the risk. Your preliminary threat model should
tell you what precise undesirable scenarios are you willing to consider.

In the case of session hijacking, that would be for example:

 - the network sniffing guy
 - the XSS/CSRF guru
 - the IT assistant who wants the session IDs
 - the Trojan guy
 - the psycho-financial-crisiso-social engineering guy
 - the wormer guy
 - and so on.

...and how you will defend against them:

  - accept  -> do nothing
  - mitigate  -> make their attacks less harming to your system
  - eliminate  -> fix the weaknesses that may help them accomplish their job
  - delegate  -> don't fix anything. get insured.


For example:  you may have the "communication channel sniffing" or
"hijacking" attack pattern, that you may "eliminate" by implementing
SSL

If you want to counter successful exploitation of existing XSS holes,
you may want to "mitigate" session hijacking risks by tying the session
identifier with the user network address and implementing anti-CSRF
measures. But.. that again, would not be "fixing" the application...

As Debasis expressed in a previous answer, protecting from session
hijacking often consists in fixing other flaws. ie: an XSS is, among
others, a useful vector that you may "eliminate" by fixing, thus, 
mitigating
the risk of session hijacking.

And so on.

If there was a golden rule for eliminating the risk of session hijacking,
I guess most security books would give the receipt.


Now, let's consider the "problem" you stated:

"If an attacker gets hold of the end users cookies (through XSS and so,
forth),,how can you actually prevent session hijacking?"

You proposed a series of measures to which you always gave "cons".
You can't expect anything else but "cons", there is no "fail-safe" holy
function that will save you.....unless you fix that XSS flaw first. Appsec
does not consist in making an application invulnerable but in making
it too expensive for your target to hack.

Salvation only comes by reducing the risk: fixing vulnerabilities and
adding layers of defense to make 'their' life harder.

If I have one recommendation from all above that would be: don't
focus on your "cons", focus on your "pros". And if at anyday you want
to tell your customers that their application's session management
can not be hacked, then...don't. That would be a lie.


Antonio Fontes