Re: How can i protect against session hijacking?

[AF <saphyr () infomaniak ch>]

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