You can find an example page and combined vulnerabilities below URL. This example login page is affected by Predefined Post Authentication Session ID Vulnerability. This vulnerability can lead a social engineering scenario or other hijacking attack scenarios when mixed with other vulnerabilities (such XSS).
For proof of concept: http://www.iosec.org/iosec_login_vulnerable.php Predefined Post Authentication Session ID Vulnerability is a Vendor-neutral vulnerability and it let attackers to design new attack scenarios. A lot of web application on the Internet affected by this vulnerability. ----------------------- Vulnerability Name: Predefined Post Authentication Session ID Vulnerability Type: Improper Session Handling Impact: Session Hijacking Level: Medium Date: 10.07.2012 Vendor: Vendor-neutral Issuer: Gokhan Muharremoglu E-mail: [email protected] VULNERABILITY If a web application starts a session and defines a session id before a user authenticated, this session id must be changed after a successful authentication. If web application uses the same session id before and after authentication, any legitimate user who has gained the "before authentication" session id can hijack future "after authentication" sessions too. MITIGATION To avoid this vulnerability, sessions must be regenerated after a successful login. In a session fixation attack, attacker fixates (sets) another person's (victim's) session identifier because of "never regenerated and validated" session id and this vulnerability can also lead to the Session Fixation attack or etc. Gokhan Muharremoglu Information Security Specialist (CEH, ECSA, CIW-Web Security Professional, Security+, EXIN 27002 ISFS) -----Original Message----- From: Jann Horn [mailto:[email protected]] Sent: Friday, July 13, 2012 2:06 AM To: Gokhan Muharremoglu Cc: [email protected] Subject: Re: [Full-disclosure] Predefined Post Authentication Session ID Vulnerability On Wed, Jul 11, 2012 at 11:34:11AM +0300, Gokhan Muharremoglu wrote: > Vulnerability Name: Predefined Post Authentication Session ID > Vulnerability > Type: Improper Session Handling > Impact: Session Hijacking > Level: Medium > Date: 10.07.2012 > Vendor: Vendor-neutral > Issuer: Gokhan Muharremoglu > E-mail: [email protected] > > > VULNERABILITY > If a web application starts a session and defines a session id before > a user authenticated, this session id must be changed after a > successful authentication. If web application uses the same session id > before and after authentication, any legitimate user who has gained > the "before authentication" session id can hijack future "after > authentication" sessions too. Uh, so, erm, you assume that someone can steal my cookie/set it/whatever although the Same Origin Policy should clearly not allow that, and then, after I have logged in, he can't just steal my cookie? Unless you allow setting the session-ID via an URL or so (which would IMO be pretty stupid), I can't see how this is a realistic, vendor-neutral attack. Could you explain this a bit better? I don't get it. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
