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

[Phplib-users] How can I preserve an anchor in the URL when I link to a PHPlib protected page

[Robert V. O. <van...@un...>]

Hello,

I have a PHPlib protected page and want to link to an anchor within it (a
href="Members.html#1"), but when PHPlib appends the session ID to the URL,
the anchor gets stripped off
(Members.html?UDSession=f22c81498c75ebeea7ad6115c84ffb21).

How can I preserve the anchor in the URL when I link to a PHPlib protected
page (a href="Members.html#1?UDSession=f22c81498c75ebeea7ad6115c84ffb21")?

Thanks,
Bob V

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

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

It would be interesting to note how by_necessity_aware sites, eg: 
easydns, have solved the problem. I remember the guy was on this list in 
the early times.

Gian

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

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

> -----Original Message-----
> From: Giancarlo [mailto:gia...@na...]
> Sent: Monday, December 09, 2002 5:05 PM
> To: rob...@ws...
> Subject: Re: [Phplib-users] store the IP in the session
>
>
> >
> > But where does the url come from.  You were talking about clicking on a
> > dangerous url which would steal the session id and send it somewhere.
>
> Didn't we aknowledge that a cookie-less, cookie-enabled client, by
> clicking on a link as
> https://www.xxx.yyy/?PHPSESSID=foo
> will: a) get no cookie b)create a session 'foo' on the server, and a
> file /tmp/sess_foo c) have trans_sid append ?PHPSESSID=foo to all th
> elinks in the page d) expire at gc time, but be recreated again anytime
> by clicking on the same link? And thus be a spoofable link 'ad aeternum'?
> The cases when we have a GET sid, but no referer can be:
> someone has copied on of URLs while @us, and added it to a message or a
> web page or his bookmarks. In all cases either we have no referer, or
> refere is out of our domain. We don't want to say anything, but silently
> discard our SID and redirect him to the clean URL.

  If you are not running phplib, yes.  If you are, no.  In phplib, if the
session doesn't exist, it does not automagicly create it.  I'm not sure
about php4 itself, I will look into that, but how php4 behaves does not
dictate how phplib behaves.  If the session does not exist, then the
page_open should fail.
  But if it doesn't exist, who cares if we create one.  It's empty?  Best
practices should certainly be that we don't allow things to be forces, I
agree totally.

>
>  > Which
> > is a CSX and would require scripting.
>
> Scripting is required to modify a page's link to increase that
> user-definable SID. Dunno if this would stay right iside the url string
> (so that can be parsed out), or may stay elsewhere in the page. Dunno
> much JS.
>
>
> > But as previously discussed, this is not effective in a connectionless
> > environment where the time between connection may easily be in
> the order of
> > 10 to 15 minutes.  It would be easy for someone to hijack the session in
> > that time.
>
> I will explain that two-part URL better. it is composed of two half, as
> ?MySess=111111/aaaaaa
> The 111111 is just our unpredictable md5 as before, and is the key of
> the session record. The 'aaaaaa' part is never the same. Every link is
> made different from the previous, the aaaaaa is taken from a list of
> pregenerated ones. Each time is taken one, is marked as taken. Everytime
> is used one, is marked as used. New ones are taken from those not yet
> taken nor used. One can be taken-and used on the fly, so it does not
> need to be 'taken' to become 'used'.
>
> Suppose that the random pregenerated list is:
> aaaaaa
> bbbbbb
> cccccc
> dddddd
>
> ;-)
>
> So in a page your links look like:
>
> page1.php?Mysess=111111/aaaaaa
>
> page2.php?MySess=111111/bbbbbb
>
> Page3.php?MySess=111111/cccccc
>
> and so on.
>
> To avoid locks, the pregenerated keys can be stored in a dedicate table,
> with the name and id as keys as in active_sessions.
> A page can also 'preask' an fair enough amount of keys for it's use,
> mark them all 'taken', and free the unused ones before end,, to
> quickify... There can be an asyncronous job that refills the fresh keys
> when nearly ended, or use triggers.
>
> In practice only those present can know the links. And each is clickable
> only once. The only way I can think this can be spoofed is when sent by
> the person itself. The browser back can work if the cache settings are
> correct.
>
>
> > There also has to be a reuse window because multiple frames may
> > be changed at the same time using the same ID.
>
> Each id is different
>
> Anyway this is just fantasy.  It seems you are among the few that seem
> concerned about the things I mentioned.  I like the things you proposed
> for session, I wonder how much are they possible with php4 propagation,
> which is little hackable. Sure having a phased C routine do anything is
> a lot faster, but this can be THE sensitive part of it all.
> I think we should keep the PHP4 propagation (cookie/get) module as a
> whole choice, and define a separate phplib 'propagation' module. In th
> eand we have an auth to care about, php4 hasn't. This would repeche
> pieces of the sessio class, as Maxim has started doing already,
> otherwise there is no 'custom_propagation functions' for coding this in
> PHP4.

