phplib-users — A list for users of phplib to talk / discuss phplib

Re: [Phplib-users] Re: [phpslash-users] Hello -- I could use some help

[Michael C. <mdc...@mi...>]

On Thu, Nov 07, 2002 at 11:21:41AM -0500, Rob Hutton wrote:
>   There is no way in MySQL to do it automagicly because there is no foreign
> key support.  Even if they didn't actually enforce data integrity rules, it
> would be nice to have them just because of the modeling.
>   That said, I do most of my modeling for simple stuff in *choke* Visio.  It
> will read the table definition through odbc and then you can drop the
> relationships in failry easily.

Another product, and the only Microsoft software product that I ever
recommend, is Access.  Hate it if you want, but it does allow you to
draw the relationships between tables and design queries, even queries
that are too complex for MySQL, quite easily.  It's almost 100% SQL-89
compliant.

Just please don't use it for programming.  Reporting, modeling (to an
extent), and ad-hoc querying are pretty strong, and last I bought it it
was still $99.

Michael
-- 
Michael Darrin Chaney
mdc...@mi...
http://www.michaelchaney.com/

RE: [Phplib-users] Re: [phpslash-users] Hello -- I could use some help

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

  There is no way in MySQL to do it automagicly because there is no foreign
key support.  Even if they didn't actually enforce data integrity rules, it
would be nice to have them just because of the modeling.
  That said, I do most of my modeling for simple stuff in *choke* Visio.  It
will read the table definition through odbc and then you can drop the
relationships in failry easily.

Thanks,
Rob Hutton
Web Safe
www.wsafe.com

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Joe
> Stewart
> Sent: Thursday, November 07, 2002 10:59 AM
> To: 'phplib-users'
> Subject: [Phplib-users] Re: [phpslash-users] Hello -- I could use some
> help
>
>
> Hey, can anyone suggest a way to model the database relationships for
> Kareem?
>
> thanks,
>
> Joe
>
> On Thu, Nov 07, 2002 at 09:08:20AM -0500, Kareem Lawrence wrote:
> > Joe,
> >
> > Since you can't recommend a product like ERwin that will allow
> me to view
> > the database schema. Can you recommend a method by which I can
> determine the
> > relationships between the tables in the database? This would be
> very useful
> > to me for any additions I may want or need to make. Using this
> as a teaching
> > tool for myself. Do you think you could help?
> >
> > Kareem
> >
> > -----Original Message-----
> > From: Joe Stewart [mailto:jo...@be...]On Behalf Of Joe Stewart
> > Sent: Tuesday, November 05, 2002 12:24 PM
> > To: Kareem Lawrence
> > Subject: Re: [phpslash-users] Hello -- I could use some help
> >
> >
> > On Mon, Nov 04, 2002 at 12:30:44PM -0500, Kareem Lawrence wrote:
> > > Joe,
> > >
> > snip!
> >
> > > One very important thing that PHPSlash has
> > > over it is the ability to associate a single story to
> multiple areas of a
> > > web site. If brief overview of underlying db of PHPSlash it would seem
> > that
> > > what it's missing is a collections table that aggregates the
> associations.
> >
> > I may be misunderstanding but...
> >
> > While integrity is maintained for the associations, I don't think all
> > pageviews use the same associations.
> >
> > > What would be really useful to me is to get a data modeling
> product like
> > > ERwin to view these relationships more clearly so that I don't have to
> > rely
> > > on my (usually faulty) suppositions. Can you recommend something?
> > >
> >
> > Sorry. no.
> >
> > later,
> >
> > Joe
> >
> > > Kareem
> > >
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

Re: [Phplib-users] Re: latest snapshot

[Michael C. <mdc...@mi...>]

On Wed, Nov 06, 2002 at 10:41:56PM +0100, Giancarlo wrote:
> the requested url  passes in cleartext, even with SSL
 
If that were the case, we could do name-based virtual hosting with ssl.
 
When you use SSL, the entire connection is encrypted.  If you want to
see this in action, use the openssl command on a unix machine (with
openssl installed) to connect to a web server:
 
% openssl s_client -connect www.hotmail.com:443
{bunch of information about the certificate and connection}
HEAD / HTTP/1.0
 
