Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Re: How to create (hijacking) secure HTTP sessions?

Subject: Re: How to create (hijacking) secure HTTP sessions?
Date: Sat, 3 Jun 2006 08:49:04 +0100
On 6/1/06, Michael Decker <MDecker@tesis.de> wrote:
        Hi!

I tried to figure out, how to create HTTP session, that are not so easy
to hijack.

So I think about that mechanisms:

* Using HTTPs
* Randomize HTTP session IDs
* Only create HTTP session ID after login
* HTTP session ID joined with IP and SSL session ID
* Block all session ID usings, that do'nt match IP and SSL session ID
* Set HTTP session timeout
* Expire HTTP session after logout

You've missed two mechanisms that work 100%:

* Use private client certificates and attach certificates to session IDs.

* Use Digest for authentication. (Yes, I know, not very likely.)

You can also add:

* Session inactivity timeout.

* Only create HTTP session ID after login

This should be "Re-generate session IDs after authentication takes place". In many situations you will need to have a proper session even before authentication, if not for anything else then for tracking purposes.


Is that all? Is there any mechanism, that isn't a good idea?

...

* Using HTTPs

Do not mix SSL sections with non-SSL sections. Mark cookies "secure".

* Randomize HTTP session IDs

But they should also be long, not start repeating too fast, and not based (only) on the information also known to the attacker (e.g. IP address).

* HTTP session ID joined with IP and SSL session ID

Here you need to have in mind that there's nothing in the spec to say the browser must continue to use the same SSL session throughout the application session. So while this works in some circumstances it doesn't in many others.

* Block all session ID usings, that do'nt match IP and SSL session ID

Depending on where your users are you may realise their IP address will change during the session (if they are using a proxy or ISDN to connect to the Internet). It's probably better to use the User-Agent field but that does not protect you from a determined attacker (who can spoof it). PI prefer to only log the violations of the changes to the IP address and the User-Agent field.

--
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall

-------------------------------------------------------------------------
Sponsored by: Watchfire

Watchfire named worldwide market share leader in web application
security assessment by leading market research firm. Watchfire's AppScan
is the industry's first and leading web application security testing
suite, and the only solution to provide comprehensive and consolidated
remediation task lists at every level of the application. See for
yourself.
Download a Free Trial of AppScan 6.0 today!

https://www.watchfire.com/securearea/appscansix.aspx?id=701300000007t9c
--------------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>