You can control the php4 Session ID though and override the php4 behavior.

>
>
> Gian
>
>

Re: [Phplib-users] Proposed changes to session

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

Rob Hutton wrote:
> 1) allow_auto_mode_change = boolean :  If set to True, this allows the mode
> to change based on the method that the session ID was submitted.  The order
> of checking would be cookie, get, post.  If set to false, the session would
> return an error if the method did not match the previous mode or multiple
> modes were set.  Either setting would return an error if the method was not
> in the supported_modes array.
> 
> 2) sess( supported_modes = array()) :  supported_modes specifies the list of
> modes supported by this session type.  This would replace the mode and
> fallback_mode variables.
> 
> 3) sess->transform(session_class = class) :  Transform the current session
> variable into type session_class.  This would allow the session variables to
> be moved to type session_class in case you need one class to handle "public"
> areas and one to handle "private" areas for example with more securty.
> 


Sound. I agree on all these. In practice, as I noted in default_auth, we 
are moving characteristics from the page to the user. Things like that 
session_timeout is better determibed on a per user base rather than 
per-page. The same with session now. This recognise that it really 
depends on who you are, doing what, when. Great!

Gian

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

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

>
>
>   > This is a cross site scripting vulnerability inherent to the way HTTP
> works.
>
> There is no scripting involved here, it is a plain url.
>

But where does the url come from.  You were talking about clicking on a
dangerous url which would steal the session id and send it somewhere.  Which
is a CSX and would require scripting.

>   > There is nothing we can do to prevent this.  If someone allows HTTP
> entry on
>   > their site,
>
> You can prevent scripting by parsing quotes etc, because they are not
> allowed inside links.  If a link is a danger, any wiki or annotation
> becomes a danger. Credentials in the url, if treated, should be sorta
> quaranteened or screened, and not alloweb do mixmax. That's way I
> propose 'unrepeatable' use-once sequences, made of a fixed part and a
> secretly preagreed rest. Dunno if amazon does so ;-)

But as previously discussed, this is not effective in a connectionless
environment where the time between connection may easily be in the order of
10 to 15 minutes.  It would be easy for someone to hijack the session in
that time.  There also has to be a reuse window because multiple frames may
be changed at the same time using the same ID.  If the reuse time is say, 30
seconds, then someone else has 30 seconds to insert themselves into the
session without the other person ever knowing it.  Again, this is a false
layer of security.

>
>   > then that is the risk they take.  This could easily enough occur
>   > with another security breach and a page replacement.  This is an
> application
>   > question.
>   >
>   > Referer is not set in the case of Javascript navigation, page refresh,
>   > typeing in a direct url, etc. etc. etc.
>

Because there are MANY sites that use Javascript navigation.

> Ok, so why should I accept a GET sid  without a referer?
>
>
>   >>it intervenes only when there is a referer. But we can block
> when there
>   >>is no referer
>
>   > Yes, so use SSL.   Problem solved.
>
> Again you forget links :
>
> https://aaa.com/?PHPSESSID=foo

No I didn't.  If you are clicking on a link like this, then it has been
generated using a CSX vulnerability.  If you are receving a link like this,
then the best that you can do at this point is store the last mode that the
session was running in and not accept get if mode change protection is
turned on.  Maybe a sticky flag like you said.

>
>
>   > Here is an example:
>   >
>   > XYZ has written an app that does not do input filtering and someone
> enters
>
>
>   > javascript to read the session cookie and send it to them.
> They get it,
>   > creat the cookie, and now they can hijack the session.  No matter how
> much
>   > code is written, without some method of identifying the remote user,
> either
>   > through a certificate or something.
>
> That hasn't taken off in so many years now...

Then what are you trying to prevent?

>
>
>   > You are trying to solve a problem that has plagued tcp for years.
> If you
>   > open a session, and someone guesses the sequence number,
>
> anyone can tell to use 'foo', with php4 session!

Which is another reason that I argued against the movement toward just
native PHP4 sessions.  The phplib wrapper prevents this by default if you
are running in cookie mode and doing things correctly.

>
>   > then they can
>   > hijack the session.
>
> #281
> Gian
>
>
>
>


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

[Phplib-users] Proposed changes to session

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