HTTP/1.1 302 Redirected
Server: Microsoft-IIS/5.0
Date: Thu, 07 Nov 2002 16:11:40 GMT
Location: https://lc1.law5.hotmail.passport.com/cgi-bin/login
 
read:errno=0
%
 
Note that the "HEAD / HTTP/1.0" is the request, and "/" is the URL.
 
Michael
--
Michael Darrin Chaney
mdc...@mi...
http://www.michaelchaney.com/

RE: [Phplib-users] sending the url of a protected page

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

I modified session self_url to be:

   return $this->url($HTTP_SERVER_VARS['PHP_SELF'] . "?" .
$HTTP_SERVER_VARS['QUERY_STRING']);

Then, the submit button on the login form calls $this->url() ($this refers
to the current auth object which points at $sess->url();

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Richard
> Archer
> Sent: Thursday, November 07, 2002 2:41 AM
> To: php...@li...
> Subject: [Phplib-users] sending the url of a protected page
>
>
> Hi,
>
> I'm having a brain-block here... must be the heat.
>
> I want to send via email a URL like:
> https://www.example.com/blah.php?id=123
>
> The blah.php script requires admin permissions.
>
> I want it to put up the interstitial login screen then show the
> results of the "id=123" query.
>
> I can't work out how to do this, but I'm sure it must be possible!
> How??
>
>  ...Richard.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

[Phplib-users] Re: [phpslash-users] Hello -- I could use some help

[Joe S. <jo...@cm...>]

Hey, can anyone suggest a way to model the database relationships for 
Kareem?

thanks,

Joe

On Thu, Nov 07, 2002 at 09:08:20AM -0500, Kareem Lawrence wrote:
> Joe,
> 
> Since you can't recommend a product like ERwin that will allow me to view
> the database schema. Can you recommend a method by which I can determine the
> relationships between the tables in the database? This would be very useful
> to me for any additions I may want or need to make. Using this as a teaching
> tool for myself. Do you think you could help?
> 
> Kareem
> 
> -----Original Message-----
> From: Joe Stewart [mailto:jo...@be...]On Behalf Of Joe Stewart
> Sent: Tuesday, November 05, 2002 12:24 PM
> To: Kareem Lawrence
> Subject: Re: [phpslash-users] Hello -- I could use some help
> 
> 
> On Mon, Nov 04, 2002 at 12:30:44PM -0500, Kareem Lawrence wrote:
> > Joe,
> >
> snip!
> 
> > One very important thing that PHPSlash has
> > over it is the ability to associate a single story to multiple areas of a
> > web site. If brief overview of underlying db of PHPSlash it would seem
> that
> > what it's missing is a collections table that aggregates the associations.
> 
> I may be misunderstanding but...
> 
> While integrity is maintained for the associations, I don't think all
> pageviews use the same associations.
> 
> > What would be really useful to me is to get a data modeling product like
> > ERwin to view these relationships more clearly so that I don't have to
> rely
> > on my (usually faulty) suppositions. Can you recommend something?
> >
> 
> Sorry. no.
> 
> later,
> 
> Joe
> 
> > Kareem
> >

Re: [Phplib-users] Current PHPLIB development questions

[Joe S. <jo...@cm...>]

On Thu, Nov 07, 2002 at 10:11:26AM +0100, Giancarlo wrote:
> I I'm 100% in agreement with Richard.
> >
> > It might make more sense to use the current "not stable" tree as a
> > source for ideas, as Richard suggested, rather than try to actually
> > merge everything or even most of what is in it into the stable version.
> > I think that would be a very large and risky undertaking.
> 
> The dev snapshot has two new things: php4 session support & an auth redesign.
> 
> Php4 session support is quite stable and working by itself in the snapshot. 
> It can be merged easily, it won't interfere with preexisting stuff. It really 
> works. And is implemented much more simply than in the various previous 
> 'unsup' branches.

PHP4 session support is in the -stable cvs.  There is no difference in 
this portion of the code from cvs to the dev snapshot.

> The new auth can be more tricky to distribute, and is based on some vital 
> bugs found along  the way. These bugs have been backfixed into the cvs 
> though. 

No. no changes have been made to the auth in cvs.  So the bugs and missing 
features remain.

> But as of now I do not necessarily see a problem in using it as a 
> dropin replacement: it will work mostly everywhere, especially if the app 
> sticked to the API, and didn't use to call directly functions as 
> $auth->start() or $sess->freeze() or similar functions that were supposed not 
> to be used but to be called by phplib. The cancel_login is the only thing not 
> supported, it simply has no effect.
> 

Pretty much true, especially when not using default auth.  

The auth_validatelogin and do_register need to reject quickly if there are no
 POST variables.

Joe

> Gian
> 
> 

Re: [Phplib-users] sending the url of a protected page

[Joe S. <jo...@be...>]

On Thu, Nov 07, 2002 at 06:40:33PM +1100, Richard Archer wrote:
> Hi,
> 
> I'm having a brain-block here... must be the heat.
> 
> I want to send via email a URL like:
> https://www.example.com/blah.php?id=123
> 
> The blah.php script requires admin permissions.
> 
> I want it to put up the interstitial login screen then show the
> results of the "id=123" query.
> 

Already a feature request:

[ 608452 ] auth.inc - GET and POST variables
http://sourceforge.net/tracker/index.php?func=detail&aid=608452&group_id=31885&atid=403614


> I can't work out how to do this, but I'm sure it must be possible!
> How??
> 

One way to do this now is:

1.  Save the GET variables to a session variable in auth_loginform().

2.  restore the GET variable from the session variable and clear it after 
validation in auth_validatelogin().

This will do exactly as needed.

Joe

>  ...Richard.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

[Phplib-users] a doc on sessionID security

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

This is an interesting piece of paper. 
PHP4 session implementation won't pass any minimum requirement

http://www.idefense.com/idpapers/SessionIDs.pdf

Gian

Re: [Phplib-users] Current PHPLIB development questions

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

> though. But as of now I do not necessarily see a problem in using it as a
> dropin replacement: it will work mostly everywhere, especially if the app
> sticked to the API, and didn't use to call directly functions as
> $auth->start() or $sess->freeze() or similar functions that were supposed
> not to be used but to be called by phplib. The cancel_login is the only
> thing not supported, it simply has no effect.

In fact there used to be a few 'unsupported patches' around that used some 
workaround to get a 'login form' anywhere etc.
One of these used to set $auth->auth[uid]='form' so that it could call 
$auth->start anytime.
This is a typical example of something that would not work with the new auth, 
because the problem has been solved bothh by finding a bug and by eliminating 
 the 'unique entrance point' of the auth->auth[uid]=='form' state, that would 
block session everywhere and needed the cancel_login.

There are other 'usupported patches', that BTW never made their way into the 
official distrib, that would not work with the new auth. But all in all (ask 
those who looked at it), once you just read the new code and compare it with 
the old one, you understand that you don't want to go backwards anymore...

Gian

RE: [Phplib-users] Re: latest snapshot (fwd)

[Marko K. <M.K...@os...>]

Looks like previous post got lost. otherwise ignore this. ;)

