[PHP] Re: Securing areas of a web site with PHP

2003-01-01 Thread Tularis
Jean-Christian Imbeault wrote:

1- user logs in
2- user goes to restricted area
3- user views pages, orders an item, changes his account settings, etc ...
4- user logs out
5- user is sent to log out page
6- user hits back button ...

And here my problems start ... even though the user has logged out, all 
the restricted pages he saw are still cached by his browser and 
accessible ...

I have tried using a script that checks a session variable that 
indicates if a user is logged in or not and take appropriate action at 
the start of all restricted pages, but that doesn't work since when 
the user hits the back button, the PHP script is not re-executed, the 
page is simply loaded from the browser cache.

What are some PHP techniques I could use so that a user can no longer 
access/use pages once he has logged out?


I adives to make sure the browser doesn't cache it *at all*.
This can be done using (one, or more) of the following headers:

// HTTP 1.1 compliant:
header(Cache-Control: no-store, no-cache, must-revalidate);
header(Cache-Control: post-check=0, pre-check=0, false);
// HTTP 1.0 compliant:
header(Pragma: no-cache);

Hope that helps,
- Tularis


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP] Re: Securing areas of a web site with PHP

2003-01-01 Thread Jean-Christian Imbeault
Tularis wrote:


I adives to make sure the browser doesn't cache it *at all*.
This can be done using (one, or more) of the following headers:

// HTTP 1.1 compliant:
header(Cache-Control: no-store, no-cache, must-revalidate);
header(Cache-Control: post-check=0, pre-check=0, false);
// HTTP 1.0 compliant:
header(Pragma: no-cache);


I'll try this out and see what I get. Though I have read that not all 
browsers follow cache-control directives ...

This would cause the load on my web server to increase for those pages 
though ... might there be another way?

If not then it will have to do ...

Thanks for the advice!

Jc


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Re: Securing areas of a web site with PHP

2003-01-01 Thread michael kimsal
Jean-Christian Imbeault wrote:



I'll try this out and see what I get. Though I have read that not all 
browsers follow cache-control directives ...

Exactly - and some don't follow other HTTP header directives to the 
letter either.  You will not be able to 'secure' this stuff 100% simply
because you only control 50% of the environment (the server, not the 
client).  The cache-control stuff people have already replied is good, 
but realize nothing's 100%.  You also can't prevent someone from taking 
a snapshot of the page, or control who sees a piece of paper with the 
information printed on it either.  :)




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Re: Securing areas of a web site with PHP

2003-01-01 Thread David Tandberg-Johansen
[CUT]

I am using SESSION on al my secure projects
I use a file structur as this:
(loginform) - logincheck.php (if not ok-back2login | if ok (start an
session)(forward to the secure pages))

When the user logs out:
(securepages)-logout.php:
?PHP
//go through all the session array an unregister the varname
foreach($_SESSION as $key=$val){
session_unregister($key);
}
// We destroys the session
session_destroy();

//if there are an cookie vith the session name we have to unset it
//so the browser doesn't hvae the information
if(isset($_COOKIE[session_name()])){
// To delete the old cookie
unset($_COOKIE[session_name()]);
}
//we starts an new session
session_start();
//and we destroys it again
session_destroy();
//Now there are an new session cookie in the browser,
//and if the user try go back there are no data stored in the session

//we forward the user to an unsecure public page
header(Location: ./unsecurepublicpage.php);
?



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] Re: Securing areas of a web site with PHP

2003-01-01 Thread Jason Wong
On Wednesday 01 January 2003 19:24, Jean-Christian Imbeault wrote:
 Tularis wrote:
  I adives to make sure the browser doesn't cache it *at all*.
  This can be done using (one, or more) of the following headers:
 
  // HTTP 1.1 compliant:
  header(Cache-Control: no-store, no-cache, must-revalidate);
  header(Cache-Control: post-check=0, pre-check=0, false);
  // HTTP 1.0 compliant:
  header(Pragma: no-cache);

 I'll try this out and see what I get. Though I have read that not all
 browsers follow cache-control directives ...

