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

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

>
> Rob Hutton wrote:
> > This could be easily addressed by maintaining a list of unique,
> > non-incremental ids that are valid for a certain period of
> time, exactly the
> > way IP does it.
>
> You mean a single overall list, server wide, not a per session one?

No, it would be a list per session.  The problem is that if you have frames,
then you will get a different id per frame, and at any time, one of those
frames may resubmit, with whatever the value is at the time, so you have to
maintain a list of acceptable ids so that you don't break frames.  There may
be multiple submissions from different frames with the same unique ID, or
you could have multiple submissions from different frames with different
IDs.  But you don't want them to be available forever, so there has to be an
expirations on them.

>
> > The scheme wouldn't even have to be blocking, and could
> > allow multiple frames to use the same ID as long as it was within the
> > lifetime of the list.
> >
>
> The blocking/non blocking I was thinking about... By non-blocking you
> mean 'shared', or 'that can be used again'?  In reality if you use the
> same validator on multiple links, you block them, because only one can
> be clicked. I don't think you can flag some as 'usable more the once',
> otherwise the security evaporates. Unless when you reuse one of these,
> you mark as 'used' all the still unused ones, and regenerate them again
> in that page. A lot of work.

Blocking means that only one process can have a particular session open at a
time.  So, there is a switch on the session record which is something like
locked, if locked, then you wait X time.  When X has passed, you try again.
You go through that Y times.  Then you fail.

>
>
> > The problem is that this does nothing to tie the session to a certain
> > machine.
>
> But that would be great way forward anyway. Imagine, no more
> cookie burden.

You still have the problem with cookies as you may have a machine where the
same person has multiple sessions open.  There is always going to have to be
a way to tie the session ID to a particular browser session, even if has
been authenticated and cannot be hijacked.

>
>  > The only way to do this is with public key authentication.
>
>
>
>


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