> start session
> if ($_COOKIE['sesscheck'] != $_SESSION['sesscheck'] {
> 	//bomb out because we are being hijacked.
> }
> $sesscheck = md5(uniqid(rand(),1));
> set_cookie($sesscheck)
> $sess->register('sesscheck');
>
> This would have a similar effect to changing the session id every time!!!!
Looks nice!
But what happens if you're working with frames?!?
Up to now it's possible to work with frames, though it's not very handy.
You just use page_close() in only one frame. But with this scheme you
could will run into severe problems, since at the end of the page the
session wouldn't become saved, although the cookie would be saved already.
Perhaps it would be wiser to issue the set_cookie only in page_close!

Marko

Re: [Phplib-users] Current PHPLIB development questions

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

I I'm 100% in agreement with Richard.
>
> It might make more sense to use the current "not stable" tree as a
> source for ideas, as Richard suggested, rather than try to actually
> merge everything or even most of what is in it into the stable version.
> I think that would be a very large and risky undertaking.

The dev snapshot has two new things: php4 session support & an auth redesign.

Php4 session support is quite stable and working by itself in the snapshot. 
It can be merged easily, it won't interfere with preexisting stuff. It really 
works. And is implemented much more simply than in the various previous 
'unsup' branches.
The new auth can be more tricky to distribute, and is based on some vital 
bugs found along  the way. These bugs have been backfixed into the cvs 
though. But as of now I do not necessarily see a problem in using it as a 
dropin replacement: it will work mostly everywhere, especially if the app 
sticked to the API, and didn't use to call directly functions as 
$auth->start() or $sess->freeze() or similar functions that were supposed not 
to be used but to be called by phplib. The cancel_login is the only thing not 
supported, it simply has no effect.

Gian

Re: [Phplib-users] Re: latest snapshot

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

> The only drawback I can see of GET strings is that perhaps the Session
> ID can be obtained by reading the target's screen (i.e. with a
> telescope through a window, with a hidden camera etc). I see this as