The cache-control directives are only supposed to be followed if the page was 
to be _explicitly_ reloaded or refreshed. The BACK button (as specified in 
the standards rfc  something or another) is NOT supposed to reload or 
refresh a page -- it is supposed to redisplay the page from the cache. Buggy 
browsers like NN, IE  Mozilla etc reloads the page. Well behaved browsers 
like Opera redisplays from cache and hence your problem.

-- 
Jason Wong - Gremlins Associates - www.gremlins.biz
Open Source Software Systems Integrators
* Web Design  Hosting * Internet  Intranet Applications Development *

/*
It's important that people know what you stand for.
It's more important that they know what you won't stand for.
*/


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] Re: Securing areas of a web site with PHP

2003-01-01 Thread Jason Wong
On Thursday 02 January 2003 01:56, David Tandberg-Johansen wrote:
 [CUT]

 I am using SESSION on al my secure projects
 I use a file structur as this:
 (loginform) - logincheck.php (if not ok-back2login | if ok (start an
 session)(forward to the secure pages))

 When the user logs out:
 (securepages)-logout.php:
 ?PHP
 //go through all the session array an unregister the varname
 foreach($_SESSION as $key=$val){
 session_unregister($key);
 }
 // We destroys the session
 session_destroy();

 //if there are an cookie vith the session name we have to unset it
 //so the browser doesn't hvae the information
 if(isset($_COOKIE[session_name()])){
 // To delete the old cookie
 unset($_COOKIE[session_name()]);
 }
 //we starts an new session
 session_start();
 //and we destroys it again
 session_destroy();
 //Now there are an new session cookie in the browser,
 //and if the user try go back there are no data stored in the session

 //we forward the user to an unsecure public page
 header(Location: ./unsecurepublicpage.php);
 ?

If you use Opera to access your application, does the BACK button allow you to 
see previously viewed 'secure' pages after being logged out?

-- 
Jason Wong - Gremlins Associates - www.gremlins.biz
Open Source Software Systems Integrators
* Web Design  Hosting * Internet  Intranet Applications Development *

/*
the AA battery in the wallclock sends magnetic interference
*/


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] Re: Securing areas of a web site with PHP

2003-01-01 Thread Jason Sheets
Instead of doing a foreach to unset your session variables you can use
session_unset(); which will unset all your session variables for you.

Additionally if you are wanting to remove a cookie from a visitor's
browser you should use setcookie, not unset $_COOKIE, $_COOKIE allows
you to access the value of a cookie but not set or alter the contents of
the actual cookie. 

The manual page for session_unset is
http://www.php.net/manual/en/function.session-unset.php

The manual page for setcookie is 

http://www.php.net/manual/en/function.setcookie.php

Also once you have executed session_destroy you have deleted the session
information from the server, if you delete the sessionid cookie from the
browser they will get a new session id the next time a session is
started, there is no need to immediatly start and destroy another
session.

If you do not care if a user gets a new session id the next time they
visit your site you do not necessarily have to worry about deleting the
sessionid cookie as the data is already destroyed and the cookie will be
deleted when they close their browser (if cookie life is 0) or when the
cookie lifetime expires.

Most if not all of this information is available from the PHP manual at
http://www.php.net/manual

Jason

On Wed, 2003-01-01 at 10:56, David Tandberg-Johansen wrote:
 [CUT]
 
 I am using SESSION on al my secure projects
 I use a file structur as this:
 (loginform) - logincheck.php (if not ok-back2login | if ok (start an
 session)(forward to the secure pages))
 
 When the user logs out:
 (securepages)-logout.php:
 ?PHP
 //go through all the session array an unregister the varname
 foreach($_SESSION as $key=$val){
 session_unregister($key);
 }
 // We destroys the session
 session_destroy();
 
 //if there are an cookie vith the session name we have to unset it
 //so the browser doesn't hvae the information
 if(isset($_COOKIE[session_name()])){
 // To delete the old cookie
 unset($_COOKIE[session_name()]);
 }
 //we starts an new session
 session_start();
 //and we destroys it again
 session_destroy();
 //Now there are an new session cookie in the browser,
 //and if the user try go back there are no data stored in the session
 
 //we forward the user to an unsecure public page
 header(Location: ./unsecurepublicpage.php);
 ?
 
 
 
 -- 
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] Re: Securing areas of a web site with PHP

