But you have already stored the IP address of the
attacker who created the session. Therefore when the
victim connects to your web app, you do not allow them
in because the IP address does not match what is
currently stored in the session information.

--- "Sverre H. Huseby" <shh (at) thathost (dot) com [email concealed]> wrote:

> [Elihu Smails]
>
> | Sessions should track the remote IP address of
> the client at a
> | minimum, so that this problem could go away.
>
> Unfortunately, checking IP addresses won't solve the
> Session Riding /
> Web Trojan problem, as the request is coming from
> the victim's
> computer.
>
>
> Sverre.
>

__________________________________
Do you Yahoo!?
Dress up your holiday email, Hollywood style. Learn more.
http://celebrity.mail.yahoo.com

[ reply ]

But you have already stored the IP address of the<br/>
attacker who created the session. Therefore when the<br/>
victim connects to your web app, you do not allow them<br/>
in because the IP address does not match what is<br/>
currently stored in the session information.<br/>
<br/>
--- "Sverre H. Huseby" <shh (at) thathost (dot) com [email concealed]> wrote:<br/>
<br/>
> [Elihu Smails]<br/>
> <br/>
> | Sessions should track the remote IP address of<br/>
> the client at a<br/>
> | minimum, so that this problem could go away.<br/>
> <br/>
> Unfortunately, checking IP addresses won't solve the<br/>
> Session Riding /<br/>
> Web Trojan problem, as the request is coming from<br/>
> the victim's<br/>
> computer.<br/>
> <br/>
> <br/>
> Sverre.<br/>
><br/>
<br/>
__________________________________ <br/>
Do you Yahoo!? <br/>
Dress up your holiday email, Hollywood style. Learn more. <br/>
http://celebrity.mail.yahoo.com

[ reply ]