1) allow_auto_mode_change = boolean :  If set to True, this allows the mode
to change based on the method that the session ID was submitted.  The order
of checking would be cookie, get, post.  If set to false, the session would
return an error if the method did not match the previous mode or multiple
modes were set.  Either setting would return an error if the method was not
in the supported_modes array.

2) sess( supported_modes = array()) :  supported_modes specifies the list of
modes supported by this session type.  This would replace the mode and
fallback_mode variables.

3) sess->transform(session_class = class) :  Transform the current session
variable into type session_class.  This would allow the session variables to
be moved to type session_class in case you need one class to handle "public"
areas and one to handle "private" areas for example with more securty.



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

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

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

 >>>$fallback_mode) because this would allow new modes to be added and a
 >>>preference list built ($mode = array("cert", "cookie")) where cert is

 >>Ok, then in that case you'd certainly want to be able to apply 'cert'
 >>only froim a certain moment on, so be able to migrate your session and
 >>user data from the previous type of session into this new one. And not
 >>impose one choise at the start.
 >>And you'd never let a 'cert' session to downgrade to 'cookie' while
 >>maintaining the same privileges. OTH.

It's somehow also the programmer responsib to see that mode is not 
downgraded. You know, the annoying messages when entering/leaving secure 
mode.

> Correct, with a major exception.  There is no reason why a session could not
> be transformed from one mode to another.  The mode would just have to be
> stored in auth.  Then a page_open would know how to restore the session
> and a function such as auth->change_mode would make the change.  


This the change_mode has to be done while restoring the session, which 
happens before any auth exists. So auth has to be able to call a 
function that saves the session data, create a new one of the type 
wanted, restore the data. There's a patch from me that already does this 
for session3, while I committed the $block_alien_sids  check to 
session.inc in the php-lib-stable cvs. With php4 I couldn't find a way 
to do this using php4 session functions. Nor it seems Maxim did, as he 
reinserted the known 'Header: 302 Moved there' or similar.

Better if the session has a new sid here, as it acquires a higer grade.

Going back to lower-level cookie/get, things are not much different.
I see in Maxim's that session_start can be executed twice. I wonder what 
happens if session.use_only_cookies is set between the two.



The list simply
> specifies the ones you want to allow, and auth would pick the most secure
> that works.  If you want to force a mode change, then no problem as long as
> it is one of the ones that you support.

Re: [Phplib-users] Web Server Requeriments (please)

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

On Sat, Dec 07, 2002 at 02:01:15PM +0100, Virilo Tejedor Aguilera wrote:
> I've never use a web server different to my Apache for win32.
> 
> Now i need to pay for a web hosting service (perhaps www.amen-es.com).
> 
> How know if its able to run phplib.  Its enough having php4?
> 
> Whats the matter with include files?  I could change php.ini? Its absolutely necessary?
> 
> Thanks.

If a web hosting service supports PHP4, you should be able to run PHPLIB.

However, it will be easier to run PHPLIB if the web hosting service
allows one to have some overrides in their directories, for example, the
".htaccess" files supported by Apache and other web servers.  Then one
can set a number of useful values there.

One does not have to modify the "php.ini" file to use PHPLIB.  Instead,
one can include or require the prepend.inc file in each page that
needs it.  Using the auto_prepend_file feature of the "php.ini" file is
convenient to make sure that prepend.inc always gets prepended (included
at the start of the page), but it is not required.

-- 
    ..chris

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

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

  > This is a cross site scripting vulnerability inherent to the way HTTP
works.

There is no scripting involved here, it is a plain url.

  > There is nothing we can do to prevent this.  If someone allows HTTP
entry on
  > their site,

You can prevent scripting by parsing quotes etc, because they are not
allowed inside links.  If a link is a danger, any wiki or annotation
becomes a danger. Credentials in the url, if treated, should be sorta 
quaranteened or screened, and not alloweb do mixmax. That's way I 
propose 'unrepeatable' use-once sequences, made of a fixed part and a 
secretly preagreed rest. Dunno if amazon does so ;-)

  > then that is the risk they take.  This could easily enough occur
  > with another security breach and a page replacement.  This is an
application
  > question.
  >
  > Referer is not set in the case of Javascript navigation, page refresh,
  > typeing in a direct url, etc. etc. etc.

Ok, so why should I accept a GET sid  without a referer?


  >>it intervenes only when there is a referer. But we can block when there
  >>is no referer

  > Yes, so use SSL.   Problem solved.

Again you forget links :

https://aaa.com/?PHPSESSID=foo


  > Here is an example:
  >
  > XYZ has written an app that does not do input filtering and someone
