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

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

> -----Original Message-----
> From: Giancarlo [mailto:gia...@na...]
> Sent: Monday, December 09, 2002 5:05 PM
> To: rob...@ws...
> Subject: Re: [Phplib-users] store the IP in the session
>
>
> >
> > 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.
>
> Didn't we aknowledge that a cookie-less, cookie-enabled client, by
> clicking on a link as
> https://www.xxx.yyy/?PHPSESSID=foo
> will: a) get no cookie b)create a session 'foo' on the server, and a
> file /tmp/sess_foo c) have trans_sid append ?PHPSESSID=foo to all th
> elinks in the page d) expire at gc time, but be recreated again anytime
> by clicking on the same link? And thus be a spoofable link 'ad aeternum'?
> The cases when we have a GET sid, but no referer can be:
> someone has copied on of URLs while @us, and added it to a message or a
> web page or his bookmarks. In all cases either we have no referer, or
> refere is out of our domain. We don't want to say anything, but silently
> discard our SID and redirect him to the clean URL.

  If you are not running phplib, yes.  If you are, no.  In phplib, if the
session doesn't exist, it does not automagicly create it.  I'm not sure
about php4 itself, I will look into that, but how php4 behaves does not
dictate how phplib behaves.  If the session does not exist, then the
page_open should fail.
  But if it doesn't exist, who cares if we create one.  It's empty?  Best
practices should certainly be that we don't allow things to be forces, I
agree totally.

>
>  > Which
> > is a CSX and would require scripting.
>
> Scripting is required to modify a page's link to increase that
> user-definable SID. Dunno if this would stay right iside the url string
> (so that can be parsed out), or may stay elsewhere in the page. Dunno
> much JS.
>
>
> > 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.
>
> I will explain that two-part URL better. it is composed of two half, as
> ?MySess=111111/aaaaaa
> The 111111 is just our unpredictable md5 as before, and is the key of
> the session record. The 'aaaaaa' part is never the same. Every link is
> made different from the previous, the aaaaaa is taken from a list of
> pregenerated ones. Each time is taken one, is marked as taken. Everytime
> is used one, is marked as used. New ones are taken from those not yet
> taken nor used. One can be taken-and used on the fly, so it does not
> need to be 'taken' to become 'used'.
>
> Suppose that the random pregenerated list is:
> aaaaaa
> bbbbbb
> cccccc
> dddddd
>
> ;-)
>
> So in a page your links look like:
>
> page1.php?Mysess=111111/aaaaaa
>
> page2.php?MySess=111111/bbbbbb
>
> Page3.php?MySess=111111/cccccc
>
> and so on.
>
> To avoid locks, the pregenerated keys can be stored in a dedicate table,
> with the name and id as keys as in active_sessions.
> A page can also 'preask' an fair enough amount of keys for it's use,
> mark them all 'taken', and free the unused ones before end,, to
> quickify... There can be an asyncronous job that refills the fresh keys
> when nearly ended, or use triggers.
>
> In practice only those present can know the links. And each is clickable
> only once. The only way I can think this can be spoofed is when sent by
> the person itself. The browser back can work if the cache settings are
> correct.
>
>
> > There also has to be a reuse window because multiple frames may
> > be changed at the same time using the same ID.
>
> Each id is different
>
> Anyway this is just fantasy.  It seems you are among the few that seem
> concerned about the things I mentioned.  I like the things you proposed
> for session, I wonder how much are they possible with php4 propagation,
> which is little hackable. Sure having a phased C routine do anything is
> a lot faster, but this can be THE sensitive part of it all.
> I think we should keep the PHP4 propagation (cookie/get) module as a
> whole choice, and define a separate phplib 'propagation' module. In th
> eand we have an auth to care about, php4 hasn't. This would repeche
> pieces of the sessio class, as Maxim has started doing already,
> otherwise there is no 'custom_propagation functions' for coding this in
> PHP4.

You can control the php4 Session ID though and override the php4 behavior.

>
>
> Gian
>
>