RE: How can i protect against session hijacking?

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

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

________________________________________
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