enters


  > javascript to read the session cookie and send it to them.  They get it,
  > creat the cookie, and now they can hijack the session.  No matter how
much
  > code is written, without some method of identifying the remote user,
either
  > through a certificate or something.

That hasn't taken off in so many years now...


  > You are trying to solve a problem that has plagued tcp for years. 
If you
  > open a session, and someone guesses the sequence number,

anyone can tell to use 'foo', with php4 session!

  > then they can
  > hijack the session.

#281
Gian

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

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

>  > OK, but if they are smart enough to sniff a cookie off of the
> wire, then
>
> I am always talking about unadvertely clicking on a link like
> https://www.www/www?PHPSESSID=1
> somewhere you click on that link that brings your cookie enabled site
> where, in case I'll register or login or simple visit, someone can
> reenter in my place and start from the situation as when I left.

This is a cross site scripting vulnerability inherent to the way HTTP works.
There is nothing we can do to prevent this.  If someone allows HTTP entry on
their site, then that is the risk they take.  This could easily enough occur
with another security breach and a page replacement.  This is an application
question.

>
>  > they are smart enough to set one.  That's what we are trying
> to prevent,
>  > correct?  The movement from cookie to GET?
>
> Both, but most worry is from get to cookie. From less to more trust &
> persistance. Catching this, supposes first that a cookie header is sent
> anytime even there is a GET request, and not to interprete the presence
> of GET sid as 'non availability of cookies'.
> We have two type of tickens at the cine. One is for a isolated, more
> aseptic, gallery upstair. The other is for the more promiscuous platea
> down, all together, where there's a lot of germs and it's easier to
> catch an influenza ;-)  You don't do well to your clients that should be
> lodged in area A to direct them down in  area B. And you don't do well
> either when you let people coming from area B enter area A.

So have one auth that only supports GET, and one that only supports cookies.
There is nothing to prevent this right now!

>
> Also the referer_check, in case the sid is in the url, is very useful. A
> must I think. There is a php.ini directive,
>
> session.referer_check = www.www

Referer is not set in the case of Javascript navigation, page refresh,
typeing in a direct url, etc. etc. etc.

>
> it intervenes only when there is a referer. But we can block when there
> is no referer
> Bookmarks have no referer, as links in email messages. GET SIDs without
> a referer,
> should be checked. This would block a good deal. I don't like the idea
> that the session management I implement is so easy to spoof on the
> massive, by absolutely whoever wants, with just a browser. The link
> itself becomes a troian.

Yes, so use SSL.  Problem solved.  The CSX vulnerabilities are not solvable.
They are inherent in the design of HTML.  They require user dillagence to
address to some extent, and non stupid programming on the others.  PHPLib
should not allow CSX in its own code.  But we are talking about people
writing programs whose job it is to make them secure.  All it takes to avoid
a CSX is to encode any HTTP traffic you get back.  Then anything inside a
link gets treated as text.

If what you want is to protect from csx's, then write a filter function that
all submitted URLs get run through.  This does not effect cookies anyway.
Here is an example:

XYZ has written an app that does not do input filtering and someone enters
javascript to read the session cookie and send it to them.  They get it,
creat the cookie, and now they can hijack the session.  No matter how much
code is written, without some method of identifying the remote user, either
through a certificate or something.  The best we can do right now is inform
in the docs.  If they don't read them, that's their fault.

You are trying to solve a problem that has plagued tcp for years.  If you
open a session, and someone guesses the sequence number, then they can
hijack the session.  Fortunately, in the TCP world there is connection
oriented information.  In the HTTP world, there is no connection, just
persistence.  As in, you can make an object persist from connection to
connection.  The availability of a cert provides some amount of "connection"
information.  If the SSL session ID was reliable, then that would be a good
identifier.  Until there is, we will beat our head against the wall trying
to fix a problem that is inherent in the protocol.

> It's message #280 by me on this subject. Dunno why everytime I restart
> this music, some patch reminded me ;-), I am tired . It's so easier to
> exploit this by anyone, than to explain it to the experts. I even don't
> care anymore. Forget this and don't worry.
>
> G
>


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

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

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

Correct, with a major exception.  There is no reason why a session could not
be transformed from one mode to another.  The mode would just have to be
stored in auth.  Then a page_open would know how to restore the session, and
a function such as auth->change_mode would make the change.  The list simply
specifies the ones you want to allow, and auth would pick the most secure
that works.  If you want to force a mode change, then no problem as long as
it is one of the ones that you support.

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