This is true if we don't take into consideration the fact that any, 
user-fantasy id can be provided by proposing a link with the sid in it. And 
it will be created.
Where is the randomicity and 'non-guessability' if anyone (cookie free) can 
impose on anyone else his known sid as ?Example=Session=1

There are books and treaties about random cookie/token creation. Human 
fantasy is not an enough valid device for generating random tokens!
This is not Posix/MIT/cookie/whatever compliant. This is an illogic bestiality


Gian

Re: [Phplib-users] Re: latest snapshot

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

> What about incrementing a separate random that gets changed in pageopen.
> Call it sesscheck
>
> start session
> if ($_COOKIE['sesscheck'] != $_SESSION['sesscheck'] {
> 	//bomb out because we are being hijacked.
> }
> $sesscheck = md5(uniqid(rand(),1));
> set_cookie($sesscheck)
> $sess->register('sesscheck');

If we could know the moment whenn our session is a fresh new one, we could 
save the mode (get/cookie), and block that client from changing his mode 
along the way. Every passage/steal of cookie/GET supposes changing its mode 
along the way. 
If we trust cookies is because they are not allowed be passed. If a client 
chances propagation we can be almost sure that the client itself has changed, 
or it means that someone has enabled/disabled his cookies midway, which 
should equate a change in client.
We should be able to decide where and when accept these alien sids. In some 
cases they are useful though, but allowing them anywhere is not safe.

Gian

RE: [Phplib-users] Re: latest snapshot

[Marko K. <M.K...@os...>]

> start session
> if ($_COOKIE['sesscheck'] != $_SESSION['sesscheck'] {
> 	//bomb out because we are being hijacked.
> }
> $sesscheck = md5(uniqid(rand(),1));
> set_cookie($sesscheck)
> $sess->register('sesscheck');
>
> This would have a similar effect to changing the session id every time!!!!
Looks nice!
But what happens if you're working with frames?!?
Up to now it's possible to work with frames, though it's not very handy.
You just use page_close() in only one frame. But with this scheme you
could will run into severe problems, since at the end of the page the
session wouldn't become saved, although the cookie would be saved already.
Perhaps it would be wiser to issue the set_cookie only in page_close!

Marko

Re: [Phplib-users] Re: latest snapshot

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

Il 05:44, gioved=EC 7 novembre 2002, Richard Archer ha scritto:
> At 23:29 -0500 6/11/02, Rob Hutton wrote:
> >Interesting idea about changing the session ID.=20

Yes, because if anyone did know, or suggest us, a known session id to ent=
er=20
an unauthed session, once we are authed that sid is discarded, so the=20
'knowing suggestor' cannot folow us there.

And when we reissue the session, this would be the right moment for chang=
ing=20
the session type if we want, let's say from a file mudule, to a custom=20
db_module, so once logged in our session sits more secure into the db.
This would be a good compromise bethween speed and open access (everyone =
can=20
use the session features, even with cookies disabled, full speed because =
php4=20
native),, nad once logged in things get more tight, at a slight performan=
ce=20
cost, but maximum safety=20

[Phplib-users] sending the url of a protected page

[Richard A. <rh...@ju...>]

Hi,

I'm having a brain-block here... must be the heat.

I want to send via email a URL like:
https://www.example.com/blah.php?id=123

The blah.php script requires admin permissions.

I want it to put up the interstitial login screen then show the
results of the "id=123" query.

I can't work out how to do this, but I'm sure it must be possible!
How??

 ...Richard.

RE: [Phplib-users] Re: latest snapshot

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

> I would not expect any significant additional overhead on the server.
> You just need to generate a new session ID and change the database
> query which stores the session so that it updates the session ID when
> it stores the session variables. I wouldn't think there'd be more than
> about 10 lines of extra code in PHPLIB. Might be an interesting option
> to add sometime... have to make it optional via a local.inc switch!
>

Not with PHP4 sessions.  PHP itself controls the session ID.

>
> First time I've heard that... I would have thought cracking SSL
> connections in anything resembling real time without military-grade
> hardware would be big news. Got any pointers to how that's done?

There is a fairly easy MITM attack of up to version 2, which there is a lot
of still out there (anyone heard of IIS?).  I will try to drag out my docs,
I can't lay quick hands on them and it is time for a couple of hours of
rest.  Basically there was a weakness in the key exchange protocol that
allowed you to insert yourself into the stream anytime is you had recorded
the initial handshake.

>
>
> Except you don't get told what the cookie lifetime is. All you get back
> from the browser is the cookie name and value.

Right.  Guess that is a problem.

What about incrementing a separate random that gets changed in pageopen.
Call it sesscheck

start session
if ($_COOKIE['sesscheck'] != $_SESSION['sesscheck'] {
	//bomb out because we are being hijacked.
}
$sesscheck = md5(uniqid(rand(),1));
set_cookie($sesscheck)
$sess->register('sesscheck');

This would have a similar effect to changing the session id every time!!!!

>
>  ...R.
>
>

RE: [Phplib-users] Re: latest snapshot

[Richard A. <rh...@ju...>]

At 23:29 -0500 6/11/02, Rob Hutton wrote:

>Interesting idea about changing the session ID.  I don't see any kind of
>session_replicate and if you change the id manually, you loose everything.
>I would think this could get to be a serious amount of overhead on the
>server, too.

I would not expect any significant additional overhead on the server.
You just need to generate a new session ID and change the database
query which stores the session so that it updates the session ID when
it stores the session variables. I wouldn't think there'd be more than
about 10 lines of extra code in PHPLIB. Might be an interesting option
to add sometime... have to make it optional via a local.inc switch!


>Someone in the manual suggested storing the IP of the remote machine in the
>session and refusing to start it if the session request comes from somewhere

Yeah, well that's a bogus suggestion because you'll break things for
so many people your site will become useless.


>> Yup. If you want even a veneer of security, run the session over SSL.
>
>Except SSL isn't that hard to crack ;-)

First time I've heard that... I would have thought cracking SSL
connections in anything resembling real time without military-grade
hardware would be big news. Got any pointers to how that's done?


>> No need to insert a session cookie into the browser's runtime state.
>> Quit the browser, add a permanent cookie to your cookie jar with a text
>> editor, start the browser, load the URL. There is no inherent
>> difference between a permanent cookie and a session cookie except that
>> the browser caches them differently.
>
>So the cookie lifetime should be checked to make sure it is 0.  Will add to
>my mods to auth.

Except you don't get told what the cookie lifetime is. All you get back
from the browser is the cookie name and value.

 ...R.

RE: [Phplib-users] Re: latest snapshot

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

Interesting idea about changing the session ID.  I don't see any kind of
session_replicate and if you change the id manually, you loose everything.
I would think this could get to be a serious amount of overhead on the
server, too.  Anyway, here is the relevant paragraph from the PHP manual:

***
Sessions rely on the session ID, meaning one can 'steal' a session, by
stealing the session ID. This can be made harder, by using a cookie
specifically a session cookie, but does not in any way make it impossible
and still relies on the user closing all browser windows, to expire the
session cookie. Besides that, even session cookies can be sniffed on a
network or logged by a proxyserver.
***

So, the trick is some end user responsibility (close all windows) across SSL
and strong session IDs.  Maybe a disclaimer should be added.  Also, should
the length of the session ID be extended?

Someone in the manual suggested storing the IP of the remote machine in the
session and refusing to start it if the session request comes from somewhere
else.  Problem is, inconsistent browser support, implementation, and proxy
server farms.  Maybe in "SUPER DUPER SECURITY MODE".

Other responses in line.

>
> Might be. Or you might be able to run a memory search tool, search for
> the cookie name and see the value right next to it. Finding the cookie
> name is trivial... just load the site on another computer with "prompt"
> for cookies and it'll tell you.

But this requires physical access.  It would be easier in most environments
to do it across the net.  Plus, it's the old rule of turn you screen saver
on with a password so that someone does not come up to your machine and use
it while you are not there.  This is a physical security issue.

>
>
> Yup. If you want even a veneer of security, run the session over SSL.

Except SSL isn't that hard to crack ;-)

>
>
> No need to insert a session cookie into the browser's runtime state.
> Quit the browser, add a permanent cookie to your cookie jar with a text
> editor, start the browser, load the URL. There is no inherent
> difference between a permanent cookie and a session cookie except that
> the browser caches them differently.

So the cookie lifetime should be checked to make sure it is 0.  Will add to
my mods to auth.

>
>
> The only drawback I can see of GET strings is that perhaps the Session
> ID can be obtained by reading the target's screen (i.e. with a
> telescope through a window, with a hidden camera etc). I see this as
> only a minimal drawback over the cookie approach, and if session
> hijacking is of concern, cookies are IMHO not an adequate security
> mechanism in themselves.

Or the age old shoulder surfer.  That's how a lot of passwords are
compromised to this day.  If it is on the screen, someone can walk up behind
the user and see it, write it down, etc.  Most stuff like this is much more
intimate than a telescope.  You'd be surprised how many "high" security
areas that I have gotten into during physical audits by pushing around a 50
gallon trash can on wheels with some cleaning supplies on the outside.  I
had someone let me in to a Level 3 (top) security government contractor by
telling them I was new and had not gotten a badge yet.

RE: [Phplib-users] Re: latest snapshot

[Richard A. <rh...@ju...>]

At 22:07 -0500 6/11/02, Rob Hutton wrote:

>  Not quite that simple.  Session cookies are never written to the hard
>drive and are not viewable from the cookie window.  The only way I can think
>of looking at them is by running the browser in a VM debugger and looking at
>the trace.  Even then I am not sure that you could find it because it might
>be scattered in the stack.

Might be. Or you might be able to run a memory search tool, search for
the cookie name and see the value right next to it. Finding the cookie
name is trivial... just load the site on another computer with "prompt"
for cookies and it'll tell you.


>  It would be much easier to sit between the server and web site to do
>something, which is where https comes in.

Yup. If you want even a veneer of security, run the session over SSL.


>  Also, I asked a couple of questions on the Mozilla list, and to their
>knowledge, you would have to write some code to insert a session cookie into
>memory or attack the server directly without a browser (like with curl).

No need to insert a session cookie into the browser's runtime state.
Quit the browser, add a permanent cookie to your cookie jar with a text
editor, start the browser, load the URL. There is no inherent
difference between a permanent cookie and a session cookie except that
the browser caches them differently.


>Either way is more trouble that simply entering a [session] id as a
>get variable, and is the safest way I see of doing it.

Yes, but if you have an attacker willing to try the non-trivial task of
session hijacking, presumably they have a reason driving them to do so.
In which case making it just a little harder might be giving yourself
and the user a false sense of security.

The only drawback I can see of GET strings is that perhaps the Session
ID can be obtained by reading the target's screen (i.e. with a
telescope through a window, with a hidden camera etc). I see this as
only a minimal drawback over the cookie approach, and if session
hijacking is of concern, cookies are IMHO not an adequate security
mechanism in themselves.

Perhaps changing the session ID on each page view would be a better
approach. Wouldn't be too hard to implement either, I expect.

 ...R.

RE: [Phplib-users] Re: latest snapshot

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

Sorry, entering a session ID as a get variable, not uid.  I'm getting ahead
of myself!!!

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Rob Hutton
> Sent: Wednesday, November 06, 2002 10:07 PM
> To: Richard Archer; php...@li...
> Subject: RE: [Phplib-users] Re: latest snapshot
>
>
>   Not quite that simple.  Session cookies are never written to the hard
> drive and are not viewable from the cookie window.  The only way
> I can think
> of looking at them is by running the browser in a VM debugger and
> looking at
> the trace.  Even then I am not sure that you could find it
> because it might
> be scattered in the stack.
>   It would be much easier to sit between the server and web site to do
> something, which is where https comes in.
>   Also, I asked a couple of questions on the Mozilla list, and to their
> knowledge, you would have to write some code to insert a session
> cookie into
> memory or attack the server directly without a browser (like with curl).
> Either way is more trouble that simply entering a uid as a get
> variable, and
> is the safest way I see of doing it.
>
> Thanks,
> Rob Hutton
> Web Safe
> www.wsafe.com
>
> > -----Original Message-----
> > From: php...@li...
> > [mailto:php...@li...]On Behalf Of Richard
> > Archer
> > Sent: Wednesday, November 06, 2002 5:33 PM
> > To: php...@li...
> > Subject: RE: [Phplib-users] Re: latest snapshot
> >
> >
> > At 16:19 -0500 6/11/02, Rob Hutton wrote:
> >
> > >  If you allow the session ID to be passed in as a string, then
> > someone can
> > >hijack a session by simply passing the session ID in the get string.  A
> > >cookie is much harder to insert, and since they are session
> cookies, they
> > >can't easily be viewed or replicated...
> >
> > OK. It is trivial to insert a cookie once you know the values. You
> > can edit your cookie file with a text editor or use curl to pass in
> > the cookie on the command line.
> >
> > So, session ID discovery is really the key here.
> >
> > If physical access is available, concealing the session ID is
> > meaningless because the perp can sit at that machine and continue
> > the existing session just as easily as they could copy down the
> > session ID from screen or run a memory scanning utility to find it.
> >
> > Without physical access to the user's machine, session hijacking
> > requires sniffing the traffic to determine the session ID... in
> > which case the GET string and the cookie would both be displayed
> > as plain as day.
> >
> > However I would assume that if security is any sort of an issue
> > then the session would be running over SSL in which case it is not
> > a trivial matter to obtain either the GET string or the cookie and
> > in this case I can't see why one should be preferred over another.
> >
> > But I must admit I've never studied this area in great depth.
> >
> >  ...Richard.
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: See the NEW Palm
> > Tungsten T handheld. Power & Color in a compact size!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> > _______________________________________________
> > Phplib-users mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phplib-users
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

RE: [Phplib-users] Re: latest snapshot

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

  Not quite that simple.  Session cookies are never written to the hard
drive and are not viewable from the cookie window.  The only way I can think
of looking at them is by running the browser in a VM debugger and looking at
the trace.  Even then I am not sure that you could find it because it might
be scattered in the stack.
  It would be much easier to sit between the server and web site to do
something, which is where https comes in.
  Also, I asked a couple of questions on the Mozilla list, and to their
knowledge, you would have to write some code to insert a session cookie into
memory or attack the server directly without a browser (like with curl).
Either way is more trouble that simply entering a uid as a get variable, and
is the safest way I see of doing it.

Thanks,
Rob Hutton
Web Safe
www.wsafe.com

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Richard
> Archer
> Sent: Wednesday, November 06, 2002 5:33 PM
> To: php...@li...
> Subject: RE: [Phplib-users] Re: latest snapshot
>
>
> At 16:19 -0500 6/11/02, Rob Hutton wrote:
>
> >  If you allow the session ID to be passed in as a string, then
> someone can
> >hijack a session by simply passing the session ID in the get string.  A
> >cookie is much harder to insert, and since they are session cookies, they
> >can't easily be viewed or replicated...
>
> OK. It is trivial to insert a cookie once you know the values. You
> can edit your cookie file with a text editor or use curl to pass in
> the cookie on the command line.
>
> So, session ID discovery is really the key here.
>
> If physical access is available, concealing the session ID is
> meaningless because the perp can sit at that machine and continue
> the existing session just as easily as they could copy down the
> session ID from screen or run a memory scanning utility to find it.
>
> Without physical access to the user's machine, session hijacking
> requires sniffing the traffic to determine the session ID... in
> which case the GET string and the cookie would both be displayed
> as plain as day.
>
> However I would assume that if security is any sort of an issue
> then the session would be running over SSL in which case it is not
> a trivial matter to obtain either the GET string or the cookie and
> in this case I can't see why one should be preferred over another.
>
> But I must admit I've never studied this area in great depth.
>
>  ...Richard.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

Re: [Phplib-users] Current PHPLIB development questions

[Chris J. <ch...@ch...>]

On Wed, Nov 06, 2002 at 01:46:20PM +1100, Richard Archer wrote:

> My preference would be for:
> 
> complete back-compatibility with existing applications
> good documentation for the changes outlining possible breakages
> not throwing warnings with all error/warning messages enabled
> compatible with the new PHP defaults wrt globals etc (done?)
> a switch in local.inc to choose phplib-session or session-4
> examples of session-4 classes in local.inc and the html dir
> 
> The main thing I would stress is that this release should not change
> the PHPLIB API in any non-compatible way. API changes may occur in the
> 8.0 release, but should not happen in an incremental release.
> 
> The only area where this may not be possible is in the session-4 stuff,
> but this is OK as long as the old phplib-sessions are still intact and
> back-compatible. Switching on session-4 for an existing app would be
> something the developer would do in a test environment (one hopes!).


> There is a devel tree (it's the one that's not stable :). Unfortunately
> this code is quite broken. It is really only useful as a resource for
> ideas (like the session-4 stuff). I would be hesitant to over-write
> this tree with a new suite of changes at this point.
> 
> I would like to see the rest of the good stuff merged from the "phplib"
> tree into the stable tree, and the old "phplib" tree deleted (or
> archived, whatever).
> 
> I think it would be quite a good idea to create a new branch for
> development work. I would like to see it called "unstable" and to
> include a file warning against inclusion of this tree for any
> packaged release of PHPLIB. This would be an attempt at preventing
> a repeat of the inclusion of the broken tree in several OS releases.
> 
>  ...R.

My thoughts exactly!  (Well, actually much more clearly stated than my
thoughts.)

I'm 100% in agreement with Richard.

It might make more sense to use the current "not stable" tree as a
source for ideas, as Richard suggested, rather than try to actually
merge everything or even most of what is in it into the stable version.
I think that would be a very large and risky undertaking.

-- 
    ..chris

Re: [Phplib-users] Re: latest snapshot

[Richard A. <rh...@ju...>]

At 22:41 +0100 6/11/02, Giancarlo wrote:

>the requested url  passes in cleartext, even with SSL, while msg headers
>(cookies) and bodies are encrypted.

No, that's not right. An SSL connection between a browser and a server
is completely encrypted, end-to-end. Even when the request runs through
a proxy server, the proxy cannot decrypt the traffic and does not have
access to the URL.

 ...Richard.

RE: [Phplib-users] Re: latest snapshot

[Richard A. <rh...@ju...>]

At 16:19 -0500 6/11/02, Rob Hutton wrote:

>  If you allow the session ID to be passed in as a string, then someone can
>hijack a session by simply passing the session ID in the get string.  A
>cookie is much harder to insert, and since they are session cookies, they
>can't easily be viewed or replicated...

OK. It is trivial to insert a cookie once you know the values. You
can edit your cookie file with a text editor or use curl to pass in
the cookie on the command line.

So, session ID discovery is really the key here.

If physical access is available, concealing the session ID is
meaningless because the perp can sit at that machine and continue
the existing session just as easily as they could copy down the
session ID from screen or run a memory scanning utility to find it.

Without physical access to the user's machine, session hijacking
requires sniffing the traffic to determine the session ID... in
which case the GET string and the cookie would both be displayed
as plain as day.

However I would assume that if security is any sort of an issue
then the session would be running over SSL in which case it is not
a trivial matter to obtain either the GET string or the cookie and
in this case I can't see why one should be preferred over another.

But I must admit I've never studied this area in great depth.

 ...Richard.