[thelist] php login security (was: Call html page with php)

Andrew Forsberg andrew at thepander.co.nz
Wed Feb 20 15:28:00 CST 2002


>good morning to you. now it's late here, and i take it you have just got up?
>you now have the advantage. :o)

Good morning to you too!

I was actually writing a response to your last email, :) just call me
bloody-minded:

>if you are referring to my case, then i would reiterate that there were
>sessions involved, just not php 4 sessions.

Ben Phillips wrote about 8 hours ago:
>no, a session id is passed between pages. the session id is created when a
>user logs in. this is then compared to that stored in the database. if it is
>valid, and hasn't timed out then the login is okay.
>
>when i said session variables weren't available, i meant php 4
>$HTTP_SESSION_VARS. sorry for confusion.

OK, so each page would have something like this included at the top:

if ($HTTP_POST_VARS["register_user"]==TRUE) {
	// authenticate them
	// set loginOK to true if appropriate
}

if ($MY_SESSION_VAR["loginOK"]!=TRUE) {
	// redirect them somewhere else
	exit(); // kill further output just to make sure
}

// all is cool and they get the secret content

If someone has attempted a login, then that gets handled first. If
someone's logged in (either in the first IF block, or previously)
then everything runs as usual. Otherwise they're kicked back to some
generic login screen, a message is displayed, or whatever other
policy is followed for unwanted users.

>  > What are the advantages of reauthenticating a user on each page?
>
>see above comment. badders.com has a login box on every page. the user can
>use this to log in. the session code included on every page checks to see if
>a session id is passed, if not then it checks to see if a login attempt has
>been made, if not then it displays the login box (roughly).

Aaaah. We're using terms in different ways. By 'authenticate' I mean:
'compare the provided login data against a record of registered
users, if there's a match the user is authenticated.' By 'authorize'
I mean: 'an authenticated user may be authorized to use a page, a
flag is typically checked to see if they are allowed to view the
document.'

So the first IF block above would load an authentication script. The
second IF block is a simple authorization test. Checking whether a
user is authorized on each page of a secure area is necessary,
authenticating a user on every page is not necessary.

In your original example the $loginOK variable is either the result
of an internal authentication script which is re-evaluated on every
page; or, it is your session's flag that the user is good to go, ie,
authorized to view the page. The former involves a lot of redundant
work on each page, in my opinion, but is safe enough as long as the
user/pass are session variables, or otherwise kept from GET/POST
(even storing them in cookies would not be nice). The latter requires
that $loginOK is not liable to be hidden by a GET/POST/COOKIE
variable -- or there is no security.

The default variable scope order is EGPCS: environment, get, post,
cookie, and (PHP 4's internal) session variables. So, the custom
session handler your program used loaded all of its variables into
the local scope?

>btw, the information on save handlers was very interesting, thanks for that.

No problem. :)

>benji
>inchima.com

Cheers
Andrew
--
Andrew Forsberg
---
uberNET - http://uber.net.nz/
the pander - http://thepander.co.nz/



More information about the thelist mailing list