> -----Original Message-----
> From: Giancarlo [mailto:gia...@na...]
> Sent: Friday, December 06, 2002 9:18 PM
> To: rob...@ws...
> Subject: Re: [Phplib-users] store the IP in the session
>
>
> > $fallback_mode) because this would allow new modes to be added and a
> > preference list built ($mode = array("cert", "cookie")) where cert is an
>
> Ok, then in that case you'd certainly want to be able to apply 'cert'
> only froim a certain moment on, so be able to migrate your session and
> user data from the previous type of session into this new one. And not
> impose one choise at the start.
> And you'd never let a 'cert' session to downgrade to 'cookie' while
> maintaining the same privileges. OTH.
>
> Gian
>
>
>
>
>
>
>
>
>
>
>
>
>
>

[Phplib-users] Web Server Requeriments (please)

[Virilo T. A. <vi...@su...>]

I've never use a web server different to my Apache for win32.

Now i need to pay for a web hosting service (perhaps www.amen-es.com).

How know if its able to run phplib.  Its enough having php4?

Whats the matter with include files?  I could change php.ini? Its =
absolutely necessary?

Thanks.

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

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

Rob Hutton wrote:
>   This is the beginning of something better.  Buth auth should NEVER be done
> in a cascade fashion.  The should ALWAYS be a control structure. 

The API say that the checking of the input is to be done in the two 
auth_validatelogin() and auth_doregister() functions.
Note that they are both in local.inc.
These functions should return false if the input fields are not provided 
of wrong or false. Otherwise process the fields.
The fields used to be named
'username' ans 'password' in the login form.
'username', pass1','pass2' in the register form.
We only provide an example for the login suite,  auth_validatelogin ansd 
loginform.ihml though

The missin couple, auth_doregister() and registerform.ihtml that you 
used for your tests surely had the pwd name 'password' instead of 
'pass1', so if you submitted had different names that pass1, and i guess 
you named the password field just 'password' as in the login form ;-)

Anyway what I call cascade is not cascade, and the check_request() 
function I  lately added to use as switch for a control structure, apart 
from being a 'pre-duplicate' of what (the tests on the input) has 
already to be done in the two local.inc's function, the only two places 
where a user was supposed to place his hands  in all, for anything 
related to login and register
Note that, in plus, this is placed inside the main class. and not in 
local.inc.

Sorry, I won't change that 'cascade'.

Gian


  Secondly,
> there need to be more insertion points.  The concept that auth is a abstract
> class is a good one IMO.  Elimination of local.inc would be a mistake
> because now, as long as the API remains backwards compatable, you can drop
> local.inc into a newer version of PHPLib and not loose and customization.
> 
>   One other thing, everyone please keep discussion on the list and not in
> private.  There has evidently been a fair amount of off list work going on
> that when it hits the list causes much discussion.  I appreciate that there
> are people that are working on certain modules and have control over them,
> but we need to make sure that the changes made to PHPLib make sense for and
> to the community.
> 
> 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
> 
> 
> 
>>-----Original Message-----
>>From: Giancarlo [mailto:gia...@na...]
>>Sent: Thursday, December 05, 2002 12:05 PM
>>To: rob...@ws...
>>Subject: Re: [Phplib-users] store the IP in the session
>>
>>
>>I thought about auth. Yesterday I sent Joe this new start structure that
>>allows both, structured and,if not, default cascade. It also allows
>>calling the single action with start("authenticate"9, if specified.
>>
>>Gian
>>
>>Rob Hutton wrote:
>>
>>>>-----Original Message-----
>>>>From: php...@li...
>>>>[mailto:php...@li...]On Behalf Of Giancarlo
>>>>Sent: Thursday, December 05, 2002 6:49 AM
>>>>To: phplib-users
>>>>Subject: Re: [Phplib-users] store the IP in the session
>>>>
>>>>
>>>>Kristian Koehntopp wrote:
>>>>
>>>>>Somebody who does not use session cookies, but forces us to use
>>>>>GET parameters does not want to be secure, either. Again, we can
>>>>>code around that, but it is useless and bloats our code.
>>>>>
>>>>
>>>>Yes, but also we should explain very clearly, to ourselves first, that
>>>>using session cookies too, is prone to being forced into using GET... as
>>>>I am not sure yet there is a strong technical explaination.
>>>>So I'd add a $sticky_mode session variable to prevent ar allow
>>>>mode shifts.
>>>>
>>>
>>>That's a question of configuration.  If you don't want it to fallback to
>>>get, then don't enable that.  I think it should be defined clearer,
>>>something like $mode = array("cookie", "get", "post") (vs. the current
>>>$fallback_mode) because this would allow new modes to be added and a
>>>preference list built ($mode = array("cert", "cookie")) where cert is an
>>>extension of cookie that handles pki authentication.  But you
>>
>>can already
>>
>>>prevent mode shifts.
>>>
>>>Secondly, if this is going into the current snapshot auth, Joe
>>
>>and I have
>>
>>>some very real problems with the unstructured approach.  These
>>
>>need to be
>>
>>>addressed before further work is done.  I will post the one I
>>
>>modified to
>>
>>>the patches area today.
>>>
>>>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
>>>
>>>
>>>
>>
>>
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
> 

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

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

 >
 > OK, but if they are smart enough to sniff a cookie off of the wire, then

I am always talking about unadvertely clicking on a link like
https://www.www/www?PHPSESSID=1
somewhere you click on that link that brings your cookie enabled site
where, in case I'll register or login or simple visit, someone can
reenter in my place and start from the situation as when I left.

 > they are smart enough to set one.  That's what we are trying to prevent,
 > correct?  The movement from cookie to GET?

Both, but most worry is from get to cookie. From less to more trust &
persistance. Catching this, supposes first that a cookie header is sent
anytime even there is a GET request, and not to interprete the presence
of GET sid as 'non availability of cookies'.
We have two type of tickens at the cine. One is for a isolated, more 
aseptic, gallery upstair. The other is for the more promiscuous platea 
down, all together, where there's a lot of germs and it's easier to 
catch an influenza ;-)  You don't do well to your clients that should be 
lodged in area A to direct them down in  area B. And you don't do well 
either when you let people coming from area B enter area A.

