RE: [Phplib-users] store the IP in the session

[Rob H. <rob...@ws...>]

>
>
>   > This is a cross site scripting vulnerability inherent to the way HTTP
> works.
>
> There is no scripting involved here, it is a plain url.
>

But where does the url come from.  You were talking about clicking on a
dangerous url which would steal the session id and send it somewhere.  Which
is a CSX and would require scripting.

>   > There is nothing we can do to prevent this.  If someone allows HTTP
> entry on
>   > their site,
>
> You can prevent scripting by parsing quotes etc, because they are not
> allowed inside links.  If a link is a danger, any wiki or annotation
> becomes a danger. Credentials in the url, if treated, should be sorta
> quaranteened or screened, and not alloweb do mixmax. That's way I
> propose 'unrepeatable' use-once sequences, made of a fixed part and a
> secretly preagreed rest. Dunno if amazon does so ;-)

But as previously discussed, this is not effective in a connectionless
environment where the time between connection may easily be in the order of
10 to 15 minutes.  It would be easy for someone to hijack the session in
that time.  There also has to be a reuse window because multiple frames may
be changed at the same time using the same ID.  If the reuse time is say, 30
seconds, then someone else has 30 seconds to insert themselves into the
session without the other person ever knowing it.  Again, this is a false
layer of security.

>
>   > then that is the risk they take.  This could easily enough occur
>   > with another security breach and a page replacement.  This is an
> application
>   > question.
>   >
>   > Referer is not set in the case of Javascript navigation, page refresh,
>   > typeing in a direct url, etc. etc. etc.
>

Because there are MANY sites that use Javascript navigation.

> Ok, so why should I accept a GET sid  without a referer?
>
>
>   >>it intervenes only when there is a referer. But we can block
> when there
>   >>is no referer
>
>   > Yes, so use SSL.   Problem solved.
>
> Again you forget links :
>
> https://aaa.com/?PHPSESSID=foo

No I didn't.  If you are clicking on a link like this, then it has been
generated using a CSX vulnerability.  If you are receving a link like this,
then the best that you can do at this point is store the last mode that the
session was running in and not accept get if mode change protection is
turned on.  Maybe a sticky flag like you said.

>
>
>   > Here is an example:
>   >
>   > XYZ has written an app that does not do input filtering and someone
> enters
>
>
>   > javascript to read the session cookie and send it to them.
> They get it,
>   > creat the cookie, and now they can hijack the session.  No matter how
> much
>   > code is written, without some method of identifying the remote user,
> either
>   > through a certificate or something.
>
> That hasn't taken off in so many years now...

Then what are you trying to prevent?

>
>
>   > You are trying to solve a problem that has plagued tcp for years.
> If you
>   > open a session, and someone guesses the sequence number,
>
> anyone can tell to use 'foo', with php4 session!

Which is another reason that I argued against the movement toward just
native PHP4 sessions.  The phplib wrapper prevents this by default if you
are running in cookie mode and doing things correctly.

>
>   > then they can
>   > hijack the session.
>
> #281
> Gian
>
>
>
>


Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271