2003-01-01 Thread David Tandberg-Johansen
I have tested this with all kind of browsers on WIndows, and to make a clean
cut I had to do so..


Jason Sheets [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
 Instead of doing a foreach to unset your session variables you can use
 session_unset(); which will unset all your session variables for you.

 Additionally if you are wanting to remove a cookie from a visitor's
 browser you should use setcookie, not unset $_COOKIE, $_COOKIE allows
 you to access the value of a cookie but not set or alter the contents of
 the actual cookie.

 The manual page for session_unset is
 http://www.php.net/manual/en/function.session-unset.php

 The manual page for setcookie is

 http://www.php.net/manual/en/function.setcookie.php

 Also once you have executed session_destroy you have deleted the session
 information from the server, if you delete the sessionid cookie from the
 browser they will get a new session id the next time a session is
 started, there is no need to immediatly start and destroy another
 session.

 If you do not care if a user gets a new session id the next time they
 visit your site you do not necessarily have to worry about deleting the
 sessionid cookie as the data is already destroyed and the cookie will be
 deleted when they close their browser (if cookie life is 0) or when the
 cookie lifetime expires.

 Most if not all of this information is available from the PHP manual at
 http://www.php.net/manual

 Jason

 On Wed, 2003-01-01 at 10:56, David Tandberg-Johansen wrote:
  [CUT]
 
  I am using SESSION on al my secure projects
  I use a file structur as this:
  (loginform) - logincheck.php (if not ok-back2login | if ok (start an
  session)(forward to the secure pages))
 
  When the user logs out:
  (securepages)-logout.php:
  ?PHP
  //go through all the session array an unregister the varname
  foreach($_SESSION as $key=$val){
  session_unregister($key);
  }
  // We destroys the session
  session_destroy();
 
  //if there are an cookie vith the session name we have to unset it
  //so the browser doesn't hvae the information
  if(isset($_COOKIE[session_name()])){
  // To delete the old cookie
  unset($_COOKIE[session_name()]);
  }
  //we starts an new session
  session_start();
  //and we destroys it again
  session_destroy();
  //Now there are an new session cookie in the browser,
  //and if the user try go back there are no data stored in the session
 
  //we forward the user to an unsecure public page
  header(Location: ./unsecurepublicpage.php);
  ?
 
 
 
  --
  PHP General Mailing List (http://www.php.net/)
  To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP] Re: Securing areas of a web site with PHP

2003-01-01 Thread Mel Lester Jr.
You might consider using cookies that keep track of the user's
login name and a bitwise status to control AAA (Authentication,
Authorization, and Access0 controls instead of using session variables.

-mel

On Wed, 1 Jan 2003, Jean-Christian Imbeault wrote:

 On my web site there are some areas that I want to make accessible only 
 after a user has logged in (for example when placing an order, etc ...) 
 I have been able to achieve this however I have the following problem:
 
 1- user logs in
 2- user goes to restricted area
 3- user views pages, orders an item, changes his account settings, etc ...
 4- user logs out
 5- user is sent to log out page
 6- user hits back button ...
 
 And here my problems start ... even though the user has logged out, all 
 the restricted pages he saw are still cached by his browser and 
 accessible ...
 
 I have tried using a script that checks a session variable that 
 indicates if a user is logged in or not and take appropriate action at 
 the start of all restricted pages, but that doesn't work since when 
 the user hits the back button, the PHP script is not re-executed, the 
 page is simply loaded from the browser cache.
 
 What are some PHP techniques I could use so that a user can no longer 
 access/use pages once he has logged out?
 
 Basically I would like to have sort of state machine so I that I can 
 simply check where a user is coming from and his login state to decide 
 if a certain page should be presented or not (i.e. you can't get here 
 form there or you can't view that page with your current login status).
 
 But it seemed that creating a state machine is not the right way to go 
 about it since hitting the back button pretty much allows a user to 
 circumvent this ...
 
 Eventually the web site I will build will actually have many areas, 
 each needing a separate/different login, (and you can be logged in to 
 multiple areas at once) so I would like to be able to generalize this 
 problem and understand how I can use PHP to implement the needed 
 functionality.
 
 Just as a simple example, once a user has placed an order, he should not 
 be able to go back to the order placing/processing pages ...
 
 Any tips, hints, or pointers to tutorials are appreciated!
 
 Thanks,
 
 Jc
 
 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] Re: Securing areas of a web site with PHP

2003-01-01 Thread Justin French
A lot has been said on the issue already, so I'll attempt to keep mine
brief.

Cache control will help a little, but not all browsers support it.  Yes, it
will cause a little more traffic on your site, and yes it will help keep
some people from clicking back, but it certainly won't FIX anything.

Javascript can disable back buttons, but i've never used it, because
a) I hate javascript
b) you can't rely on javascript to be available
c) i don't like forcing people to work a certain way
d) there are always work-arounds

