phplib-users

Rp.: Re: Rp.: Re: Rp.: Re: [Phplib-users] Doc suggestions

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

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

>Hello, Giancarlo,
>
>> I would like to know which 
>other major scripting 
>language allows any
>> session propagation other 
>than cookie. 
>
>Any language. It is not 
>question of language. I

Ok, but this was the most'mundane' and less significant among a series of other questions:

-don't you beleive that, among these various propagations, cookies offer more guarantees
-is it right  to downgrade everybody's security to the minimum common of those  who have cookies disabled, whith an effect exactly opposite of their reason to do so. Shouldn't it be more right then to confine that to only those who cannot afford a better way?
-what other session mngmnt allows arbitrary id creation and what can be a honest use of it?
-what about issue a new session and move to it after authenticating? 
-what about keeping track of sess creation date & initial mode,  and  consider a change of mode at the same level as a new client (mode coherence?). 
- what is the use of the auth['uid']='form' status, if not better security?

Gian
 

Re: Rp.: Re: Rp.: Re: Rp.: Re: [Phplib-users] Doc suggestions

[Maxim D. <max...@bo...>]

Hello Giancarlo,

G> Ok, but this was the most'mundane' and less significant among a series of other questions:

G> -don't you beleive that, among these various propagations, cookies offer more guarantees
Yes, they do.

G> -is it right  to downgrade everybody's security to the minimum common of those  who have cookies disabled, whith an effect exactly opposite of their reason to do so. Shouldn't it be more right
G> then to confine that to only those who cannot afford a better way?

Security downgraded only for those who don't accept cookies and take the risk of
session being hijacked if urls 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.
I don't forget some obvious things that strengthen security much more
than cookie-only session, like reasonably short session and auth expiration.

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?

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 :) It
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 ...

G> - what is the use of the auth['uid']='form' status, if not better security?
I guess, It's just an intermediate state. Not quite sure ...



-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

Re: [Phplib-users] Doc suggestions

[Kristian K. <kk...@ne...>]

Am Dienstag, 9. Juli 2002 16:51 schrieb Maxim Derkachev:
> Security downgraded only for those who don't accept cookies
> and take the risk of session being hijacked if urls they get
> are stolen from the remote proxy logs or published in the
> Internet.

URL IDs leak like hell. They are being logged by proxies (true=20
for hostname and path component IDs, not true for Squid and GET=20
parameters). They leak via references header (true for all three=20
systems). They are being bookmarked (true for all). They are=20
mailed (true for all) or worse, printed in magazines.

Cookies don't do any of this. Cookies are highly preferred as a=20
mode of ID propagation.

For true security, SSL is a necessity independent of ID=20
propagation mode. Still, cookies are even preferred in this=20
situation due to references, bookmarks and mail.

> of it either. How the fact a session with id 'foo' is created
> can be a security hole?

It enables "known session id" attacks on unsuspecting end users.=20
In this attack model, Charlie sends mail with prepared URLs to=20
Bob, inviting them to Alices Online Restaurant. Since Charlies=20
invitations already contain IDs, Charlie does know Bobs session=20
ID and can hijack Bobs session easily.

A session library should check if a session record for a given ID=20
is present, and if it isn't should generate a new, random ID=20
with an empty session record, then restart the session. This=20
will protect against the above attacker model.

Kristian

Re: [Phplib-users] Doc suggestions

[Kristian K. <kk...@ne...>]

Am Dienstag, 9. Juli 2002 15:54 schrieb Giancarlo:
> -don't you beleive that, among these various propagations,
> cookies offer more guarantees=20

There are two known general modes of ID propagation. These are=20
cookies and making the ID part of the URL. The latter is always=20
deprecated, as the ID becomes part of the URL, that is, becomes

a) visible
b) logged in many proxies
c) part of bookmarks
d) is probably being mailed when a URL is mailed by a user.
e) is lost when the users browsed to a different target and later=20
returns.
f) is leaked out of the application via referer

The URL can carry an ID in three known places. These are GET=20
parameters (http://server/path/program?ID=3D...), path components=20
(http://server/ID/path/program), and hostnames=20
(http://xID.serverdomain/path/program). All of these have=20
distinct advantages and disadvantages, and all of them are=20
subject to the risks a-f shown above. Koehntopp PHPLIB only used=20
GET parameters, as they did not require special server setup=20
procedures, no special DNS setup and are not patented. It is=20
only a fallback mechanism anyway, and not worth bothering more=20
than absolutely necessary.

So an application should always try to use cookies and only fall=20
back to URL propagation if necessary.

>-is it right  to downgrade
> everybody's security to the minimum common of those  who have
> cookies disabled, whith an effect exactly opposite of their
> reason to do so. Shouldn't it be more right then to confine
> that to only those who cannot afford a better way?=20

See discussion above. Cookies are the recommended way to=20
propagate an ID, and should be used wherever possible. Note that=20
you probably have to provide a valid P3P policy in order for=20
current MSIE to accept a session cookie.

>-what other
> session mngmnt allows arbitrary id creation and what can be a
> honest use of it?=20

None. Arbitrary ID creation was an accidental artefact of the=20
Koehntopp PHPLIB implementation. In fact the original code=20
should have checked for the existence of a session with that ID,=20
and created a new ID if there was no session record present with=20
the original ID. I remember thinking about that case, and then=20
dropping it for performance reasons (that was using MySQL based=20
sessions on a 143 MHz Ultra-Sparc 1).

>-what about issue a new session and move to
> it after authenticating?=20

Why should that be useful? Sessions and authentications are=20
different and independent things and should have only little=20
interaction.

>-what about keeping track of sess
> creation date & initial mode,  and  consider a change of mode
> at the same level as a new client (mode coherence?).=20

Sorry, I am missing the previous discussion here. What exactly=20
are the problem and idea behind this?

>- what is
> the use of the auth['uid']=3D'form' status, if not better
> security?

Koehntopp PHPLIB was programmed with interstitial (blocking)=20
authentication in mind. The state machine is really only useful=20
for that, and little else. Default Auth and auth_preauth() were=20
added as an afterthought in Koehntopp PHPLIB, and are really=20
cluttering up the Auth process.=20

The whole thing should be redesigned, and using a sidebar login=20
and default authentication as the main model, as this is much=20
more common and useful than the original interstitial auth.


Note that I am not longer involved in PHPLIB development at all,=20
am no longer using PHP very much, and am reading this list only=20
sporadically. So this are just the ramblings of some old guy who=20
left you with some original code...

Kristian