Re: Custom session tokens and XSS

[PortSwigger <mail () portswigger net>]

Hi -- it was the constant type of token that I had in mind.

But your session fixation attack isn't what I was interested in -- I presume 
it could be stopped in the usual way by issuing a fresh token on each login. 
I was interested in the possibilty of hijacking an existing, already 
logged-in, session via XSS vulnerabilities in the situation where a hidden 
form field is used to transmit the token. Standard attacks like giving the 
user a crafted URL don't work, as their request won't contain their token and 
so they effectively leave their prior session (in contrast to what happens 
with cookies). The "fixation" issue arose as a way to frame a valid request 
which, when made by the user, would succeed in injecting the XSS payload into 
their browser (and avoid bouncing back to login). But again here, the user 
will leave their prior session and join the attacker's -- whilst the attacker 
will be able to inject his payload (which is bad) he won't be able to 
straightforwardly steal the user's prior (now abandoned) token.

Cheers,
PortSwigger


On Thursday 14 August 2003 09:52, Ingo Struck wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi...
>
> Well, maybe it's a problem of terminology... ;o)
> You talk of a
>   "custom session token in a hidden form field".
> - From that I would conclude that this token remains constant over the
> complete session. If it is like that, i.e. constant, then it makes no
> difference if you submit the session id (SID) with hidden form fields or
> any other mechanism. If the victim gets tricked into logging in on that SID
> (be it with a scripted POST request or not), then the attacker has
> effectively exactly the same chance to do whatever he wants with that SID.
>
> - From what you write further on, I conclude that you're talking of a
>  "transaction token" that changes on a per-request basis rather than a
> "session token".
> If you meant that, then you're of course right:
> Even if you trick somebody to login with a valid transaction token,
> then that token changes with the next response / request cycle and
> the attacker has no clue about that next token.
> Implementing that is a good thing against the simple "session foisting",
> but still open to mitm attacks.
>
> You say, that if the request does not contain a valid transaction token,
> then the user is passed to the login page (which implies that the old
> session will be invalidated). I wouldn't implement it like that but rather
> pass a 403 back. Logging off the user on invalid requests opens up the
> chance for attackers to log off other users with invalid requests. You
> should rather simply drop illegal requests
>
>
> 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/O03JhQivkhmqPSQRAv6NAKDN0qSyDlRyA8bjZneaMObQYFMCjgCg1mGo
> xjv8tgPZKGkLsszXNIVyQiw=
> =LmVX
> -----END PGP SIGNATURE-----