WebApp Sec mailing list archives
Re: Re: Custom session tokens and XSS
From: Mark Reardon <riscorp () mindspring com>
Date: Thu, 14 Aug 2003 10:56:37 -0400 (GMT)
The reason to log a session out when a bad token is received is so that if someone steals the token (somehow), then the real user's next use of their token will cause the attacker to get logged out. It opens a denial of service capability but closes another hole. Mark -------Original Message------- From: Ingo Struck <ingo () ingostruck de> Sent: 08/14/03 04:52 AM To: PortSwigger <mail () portswigger net> Subject: Re: Custom session tokens and XSS
-----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-----
---- Mark Reardon Reardon Information Security Corporation (404) 444-0041
Current thread:
- Re: Custom session tokens and XSS, (continued)
- Re: Custom session tokens and XSS Cyrill Osterwalder (Aug 13)
- Re: Custom session tokens and XSS PortSwigger (Aug 13)
- Re: Custom session tokens and XSS Ingo Struck (Aug 14)
- Re: Custom session tokens and XSS PortSwigger (Aug 14)
- Re: Custom session tokens and XSS Ingo Struck (Aug 14)
- Re: Custom session tokens and XSS Ian (Aug 14)
- Switching off scripts Ingo Struck (Aug 14)
- Re: Custom session tokens and XSS PortSwigger (Aug 14)
- Re: Custom session tokens and XSS Stephen de Vries (Aug 14)
- Re: Custom session tokens and XSS Ingo Struck (Aug 14)