Re: How can i protect against session hijacking?

["Marco M. Morana" <marco.m.morana () gmail com>]

Tommy

interesting how you put session hijacking in perspective of XSS and pro and 
cons of countermeasures (make it and break it)

You mention XSS as a way to get session tokens from a client, you allude to 
simple ways to get valid session tokens such as for example when are passed 
as HTTP parameters in GET requests and logged by web servers and proxies 
during transmission .Other attacks include malware installed on the victim 
machine to do Man In The Middle (MiTM) as well as browser caching.
It might just be that the session can be replyed because of a web 
application is failing to kill a session at logout or failing to change the 
session cookie
after POST requests.

But let's comment on your pro and cons, it really depends on the threat that 
you would like to mitigate against. Since  you really do not know this a 
priori you probably need to apply all countermeasures that make sense.

Here is my commments on the countermeasures that you mention in your list:
1) Client certificates (mutual authentication) can be strong mitigation 
against MiTM. Assuming you for a computer infected, the victim still had to 
validate a spoofed certificate
presented my the attacker. This is likely to phish the victim but 
nevertheless is like ignoring a valid certificate from a spoofed one.

2) Using remote IP for validation. This is all cons. IP address can be 
spoofed easily. Also if you use this as a form of authentication as machine 
tagging you will be defeated by an attacker
using a proxy in the middle to hide the source IP address. You should never 
rely on this form of authentication, except maybe for internal low risk 
applications

3) SSL. Is mostly a pro.Yes cookies are not logged in this case. If the 
cookie is part of GET requests will be still shown in the browser history 
and can be replayed by someone having access to un-attended browser 
(assuming the session is still valid). SSL alone does not do the trick to 
protect session hijacking. You need to have session tokens as part of POST 
data.

4) HTTPOnlyFlag. Is a good mitigation to prevent client code accessing 
cookie even if is not strong mitigation (can be bypassed). You might want to 
add /secure parameter to prevent them traveling in non SSL channels.

5) Browser fingerprinting using user-agent header. Not sure how this helps, 
it is another spoofable identifier like IPs. He can be used for machine 
fingerprinting but nevertheless is a weak countermeasure

6) Regenerating cookie information often, or on each request. You should 
generated it at each POST data request when this data is sensitive (e.g. 
logons). You should only worry to HTTP POST 200 OK issues that is the pages 
that POST data do not have caching headers set and the reply comes with a 
redirect 302 instead of 200 OK. This will prevent session reply from un 
attended browser by replying the POST by hitting the browser back button.

In essence, you need to look at the XSS vulnerability first then to the 
threat (session hijacking) that exposes and the impact (breaking 
authentication, authorization etc). Session hijacking can be prevented by 
adapting defense in depth that means mitigate the threat at different layers 
such as the client and application. Attack vectors such as XSS can be 
mitigated as input validation vulnerability so the fact that your attack 
vector uses XSS to steal the cookie implies that you failed the first 
defense. The second defense is to adopt measures for secure session 
management among the one that you mentioned 1,3,4,6

Hope this helps

Marco
OWASP Chapter Lead

Writing Secure Software Blogger






> 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.

OWASP Chapter LeadOWASP Chapter Lead Writing Secure Software Blogger
----- Original Message ----- 
From: "Tommy" <tommyrolworslin () fastmail fm>
To: <webappsec () securityfocus com>
Sent: Friday, March 27, 2009 11:03 AM
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