Also the referer_check, in case the sid is in the url, is very useful. A
must I think. There is a php.ini directive,

session.referer_check = www.www

it intervenes only when there is a referer. But we can block when there
is no referer
Bookmarks have no referer, as links in email messages. GET SIDs without
a referer,
should be checked. This would block a good deal. I don't like the idea
that the session management I implement is so easy to spoof on the
massive, by absolutely whoever wants, with just a browser. The link
itself becomes a troian.
It's message #280 by me on this subject. Dunno why everytime I restart
this music, some patch reminded me ;-), I am tired . It's so easier to 
exploit this by anyone, than to explain it to the experts. I even don't 
care anymore. Forget this and don't worry.

G

RE: [Phplib-users] Structured auth with insertion points.

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

Thanks for the kind words.  I think that getting input from the wider
community, then making a descision is the best way to do things...

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


> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Chris
> Johnson
> Sent: Friday, December 06, 2002 12:01 PM
> To: Rob Hutton
> Cc: Phplib-Users
> Subject: Re: [Phplib-users] Structured auth with insertion points.
>
>
> On Fri, Dec 06, 2002 at 08:41:48AM -0500, Rob Hutton wrote:
> > Here is the structured auth I am working from.  The API is backwards
> > compatible with the current snapshot, but it has more insertion points.
> > There is a fair amount of cleanup that could be done, such as moving the
> > auth->refresh() code into a function such as Gian has done.  I
> will try to
> > do that if anyone is interested.
> >
> > Features:
> >   Can use header("Location:") to clean the URL before
> performing the auth
> > function in case the admin wants the user to be able to get out
> of auth by
> > refreshing.
> >   Can handle two or more phase auth.
> >   Insertion points to showform, handle, ok, and failed for register,
> > activate, and login.
> >   Easy addition of more modes.
>
> > Rob Hutton
>
> I like the logic of your recent posts and thinking, Rob.  I think you are
> going in the right direction with the auth class.
>
>
>
> --
>     ..chris
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

Re: [Phplib-users] Structured auth with insertion points.

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

On Fri, Dec 06, 2002 at 08:41:48AM -0500, Rob Hutton wrote:
> Here is the structured auth I am working from.  The API is backwards
> compatible with the current snapshot, but it has more insertion points.
> There is a fair amount of cleanup that could be done, such as moving the
> auth->refresh() code into a function such as Gian has done.  I will try to
> do that if anyone is interested.
> 
> Features:
>   Can use header("Location:") to clean the URL before performing the auth
> function in case the admin wants the user to be able to get out of auth by
> refreshing.
>   Can handle two or more phase auth.
>   Insertion points to showform, handle, ok, and failed for register,
> activate, and login.
>   Easy addition of more modes.

> Rob Hutton

I like the logic of your recent posts and thinking, Rob.  I think you are
going in the right direction with the auth class.



-- 
    ..chris

