RE: How can i protect against session hijacking?

["Chris Grove" <cgrove () imperva com>]

Try installing a Web Application Firewall (WAF) that prevents attacks
like this, there are several on the market...

Of course a WAF is not a substitute for shoddy coding, you should
mitigate the risk in code as best you can, and use the WAF as an added
layer for protection.


-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com]
On Behalf Of Tommy
Sent: Friday, March 27, 2009 11:03 AM
To: webappsec () securityfocus com
Subject: How can i protect against session hijacking?

Gents,

Im having a conundrum, that might tickle your fancy.
How can you efficiently prevent session hijacking ?


The problem:
--------------
User sessions are most often kept through cookies (one or multiple
cookies).
We all know how dangerous Cross-Site-Scripting attacks can be in this
case, when this piece of information is hijacked.

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


The pros and con list:
------------------------------

PROS: Client certificates installed on the client machine can be used
CONS: This certificate can be stolen if the computer is infected, right
?

PROS: Using the clients Remote IP address as validation.
CONS: This can in some cases not be used due to internet
proxies(NATing),
and firewall load balancing and shared gateway IPs etc.

PROS: Using SSL so cookie-information is not cached or leaked in any
way.
CONS: None i recon ..?Besides rendering IPS/IDS systems useless

PROS: Setting cookies with the HTTPOnly flag.
CONS: Can be bypassed, and not all web browsers support the use of
HTTPOnly.

PROS: Using client fingerprinting like Browser User Agent, java version
etc.
CONS: Can be manipulated, and will prevent the user from using multiple
browsers
within a short timeframe.

PROS: Regenerating cookie information often, or on each request.
CONS: The "back button" will not work, and is probably not a fail-safe
solution.


Are there other fail-safe options, to make sure a users session CAN NOT
be hijacked even if the web application is vulnerable to
Cross-Site-Scripting, AND the users computer is infected.
Or at least other techniques that will make session hijacking in
general, harder .. that does not rely upon IP addresses?.


Sincerely,
Tommy


-- 
http://www.fastmail.fm - Does exactly what it says on the tin