Re: Custom session tokens and XSS
On Wed, 13 Aug 2003, Ingo Struck wrote:
> > By creating a malicious email/web page with this token, the victim will be
Not really, because the attacker has not stolen the victims session, all
he has done (as you state below) is that the attacker is running the
attackers session, in the victims browser. All other XSS attacks apply,
but not stealing the session.
> 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.
I understand a-d, but I still don't see how the attacker is going to steal
the victims session token.
Let's say this is a banking application. The procedure you've described
above will allow the _victim_ to transfer funds from the attackers
session, since the only valid session token is the attackers.
At point d, the victim is now running the attackers session (with the
attackers token) in his browser. How does the attacker get the victim to
regenerate another session token, this time for their own (ie.
victims) session and still have the ability of stealing this token?
Stephen
>
> 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
Received on Wed Aug 13 09:15:41 2003
This archive was generated by hypermail 2.1.8
: Wed Aug 23 2006 - 14:07:54 EDT
|