Re: [Phplib-users] Doc suggestions

[Giancarlo <gia...@na...>]

 Maxim Derkachev <max...@bo...> a écrit le  9/7/02 18:51:

>Security downgraded only 
>for those who don't accept 
>cookies and take the risk of
>session being hijacked if urls

but that is not true! 
Any cookie-enabled client (that hasn't received a cookie already) is forced to 'get' mode by the simple presence of a SID in the URL.

there is a promise  in the term 'fallback' that is not maintained: that any better hook will be tried  to hold on to, before falling.

Because a client cannot be known as 'cookie enabled' on his first request (and if the client hasen't  previously received a cookie), a sid in the url is actually sufficient to treat that 'cookie enabled' client as 'cookie disabled' . 
And thus the downgrade
 
>they get are stolen from the 
>remote proxy
>logs or published in the 
>Internet.
>Nevertheless, sessions of 
>the cookie-enabled clients 
>can also be easily hijacked
>by a local person who knows 
>how to use a sniffer and has 
>an ability to use it.
>Both problems can be easily 
>resolved by one thing - SSL.

Once you know the url with the SID, SSL counts nothing.

>I don't forget some obvious 
>things that strengthen 
>security much more
>than cookie-only session, 
>like reasonably short session 
>and auth expiration.

Read it like that: 
if  the site does not use cookie-only, hope there's some expire  set.


>G> -what other session 
>mngmnt allows arbitrary id 
>creation and what can be a 
>honest use of it?
>Well, if it is a bug, It can be 
>easily fixed in PHP. Though, I 
>don't
>see any dishonest use of it 
>either. How the fact a 
>session with id
>'foo' is created can be a 
>security hole?

See KK's reply

>
>G> -what about issue a new 
>session and move to it after 
>authenticating?
>But what for? You'll get the 
>new socks with the same old 
>holes :) 

not exactly. These new sock's holes are displaced elsewhere, and by wearing these socks over the previous, you end up without holes ;-)

>adds some security through 
>obscurity, nothing more - 
>the session's
>insecurity is built-in and 
>inherited.
>
>G> -what about keeping 
>track of sess creation date & 
>initial mode,  and  consider a
>G> change of mode at the 
>same level as a new client 
>(mode coherence?).
>Could you be more precise? I 
>haven't caught the idea ...
>

when the session starts, you know its mode.  
Do not allow mode change. Stick to the initial mode.
A client should not disable/enable  cookies along the way.
A mode change is equivalent to a  client change, thus new session. 
So the downgrade-tranfer is blocked, and actual promiscuity can happen only among cookie-disabled clients.

Gian