Re: Custom session tokens and XSS

[PortSwigger <mail () portswigger net>]

What Ingo correctly describes is a "normal" session fixation scenario in which 
the attacker induces the user to login to an application using a session 
token already in the possession of the attacker, who then accesses the 
victim's application data using this token.

But the fixation idea was introduced here in a different context -- i.e. as a 
means to exploit XSS-style vulnerabilities in an application which uses a 
custom session token in a hidden form field, and where each request must 
contain a valid token, or the user is bounced back to the login page. To 
exploit XSS here, simply passing the user a crafted URL (or suchlike) won't 
work, as the user's request won't contain a valid session token (in contrast 
to the situation where conventional cookies are used, where the browser would 
automatically submit the user's cookie with the request). So what was 
envisaged was that the attacker obtains a valid token, and causes the user to 
make a POST request containing this token plus the XSS payload (e.g. by 
sending the user a suitable HTML-encoded email).

This would indeed succeed in injecting arbitrary HTML/JavaScript into the 
victim's browser (which could do a lot of malicious stuff) but what it 
couldn't straightforwardly do is hijack the existing session of a logged-in 
user, and _this_ is an important difference between the behaviour of 
conventional cookies and session tokens in hidden form fields.

Cheers,
PortSwigger.


On Wednesday 13 August 2003 14:45, Cyrill Osterwalder wrote:
> I completely agree with Ingo. This kind of attack is a special case of the
> general session fixation attack.
>
> Cyrill
>
> ---------------------------------------------------
> Cyrill Osterwalder
> Chief Technology Officer
>
> Seclutions AG               Phone  +41  1 366 88 00
> Ottikerstrasse 59
> CH-8006 Zuerich
>
> PGPKey ID :0xC70E7ACB
> PGPKey FP :5C84E132BBD50AB1627BF873D3B6CAF4C70E7ACB
> PGPKey URL:ldap://certserver.pgp.com
> PGPKey URL:http://pgpkeys.mit.edu:11371
>
> http://www.seclutions.com
>
>
> --On Mittwoch, 13. August 2003 14:45 +0200 Ingo Struck <ingo () ingostruck de>
>
> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi...
> >
> > > I think I may be misunderstanding this,  but if the attacker makes a web
> > > request and gets a valid token, it will be a valid token for HIS
> > > session. By creating a malicious email/web page with this token, the
> > > victim will be opening the attackers session!
> >
> > Yeah, that's exactly a successful attack!
> >
> > > Any XSS in the page, will only have access to the attackers token -
> > > which is useless from an attack point of view.
> >
> > This is *NOT AT ALL* useless from an attack point of view:
> >
> > a) attacker creates a session token
> > b) attacker tricks victim to use "his" session token
> > c) victim logs in on this session
> > d) attacker has still access to the session and thus can do anything
> > the victim could do too.
> >
> > Of course this only works, if the application does not switch session id
> > upon login (most don't!) and if the application does not check for equal
> > source IPs (most don't).
> > That's why it is strongly recommended at least to switch session tokens
> > upon login; checking source IP for subsequent requests is a nice-to-have
> > but may close off users who come frome providers with dynamic IP
> > allocation.
> >
> > Kind regards
> >
> > Ingo
> >
> > - --
> > ingo () ingostruck de
> > Use PGP: http://ingostruck.de/ingostruck.gpg with fingerprint
> > C700 9951 E759 1594 0807  5BBF 8508 AF92 19AA 3D24
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.0 (GNU/Linux)
> >
> > iD8DBQE/OjL8hQivkhmqPSQRAr6KAJ9z0lNbwutL1ba4pGpY3aEoV8OnMwCePl6k
> > RuthsqpwJx/GXUzAYOIOu3Y=
> > =NTA7
> > -----END PGP SIGNATURE-----