I know it sounds simple, but try to analyse what other big sites are doing
in this situation:

- amazon.com doesn't seem to break when I disrupt my surfing with a login
or logout... it just picks up the pieces and does what it can.  last time I
bought stuff there, I certainly didn't notice any caching issues, or that my
back button was disabled.

- my bank, the national bank (national.com.au) pops up the entire secure
banking process in a new javascript window... essentially, this starts a new
process for the user in a new window.  when they log-out, the window is
useless and is closed... there is NO clicking back if the window is closed
:)  I guess the national were concerned enough about back buttons and all
that stuff to require javascript in order to use net banking... you'd have
to make your own assessment of that.


If there's a big issue with people clicking back, I'd suggest that there
*may* be a problem with the logic of your site.  Afterall, clicking back
is what the web is about!!  If the big sites can cope with it, I'm sure you
can.

In short my solution is that if you CAN'T live with people clicking back,
then you should open the sensitive content in a new window which is
auto-closed when the user logs out... this way there is no hope of clicking
back.  Yes it requires javascript, which means you have to think hard about
ignoring a % of your users.


Justin French


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] Re: Securing areas of a web site with PHP

2003-01-01 Thread Jean-Christian Imbeault
Justin French wrote:


I know it sounds simple, but try to analyse what other big sites are doing
in this situation:


That's exactly what I did, but I don't understand *how* they do it hence 
my question.

I surfed some of the big sites and saw that they do not break when a 
user hits the back button in the middle of a transaction or when the 
user is viewing a secure part of a web site.

 If there's a big issue with people clicking back, I'd suggest that
 there *may* be a problem with the logic of your site.  Afterall,
 clicking back is what the web is about!!  If the big sites can cope
 with it, I'm sure you can.

Exactly. It can be done, but how. What are the techniques that I can 
use? On amazon for example they didn't rely on javascript and it didn't 
seem like they had turned caching off or force and refreshes.

From what I could tell, you could use the back button without any 
problems. *But* if you went back to a page and *then* clicked on 
something (a link, a button) then some kind of logic kicked and figured 
out that you where doing the same thing twice, or where doing something 
in an area you were not logged in to and acted accordingly.

So I agree with you that it definitely boils down to a logic of your 
site thing.

But what does that mean? How do I implement logic in my site? What are 
the ways to do this in PHP? What techniques do most PHP powered sites 
employ, what patterns?

Sorry if these are newbie questions ... I'm programmer, and understand 
the PHP language but when it comes to site design/logic with PHP I 
don't really know where to start.

Any help or pointers again very much appreciated!

Jc


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Securing areas of a web site with PHP

2003-01-01 Thread Jean-Christian Imbeault
Jason Wong wrote:


The cache-control directives are only supposed to be followed if the page was 
to be _explicitly_ reloaded or refreshed. The BACK button (as specified in 
the standards rfc  something or another) is NOT supposed to reload or 
refresh a page -- it is supposed to redisplay the page from the cache. Buggy 
browsers like NN, IE  Mozilla etc reloads the page. Well behaved browsers 
like Opera redisplays from cache and hence your problem.

Ah ... so using cache control is *not* the way to solve my problem ...

As Justin pointed it out I should be looking into solving this within my 
site logic then I guess ...

Does anyone know of any good online references or even books where I 
could read up on on to build logic into my site.

All the PHP books and references I have are great from a programming 
point of view but they hardly mention anything about site 
navigation/logic and how to implement it in PHP ...

Thanks!

Jc


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php