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

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

>  > OK, but if they are smart enough to sniff a cookie off of the
> wire, then
>
> I am always talking about unadvertely clicking on a link like
> https://www.www/www?PHPSESSID=1
> somewhere you click on that link that brings your cookie enabled site
> where, in case I'll register or login or simple visit, someone can
> reenter in my place and start from the situation as when I left.

This is a cross site scripting vulnerability inherent to the way HTTP works.
There is nothing we can do to prevent this.  If someone allows HTTP entry on
their site, 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.

>
>  > they are smart enough to set one.  That's what we are trying
> to prevent,
>  > correct?  The movement from cookie to GET?
>
> Both, but most worry is from get to cookie. From less to more trust &
> persistance. Catching this, supposes first that a cookie header is sent
> anytime even there is a GET request, and not to interprete the presence
> of GET sid as 'non availability of cookies'.
> We have two type of tickens at the cine. One is for a isolated, more
> aseptic, gallery upstair. The other is for the more promiscuous platea
> down, all together, where there's a lot of germs and it's easier to
> catch an influenza ;-)  You don't do well to your clients that should be
> lodged in area A to direct them down in  area B. And you don't do well
> either when you let people coming from area B enter area A.

So have one auth that only supports GET, and one that only supports cookies.
There is nothing to prevent this right now!

>
> Also the referer_check, in case the sid is in the url, is very useful. A
> must I think. There is a php.ini directive,
>
> session.referer_check = www.www

Referer is not set in the case of Javascript navigation, page refresh,
typeing in a direct url, etc. etc. etc.

>
> it intervenes only when there is a referer. But we can block when there
> is no referer
> Bookmarks have no referer, as links in email messages. GET SIDs without
> a referer,
> should be checked. This would block a good deal. I don't like the idea
> that the session management I implement is so easy to spoof on the
> massive, by absolutely whoever wants, with just a browser. The link
> itself becomes a troian.

Yes, so use SSL.  Problem solved.  The CSX vulnerabilities are not solvable.
They are inherent in the design of HTML.  They require user dillagence to
address to some extent, and non stupid programming on the others.  PHPLib
should not allow CSX in its own code.  But we are talking about people
writing programs whose job it is to make them secure.  All it takes to avoid
a CSX is to encode any HTTP traffic you get back.  Then anything inside a
link gets treated as text.

If what you want is to protect from csx's, then write a filter function that
all submitted URLs get run through.  This does not effect cookies anyway.
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.  The best we can do right now is inform
in the docs.  If they don't read them, that's their fault.

You are trying to solve a problem that has plagued tcp for years.  If you
open a session, and someone guesses the sequence number, then they can
hijack the session.  Fortunately, in the TCP world there is connection
oriented information.  In the HTTP world, there is no connection, just
persistence.  As in, you can make an object persist from connection to
connection.  The availability of a cert provides some amount of "connection"
information.  If the SSL session ID was reliable, then that would be a good
identifier.  Until there is, we will beat our head against the wall trying
to fix a problem that is inherent in the protocol.

> It's message #280 by me on this subject. Dunno why everytime I restart
> this music, some patch reminded me ;-), I am tired . It's so easier to
> exploit this by anyone, than to explain it to the experts. I even don't
> care anymore. Forget this and don't worry.
>
> G
>


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