[Phplib-users] Structured auth with insertion points.

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

Here is the structured auth I am working from.  The API is backwards
compatible with the current snapshot, but it has more insertion points.
There is a fair amount of cleanup that could be done, such as moving the
auth->refresh() code into a function such as Gian has done.  I will try to
do that if anyone is interested.

Features:
  Can use header("Location:") to clean the URL before performing the auth
function in case the admin wants the user to be able to get out of auth by
refreshing.
  Can handle two or more phase auth.
  Insertion points to showform, handle, ok, and failed for register,
activate, and login.
  Easy addition of more modes.

OK, I'm ready!!! ;-)

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

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

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

> We are speaking about two different shifts then. I am speaking about
> shifts along the way, not initial fallback. Once a certain mode is
> started, the default or the fallback, LATER do not allow mode shifts. As
> if saying: "hey guy, I told you must have cookies, you HAD cookies, why
> now are you using anything else, if not because I let you do so? How can
> you pretend to be the same guy as before, and now you show me a
> photocopied ticket, while a moment agoI saw you had the original in your
> hand? We ae the cinema tenders, you know... and we've prevented false
> tickets at the entry, now we should prevent swawwing & reentering
> inside...If it makes any sense.
> G
>

OK, but if they are smart enough to sniff a cookie off of the wire, then
they are smart enough to set one.  That's what we are trying to prevent,
correct?  The movement from cookie to GET?

This is a policy decision of the site admin.  If they want to not have mode
changes, then use cookie only.  If you want to have gets, then use get only.
if (!session_start("cookie") || session_start("get")) solves the problem.
Having a structured approach with usable features is much more important
than trying to prevent the coder from doing something stupid.  If they do,
then it is their fault.


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

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

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

  This is the beginning of something better.  Buth auth should NEVER be done
in a cascade fashion.  The should ALWAYS be a control structure.  Secondly,
there need to be more insertion points.  The concept that auth is a abstract
class is a good one IMO.  Elimination of local.inc would be a mistake
because now, as long as the API remains backwards compatable, you can drop
local.inc into a newer version of PHPLib and not loose and customization.

  One other thing, everyone please keep discussion on the list and not in
private.  There has evidently been a fair amount of off list work going on
that when it hits the list causes much discussion.  I appreciate that there
are people that are working on certain modules and have control over them,
but we need to make sure that the changes made to PHPLib make sense for and
to the community.

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


