Re: How can i protect against session hijacking?

["Michael Condon" <mjc001 () juno com>]

I found this to be a very good reference (which you may have seen before) 
for XSS and other vulnerabilities: 
http://www.sans.org/top25errors/print.pdf.
OWASP covers it very well also.
However the outlook, in my opinion is somewhat bleak. Read through the 
documentation, and the mitigation methods usually (for good, proven 
reasons - some very well known and obvious) have a disclaimer about how most 
methods can be circumvented. It's almost as if we're down to throwing 
bottle, rocks, etc. at every level - from HTML, JS, Ajax, Session control, 
Server Side code, and finally at the DB - and hoping that the attacker is 
too wounded to persist. Even SSL has been shown to have its vulnerabilities, 
even though seriously the probability of this being an issue is low given 
the expertise required.
I personally have a few standards, which may help, or you can disregard.
- I decided from day one (ok, maybe two) never, ever to pass parameters in a 
URL. In fact, my PHP programs check the QUERY_STRING in the first few lines 
of code (EVERY program), and if something is there, I send the user into a 
triangular loop. This hoses up a lot of automated "testing" tools. I also 
"punish" the user if I get obvious indication at the server side that they 
are pushing crap data.
- Since the HTTP header is unreliable, the full script path is a better, but 
still not infallible alternative.
- Every level of code, script or module should by default mistrust every 
attempt at access.
- DB design should contain referential integrity, for another layer of self 
protection.
- Don't let anyone sit around indefinitely. For example, I had a credit card 
company that would allow you to sign on (SSL of course, but no strong 
password enforcement), and then allow the statement pages to be displayed 
for an indefinite amount of time. Unbelievable. I can think of a lot worse 
ways to express it, but I'll leave it there.

I could go on at length, but strong session management is essential. 
However, checking the end user IP, User Agent and other similar methods are 
questionable, since these can legitimately change. However there's no harm, 
and indeed recommended, reverting to a "start over" state if encountered.

I'm also still at an impasse as to whether proven unreliable mitigation 
methods should be implemented regardless. Not to be relied upon by any 
means, but just as another layer of defense that would prevent/delay x% of 
intrusions. As sort of a poll, what do all of you think regarding this 
issue - waste of code, or more obstacles, the better?

I'm working on some other methods, but actually I'm hesitant to even post 
any ideas. My current approach is to assume that all firewalls, IDS, etc. 
are irrelevant. The code has to protect itself. If someone can get to your 
site, all bets are off.


--------------------------------------------------
From: "Rohit Sethi" <rklists () gmail com>
Sent: Thursday, April 02, 2009 8:00 PM
To: "Martin O'Neal" <martin.oneal () corsaire com>
Cc: "Cyrill Osterwalder" <c.osterwalder () phion com>; "Chris Grove" 
<cgrove () imperva com>; <webappsec () securityfocus com>
Subject: Re: How can i protect against session hijacking?

> Tommy,
>
> It's clear that session hijacking is only one many problems that
> you've outlined in your scenario. If you have XSS an attacker *doesn't
> need* to steal a session - he can execute his entire attack through
> the client via a set of CSRF AJAX requests and responses.
>
> What you should really be asking yourself here is "what in the session
> am I trying to protect?" Your application probably has many different
> transactions - which ones are the most sensitive? For instance, can
> people steal credit card numbers or transfer money in your
> application?
>
> For those transactions, your should consider using transactional
> authentication - forcing the user to use a different factor of
> authentication for paritcularly high-risk transactions. One time
> passwords are ideal for transactional authentication. If you can't
> afford to distribute hard tokens consider using something like
> www.phonefactor.com (they have a free service as well as commercial
> versions). I can't vouch for phone factor personally but I know it's
> come up on this list before.
>
>
>
> On 4/2/09, Martin O'Neal <martin.oneal () corsaire com> wrote:
> > > There are WAFs available on the market
> > > that implement secure session handling...
> >
> > LOL; thanks for the comment, but to paraphrase, you're basically
> > suggesting adding another technology to the mix (one that the client
> > will be unlikely to be familiar with, but will have to maintain both
> > from a platform and skills perspective), and rather than fixing the
> > application, you duplicate some functionality into the WAF, which
> > (unless you fix the XSS [in the WAF or application]) won't actually help
> > with the lost session ID anyway, as the attacker will be still running
> > mobile code in the users browser session, with access to everything that
> > the user has; source IP, cookies, blah-blah-blah.
> >
> > Doesn't sound like a particularly ideal solution to the scenario to
> > me...
> >
> > Martin...
>
>
> --
> Rohit Sethi
> Security Compass
> http://www.securitycompass.com
____________________________________________________________
Durable and cost effective steel buildings. Click for huge discounts.
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTMIFKY2OzXICcn4rSw0SaERQOVNPincqCafK6daJW1d7KM0s3QL7a/