Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc.... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
[ASK] Cross SIte Session Forgery
Posted by: Zoiz
Date: May 25, 2008 06:50AM

Hi There,

I am kinda new to WebAppSec, sorry if the question is lame.

Is it possible to forge a session? Let's say I initialize the $_SESSION['test'] in host A, can I get the $_SESSION['test'] value on Host B? Is it impossible? Thanks!

-Jackson

Options: ReplyQuote
Re: [ASK] Cross SIte Session Forgery
Date: May 25, 2008 08:21AM

Not possible, sorry.

Options: ReplyQuote
Re: [ASK] Cross SIte Session Forgery
Posted by: Zoiz
Date: May 25, 2008 10:03AM

Clean answer :D Thanks!

Options: ReplyQuote
Re: [ASK] Cross SIte Session Forgery
Date: May 25, 2008 10:24AM

The only way this is possible is if both hosts are of the same domain and the cookie is set for the domain .example.com on the domain you want to access the session from.

Then a.example.com can access the cookie from b.example.com since the domain for the cookie allows it to be accessed by any subdomain. That's why many sites you can find an exploit in a subdomain which will in many cases give you access to other subdomain's cookies. Either you set the domain of the cookie so it specifically constrained within a domain or make sure all your domains are secure.

Options: ReplyQuote
Re: [ASK] Cross SIte Session Forgery
Posted by: Zoiz
Date: May 28, 2008 09:39AM

Ok, Thanks CrYpTiC_MauleR ;)

-Jackson

Options: ReplyQuote
Re: [ASK] Cross SIte Session Forgery
Posted by: aschlosberg
Date: October 01, 2008 10:05PM

I suspect that you may be referring to a web client's session being forged. There are various methods by which a victim's session can be hijacked/forged.

One would be simply "coming across" their session ID and passing it as a cookie or query string as if it was your own. SSL aids in mitigating the chance of this but is still not perfect due to browser problems.

Session fixation allows for a victim's session ID to be "forced" upon them so obtaining the ID is no longer needed. An example would be by forcing the victim to visit domain.com?PHPSESSID=xyz instead of domain.com and then an attacker doing the same. The session would then be shared. This risk can be mitigated by calling session_regenerate_id(true) before any critical changes to session data.

Options: ReplyQuote


Sorry, only registered users may post in this forum.