Thread: [Phplib-users] Sessions where are we going??
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-users
|
From: Matt W. <li...@ye...> - 2002-06-29 15:44:21
|
This is NOT meant to sound ungrateful or be an attempt to undermine any of the good work that all the people who contribute to phplib have dopne and still do so please don't flame me for it it's just my opinion and observation. As we are now well into PHP 4 would it not be better to put the full weight of php4 session capabilitiess into phplib? Max has done a very good job of implementing custom sessions with the session4 class, but why are these still in the unstable tree and haven't been touched for months? Would it not be better for the future of phplib to embrace the tools that php4 has given us to work with sessions in our applications? Are there plans to move forward with the lib to implement fully php4 sessions especially with register_globals off, given the security implications of having this on. I don't really contribute to CVS but I am working through trying to get phplib going with php4.0.6 with php4 sessions and register_globals off, when I get somewhere where I feel I can move on it I will post to the list. Unless of course this has already been done, in which case I would really like to hear from you :) I think the fact that the current distro still aims itself at php3 would be a major turn off to any new users/contributors. just my 2p Matt |
|
From: Giancarlo <gia...@na...> - 2002-06-29 16:06:32
|
Il 17:39, sabato 29 giugno 2002, Matt Williams ha scritto: > As we are now well into PHP 4 would it not be better to put the full weight > of php4 session capabilitiess into phplib? IMHO PHP4 session is a scam. There is some unknown reason why it has been impossible, for almost two years now, to block creation of user-provided sids, and most graviuos, to have any setting that provides a cookie-only session mamagement. Add to that the fact that sessions among virtualhost are not differentiated, not even by the session_name. So if it happens that another virtualhost runs the same app, it will be able to open another's vhost sessions, if he knows the id, maybe because he succeeded to inject it to someone. And everything will go into HIS logs. Whith the result that PHP4 session is fully spoofable and it does not exist, and in fact it cannot exist, a php4 session implementation that wouldn't give full priority to any user-defined session passed via URL. Because of the potentially very malicious combination of the surmentioned elements, until they improve that, I don't trust php4 session anymore, except of course if you use a custom_handler for the session too. Then you are back to phplib Gian > > Max has done a very good job of implementing custom sessions with the > session4 class, but why are these still in the unstable tree and haven't > been touched for months? > > Would it not be better for the future of phplib to embrace the tools that > php4 has given us to work with sessions in our applications? > > Are there plans to move forward with the lib to implement fully php4 > sessions especially with register_globals off, given the security > implications of having this on. > > I don't really contribute to CVS but I am working through trying to get > phplib going with php4.0.6 with php4 sessions and register_globals off, > when I get somewhere where I feel I can move on it I will post to the list. > Unless of course this has already been done, in which case I would really > like to hear from you :) > > I think the fact that the current distro still aims itself at php3 would be > a major turn off to any new users/contributors. > > just my 2p > > Matt > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > No, I will not fix your computer. > http://thinkgeek.com/sf > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users |
|
From: Donncha O C. <don...@tr...> - 2002-07-01 09:38:08
|
Take a look at this site, which I linked to from my howto last week, it s= hould=20 help solve some of the security issues with php4 sessions. http://www.webkreator.com/php/configuration/php-session-security.html Basically, each vhost gets its own directory, and even session name. That= =20 should help to stop people stealing sessions from one vhost to another. I= f=20 you can chmod 700 and chown nobody:nobody the directory then local users=20 can't inspect those directories (unless they look at them through a scrip= t=20 running as nobody of course but the same applies to using a db as a backe= nd,=20 almost) Is there a phplib-dev mailing list? Hmm, no, scrap that if there is, the=20 number of people interested in developing the library seems to be low.=20 Perhaps the discussion should happen here.=20 The auth->start() stuff is/was scary and I won't pretend to understand al= l of=20 it but I'd like to help in some way. Donncha. On Saturday 29 June 2002 17:02, Giancarlo wrote: > Il 17:39, sabato 29 giugno 2002, Matt Williams ha scritto: > > As we are now well into PHP 4 would it not be better to put the full > > weight of php4 session capabilitiess into phplib? > > IMHO PHP4 session is a scam. There is some unknown reason why it has be= en > impossible, for almost two years now, to block creation of user-provide= d > sids, and most graviuos, to have any setting that provides a cookie-on= ly > session mamagement. [snip] |
|
From: Michael C. <mdc...@mi...> - 2002-07-01 14:52:48
|
On Mon, Jul 01, 2002 at 10:37:59AM +0100, Donncha O Caoimh wrote: > Take a look at this site, which I linked to from my howto last week, it should > help solve some of the security issues with php4 sessions. > > http://www.webkreator.com/php/configuration/php-session-security.html > > Basically, each vhost gets its own directory, and even session name. That > should help to stop people stealing sessions from one vhost to another. If > you can chmod 700 and chown nobody:nobody the directory then local users > can't inspect those directories (unless they look at them through a script > running as nobody of course but the same applies to using a db as a backend, > almost) From the phpauth docs: php_admin_value safe_mode 1 php_admin_value open_basedir /home/mdchaney php_admin_value safe_mode_exec_dir /dev/null php_admin_value safe_mode_allowed_env_vars PHP_ php_admin_value safe_mode_protected_env_vars LD_LIBRARY_PATH php_admin_value disable_functions system You can force PHP to confine itself to one directory, so people can't use it to view files outside their site. One should be able to make a site reasonably secure in this way. Michael -- Michael Darrin Chaney mdc...@mi... http://www.michaelchaney.com/ |
|
From: Giancarlo <gia...@na...> - 2002-07-01 11:10:29
|
> > Donncha O Caoimh wrote: > > > Take a look at this site, which I linked to from my howto last week, it > > > > should > > > > > help solve some of the security issues with php4 sessions. > > > > > > http://www.webkreator.com/php/configuration/php-session-security.html > > > > It is interesting, and in facts it clearly states that with auth, the > > session is better handled by phplib rather than PHP4. > > I'm not certain what you mean by that.. but I'm satisfied by what he says It was in facts Tarique's doc, linked from there, that says that, at http://www.sanisoft.com/phplib/manual/php4_sessions.php and I fully agree. << If you want to use phplib's auth, perms or user variables, it is better not to use PHP4's session functions, but only phplib's >> Gian > that all reasonable measures can be taken to avoid letting a web based user > take over a session. (BTW - your idea about cloning a session after > authentication? excellent.. I wonder if hotmail do something similar when > they reload their pages several times on login?) > > > I found there is a workaround to force cookie_only in php4: > > defining php.ini > > session.referer_check='someimpossiblestring' > > or something, which can force cookies all over in php4, but not on links > > clicked within an email, 'vause they have no referer. > > > > > Basically, each vhost gets its own directory, and even session name. > > > That should help to stop people stealing sessions from one vhost to > > > another. If you can chmod 700 and chown nobody:nobody the directory > > > then local users can't inspect those directories (unless they look at > > > them through a script running as nobody of course but the same applies > > > to using a db as a backend, almost) > > > > But any other vhost can run a php a script that browses there > > I know, but they can also run a php script that can access the database and > read the session data from the db. I honestly think there's only so much > you can do before the return on investment on time becomes minimal. You > could probably only guarantee security if you allow each user to run in a > chrooted environment where they can only see their own db, their own few > directories. > > umm.. d'you want this to go to the list? I'll resend there (without this > paragraph) if you do. > > Donncha. |
|
From: Donncha O C. <don...@tr...> - 2002-07-01 11:32:01
|
Ah.. I see the context of that quote now. I don't think Tarique was argui=
ng=20
that we use phplib without php4 sessions, as he wrote a document explaini=
ng=20
how to get that working. He meant that if you attempt to use the=20
session_start() (and associated PHP4 commands) outside of the framework o=
f=20
phplib then the auth, user and perms functions of phplib won't work. To q=
uote=20
his second example:
session_start();
page_open(array("auth" =3D> "Example_Auth",
"perm" =3D> "Example_Perm",
"user" =3D> "Example_User"));
Obviously here phplib has no way of "connecting" to the PHP4 session to s=
tore=20
the auth, perm and user information.
His final example lists the standard page_open() call using phplib sessio=
ns,=20
with or without PHP4 sessions as a backend/storage container.
Err.. we're all in favour of using PHP4 sessions to store phplib session =
data=20
aren't we? If you follow the advice listed in the previous webkreator art=
icle=20
mentioned in this thread then it should be as secure as using a database=20
backend.
Donncha.
On Monday 01 July 2002 12:06, Giancarlo wrote:
> > > Donncha O Caoimh wrote:
[snip]
> > > It is interesting, and in facts it clearly states that with auth, t=
he
> > > session is better handled by phplib rather than PHP4.
> >
> > I'm not certain what you mean by that.. but I'm satisfied by what he =
says
>
> It was in facts Tarique's doc, linked from there, that says that, at
> http://www.sanisoft.com/phplib/manual/php4_sessions.php
> and I fully agree.
>
> << If you want to use phplib's auth, perms or user variables, it is
> better not to use PHP4's session functions, but only phplib's >>
>
|
|
From: Tarique S. <ta...@sa...> - 2002-07-01 15:12:16
|
On Mon, 1 Jul 2002, Donncha O Caoimh wrote: > Ah.. I see the context of that quote now. I don't think Tarique was arguing > that we use phplib without php4 sessions, as he wrote a document explaining > how to get that working. He meant that if you attempt to use the Err... just to clear the facts a bit - I just maintain the documents - have re-written parts of it and re-organised them BUT definitely cannot take the claim of writing the piece in question - the email of the original author is on the said page Tarique -- ============================================================= PHP Applications for E-Biz: http://www.sanisoft.com Indian PHP User Group: http://groups.yahoo.com/group/in-phpug ============================================================= |
|
From: Giancarlo <gia...@na...> - 2002-07-01 12:09:44
|
Donncha O Caoimh wrote: > Err.. we're all in favour of using PHP4 sessions to store phplib session data > aren't we? I am not so against PHP4 session storage, as I am against PHP4 session propagation. Unfortunately the two things go together, are bundled,, unless we resume, for Max's session_custom class, the release_token, get_id methods etc that are into phplib. That is the real weak point of PHP4 session: the propagation. URL has precedence, user-provided ids make their way, there does not exist a 'cookie_only' option (which is the choice thas gives the best guarantees available) to block the former. How many people are aware that if they not set an expire for their auth, it is accessible for 24 H via a simple url? How many use fallback_mode='get' with no expire on auth? What are the advantages of letting users create sessions with any value they provide? Gian |
|
From: Donncha O C. <don...@tr...> - 2002-07-01 12:31:08
|
Great, thanks for clearing that up. There was a small bit of mixed=20 communication! The issue with php4 sessions and the URL is a serious one,= but=20 using cookies doesn't block it, it only makes it harder for an attacker t= o=20 take over a session. (They create a cookie file.. etc etc) This will be an issue for us so I'll look into it too. I remember your th= read=20 from a short while ago on the propogation issue.. Donncha. On Monday 01 July 2002 13:05, Giancarlo wrote: > Donncha O Caoimh wrote: > > Err.. we're all in favour of using PHP4 sessions to store phplib sess= ion > > data > > > aren't we? > > I am not so against PHP4 session storage, as I am against PHP4 session > propagation. > Unfortunately the two things go together, are bundled,, unless we resum= e, > for Max's session_custom class, the release_token, get_id methods etc t= hat > are into phplib. > That is the real weak point of PHP4 session: the propagation. > URL has precedence, user-provided ids make their way, there does not e= xist > a 'cookie_only' option (which is the choice thas gives the best guarant= ees > available) to block the former. > > How many people are aware that if they not set an expire for their auth= , it > is accessible for 24 H via a simple url? > How many use fallback_mode=3D'get' with no expire on auth? > What are the advantages of letting users create sessions with any value > they provide? > > |
|
From: Giancarlo <gia...@na...> - 2002-07-01 12:39:46
|
Il 14:31, luned=EC 1 luglio 2002, Donncha O Caoimh ha scritto: > Great, thanks for clearing that up. There was a small bit of mixed > communication! The issue with php4 sessions and the URL is a serious on= e, > but using cookies doesn't block it, it only makes it harder for an atta= cker > to take over a session. (They create a cookie file.. etc etc) There makes a lot of difference. Stealing a cookie is difficult, offering= a=20 'stealable' one is a lot easier. And also among 'stealable' ones, there is a difference. If you know that 'any' id can be created (and thogh re-created), you can = rely=20 that someone, once let's say has it into his bookmarks, will recreate the= =20 same id (known to the instiller from the beginning). If arbitrary id creation is not allowed, the 'instiller' has to have phhp= lib=20 generate one to him every time, and find a way to pass it again, while st= ill=20 alive, to the victim. So, not allowing the creation of id is also blockin= g a=20 good deal of social engineering. The logic that 'a horse with three legs can still walk, so it's no use' = is=20 wrong, because the next leg we cut, there will remain only two, and so on= =2E Gian |
|
From: Giancarlo <gia...@na...> - 2002-07-01 12:32:23
|
> > Donncha O Caoimh wrote: > > > Take a look at this site, which I linked to from my howto last week, it ... > > > Basically, each vhost gets its own directory, and even session name. But php4 session_name counts nothing. If siteA and siteB store in the same dir, /tmp, a session created by siteA with the URL http://www.siteA.com/i?PHPSESSID=foo can be accessed by siteB with, whose seesion name is 'Peppino', with: http://www.siteB.com/?Peppino=foo because 'PHPSESSID' or 'Peppino' count nothing, in PHP4 session parlance. > > But any other vhost can run a php a script that browses there > > I know, but they can also run a php script that can access the database and > read the session data from the db. I honestly think there's only so much Normally every vhost has its db with its passwords... of course, the other site can have a script that displays as txt the local.inc of the other site, where the pass is written.. Gian |
|
From: Donncha O C. <don...@tr...> - 2002-07-01 13:23:24
|
But I would use "session.save_path" to define a different directory for e= ach=20 site. ie.=20 /tmp/siteA /tmp/siteB If you use "safe_mode_include_dir" then each site will not get access to = the=20 other directories. Just a thought for an extra layer of protection for the user: The first time the user visits the site we set a cookie on their browser = with=20 some very random number as the key. Store the value of the key in the=20 session. Each time after that modify the key, set the cookie, and store it in the=20 session.=20 If at a later date a black-hat finds a URL then they won't be able to loa= d an=20 authenticated session because they won't have the extra cookie, or their=20 value will be incorrect. If a black-hat has compromised the system they can simply modify prepend.= php3=20 and mail that key to themselves and get in, but probably at that stage=20 they'll have access to all the login details on the db anyway. *shrug* What do you think? Donncha. On Monday 01 July 2002 13:28, Giancarlo wrote: > > > Donncha O Caoimh wrote: > > > > Take a look at this site, which I linked to from my howto last we= ek, > > > > Basically, each vhost gets its own directory, and even session na= me. > > But php4 session_name counts nothing. > If siteA and siteB store in the same dir, /tmp, > a session created by siteA with the URL > > http://www.siteA.com/i?PHPSESSID=3Dfoo > > can be accessed by siteB with, whose seesion name is 'Peppino', with: > > http://www.siteB.com/?Peppino=3Dfoo > > because 'PHPSESSID' or 'Peppino' count nothing, in PHP4 session parlanc= e. > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X