> -----Original Message-----
> From: Giancarlo [mailto:gia...@na...]
> Sent: Thursday, December 05, 2002 12:05 PM
> To: rob...@ws...
> Subject: Re: [Phplib-users] store the IP in the session
>
>
> I thought about auth. Yesterday I sent Joe this new start structure that
> allows both, structured and,if not, default cascade. It also allows
> calling the single action with start("authenticate"9, if specified.
>
> Gian
>
> Rob Hutton wrote:
> >>-----Original Message-----
> >>From: php...@li...
> >>[mailto:php...@li...]On Behalf Of Giancarlo
> >>Sent: Thursday, December 05, 2002 6:49 AM
> >>To: phplib-users
> >>Subject: Re: [Phplib-users] store the IP in the session
> >>
> >>
> >>Kristian Koehntopp wrote:
> >> > Somebody who does not use session cookies, but forces us to use
> >> > GET parameters does not want to be secure, either. Again, we can
> >> > code around that, but it is useless and bloats our code.
> >> >
> >>
> >>Yes, but also we should explain very clearly, to ourselves first, that
> >>using session cookies too, is prone to being forced into using GET... as
> >>I am not sure yet there is a strong technical explaination.
> >>So I'd add a $sticky_mode session variable to prevent ar allow
> >>mode shifts.
> >>
> >
> > That's a question of configuration.  If you don't want it to fallback to
> > get, then don't enable that.  I think it should be defined clearer,
> > something like $mode = array("cookie", "get", "post") (vs. the current
> > $fallback_mode) because this would allow new modes to be added and a
> > preference list built ($mode = array("cert", "cookie")) where cert is an
> > extension of cookie that handles pki authentication.  But you
> can already
> > prevent mode shifts.
> >
> > Secondly, if this is going into the current snapshot auth, Joe
> and I have
> > some very real problems with the unstructured approach.  These
> need to be
> > addressed before further work is done.  I will post the one I
> modified to
> > the patches area today.
> >
> > 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
> >
> >
> >
>
>

[Phplib-users] documentation about security in propagation

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

I think the documentation is nebulous when it says
'cookies will be used when available'.
This is true also for php docu.
The meaning of that word 'when available' does ONLY mean 'when a cookie 
already exists @client', not 'when cookies are enabled @client'.
Because this can ingenerate a kind of false security on the designer, 
not to speak in the user with the enabled cookies.
In fact cookie enabled  clients will adopt any (preexistent now, at 
last, not user-fantasy) SID got in the URL and stay in GET mode, and 
never receive a cookie, though these are enabled.

[Phplib-users] session4 before the _SESSION birth

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

> BTW, back to session I put back php 4.2.1, tried both the new Maxim's 
> and the old session4 by Joe, and both do not workk with php 4.0.6

This is because the superglobal _SESSION started to exist sometime after 
4.06. I wonder if we can pass a check for something, and in case it 
results not supported create and use an alternative $GLOBALS["_SESSION"] 
as-if... sounds horrible eh?
G

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

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

> Secondly, if this is going into the current snapshot auth, Joe and I have
> some very real problems with the unstructured approach.  These need to be
> addressed before further work is done.  I will post the one I modified to
> the patches area today.

Yes, I had the doubt yesterday that there was some expectation on that 
auth. But that has absolutely nothing to do with this sessio problem. 
Last night I sent jos the last auth.inc, wich now can handle thre 
different situation. It can be callaed without a $request value, the 
default, as before, and it will first try to act on return by a 
check_request() function, or a passed funcion name. Otherwise will fall 
cascade. I think you can place the (try) register before login, to 
prevent loggin in when someone submit for register an existing 
username/pass/ pair.

BTW, back to session I put back php 4.2.1, tried both the new Maxim's 
and the old session4 by Joe, and both do not workk with php 4.0.6

https://sourceforge.net/tracker/download.php?group_id=31885&atid=403613&file_id=36932&aid=561500

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

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

  >>So I'd add a $sticky_mode session variable to prevent ar allow
  >>mode shifts.
  >>
  >
  > That's a question of configuration.  If you don't want it to fallback to
  > get, then don't enable that.  I think it should be defined clearer,
  > something like $mode = array("cookie", "get", "post") (vs. the current
  > $fallback_mode) because this would allow new modes to be added and a
  > preference list built ($mode = array("cert", "cookie")) where cert is an
  > extension of cookie that handles pki authentication.  But you can 
already
  > prevent mode shifts.

We are speaking about two different shifts then. I am speaking about
shifts along the way, not initial fallback. Once a certain mode is
started, the default or the fallback, LATER do not allow mode shifts. As
if saying: "hey guy, I told you must have cookies, you HAD cookies, why
now are you using anything else, if not because I let you do so? How is
it than now you bear a low-grade photocopied ticket, while a moment agoI
saw you had the original in your  hand? From the series We are the
cinema tenders, you know... and we've prevented false
tickets at the entry, now we should prevent swapping tickets inside &
reentering ...If it makes any sense. kindof pindaric may seem, but...
G

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

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

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Giancarlo
> Sent: Thursday, December 05, 2002 6:49 AM
> To: phplib-users
> Subject: Re: [Phplib-users] store the IP in the session
>
>
> Kristian Koehntopp wrote:
>  > Somebody who does not use session cookies, but forces us to use
>  > GET parameters does not want to be secure, either. Again, we can
>  > code around that, but it is useless and bloats our code.
>  >
>
> Yes, but also we should explain very clearly, to ourselves first, that
> using session cookies too, is prone to being forced into using GET... as
> I am not sure yet there is a strong technical explaination.
> So I'd add a $sticky_mode session variable to prevent ar allow
> mode shifts.
>
That's a question of configuration.  If you don't want it to fallback to
get, then don't enable that.  I think it should be defined clearer,
something like $mode = array("cookie", "get", "post") (vs. the current
$fallback_mode) because this would allow new modes to be added and a
preference list built ($mode = array("cert", "cookie")) where cert is an
extension of cookie that handles pki authentication.  But you can already
prevent mode shifts.

Secondly, if this is going into the current snapshot auth, Joe and I have
some very real problems with the unstructured approach.  These need to be
addressed before further work is done.  I will post the one I modified to
the patches area today.

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

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

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

Kristian Koehntopp wrote:
 > Somebody who does not use session cookies, but forces us to use
 > GET parameters does not want to be secure, either. Again, we can
 > code around that, but it is useless and bloats our code.
 >

Yes, but also we should explain very clearly, to ourselves first, that
using session cookies too, is prone to being forced into using GET... as
I am not sure yet there is a strong technical explaination.
So I'd add a $sticky_mode session variable to prevent ar allow mode shifts.

Gian