RE: How can i protect against session hijacking?

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

> > No - absolutely not. The vulnerability is the XSS, but the client needs
to know
> > what the extent of the damage might be

Exactly! Then how come session hijacking became an independent vulnerability
where the cause that leads to it is some other form of attack? 

The fact that I am iterating again is - session hijacking can occur provided
an adverse user already have access to valid sessions/tokens via sniffing,
MITM attack, session bruteforce/prediction or XSS etc etc... Hence it makes
session hijacking as the damage factor and causes are like lack of SSL, use
of weak sessions (predictable sessions) and lack of protection against XSS
etc... 

________________________________________
From: David Scholefield [mailto:david () port80 com] 
Sent: 02 April 2009 23:51
To: Debasis Mohanty
Cc: webappsec () securityfocus com
Subject: Re: How can i protect against session hijacking?


On 2 Apr 2009, at 18:44, 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?? 

No - absolutely not. The vulnerability is the XSS, but the client needs to
know
what the extent of the damage might be so they can gauge the level of risk
associated with that vulnerability so you would need to discuss the
potential
'different malicious operations'.


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.

I just don't see how you infer this point at all from my writing - it just
doesn't read like that. -

I'll not treat that as the slur that could be read into your suggestion - I 
assume that it's just slightly 'clumsy' prose. No offense taken :)



-d

________________________________________
From: David Scholefield [mailto:david () port80 com] 
Sent: 02 April 2009 23:00
To: Debasis Mohanty
Cc: webappsec () securityfocus com
Subject: Re: How can i protect against session hijacking?


Well, fundamentally, anything that denies *perfect* security would
be considered an additive vulnerability in your definition. I'm not
really discussing semantics (which wouldn't really be very helpful)
but simply giving an example of where most people would consider
session hijacking to be a singular vulnerability.


On 2 Apr 2009, at 18:16, Debasis Mohanty wrote:


A person could hijack this session by simply sniffing the web page
request

that contains a session token

Again! This is a case of absence of SSL and a bad design where the
application doesn't uses both session (in header) and token (in body) in
conjunction for request authorisation. I still fail to understand how it
makes session hijacking an independent issue on its own here??

-d


________________________________________
From: David Scholefield [mailto:david () port80 com] 
Sent: 02 April 2009 22:23
To: Debasis Mohanty
Cc: webappsec () securityfocus com
Subject: Re: How can i protect against session hijacking?



Not sure if I have understood you correctly or I am bit off here; Can you
explain what you mean by - "simply gaining
control of, or being able to generate, the session token (which is clearly a
form of session hijacking)" ? "

OK, imagine a web application that asks for authentication using any
mechanism (username and password for example) and then, on
authentication success, generates an (encrypted) session token that is
embedded
in all dynamically generated web pages presented to the authenticated
user. When the (legitimate) user clicks on a link with a session token
embedded into the link (which only they can see because it was 
dynamically generated as a response to their authentication) they are
allowed to follow the link. The response to 'that' link is a page
dynamically
generated with the session token embedded into each link again... and
so on...

A person could hijack this session by simply sniffing the web page request
that contains a session token, and either then submit that link themselves
and the server will treat them like the original user and allow them to
'share' their session, or they could possibly even create their own links
with the
session token.

This is an example of poor design for lots of reasons, but it is also an
example
of session hijacking without other vulnerabilities being present (except the
trivial one of not encrypting web traffic which may not be possible for all
kinds
of reasons).

It is hijacking the session because the server is dynamically creating 
pages with a session token (it may be storing all kinds of information
about authorization and timeouts etc. to go along with the session token).

OK, so the creator of this system should be sacked, but it's a surprisingly
common type of example of session hijacking without recourse to other
vulns.

david


On 2 Apr 2009, at 17:12, Debasis Mohanty wrote:


Not sure if I have understood you correctly or I am bit off here; Can you
explain what you mean by - "simply gaining
control of, or being able to generate, the session token (which is clearly a
form of session hijacking)" ? "

I failed to understand here how someone can simply gain control over the
session without relying upon any other attack? 

Regarding " generate, the session token " - if the session is guessable or
can be generated by session pattern analysis then it is clear case of weak
session issue. Isin't it weak (or predictable) session issue is different
from session hijacking? In other words, here session hijacking is possible
provided the adverse user is successfully able to guess/predict the
sessions. 

-d




________________________________________
From: David Scholefield [mailto:david () port80 com] 
Sent: 02 April 2009 13:55
To: Debasis Mohanty
Cc: 'Tommy'; webappsec () securityfocus com
Subject: Re: How can i protect against session hijacking?


On 30 Mar 2009, at 21:18, Debasis Mohanty wrote:


Session
hijacking is not a vulnerability by itself; a malicious user has to rely
upon other vulnerabilities like XSS and related attacks to gain access to
victim's session.

This isn't really accurate in my opinion - consider the case when a session
token is used as the only identification and authentication mechanism that 
controls access to protected resources. In this instance, simply gaining
control of, or being able to generate, the session token (which is clearly a
form of session hijacking) will lead to data compromise without any other
form of attack. This is sometimes achievable by simply manually creating
a token within a HTTP request.

Session hijacking - on it's own - is a serious vulnerability that may
require
no other vulnerability to enable exploitation to take place.

----
Dr David Scholefield, CISSP, OPST, MBCS
07525 624 997
www.port80.com

Security in a connected world





----
Dr David Scholefield, CISSP, OPST, MBCS
07525 624 997
www.port80.com

Security in a connected world





----
Dr David Scholefield, CISSP, OPST, MBCS
07525 624 997
www.port80.com

Security in a connected world





----
Dr David Scholefield, CISSP, OPST, MBCS
07525 624 997
www.port80.com

Security in a connected world