Page 1 of 1

PHP & security: .htaccess or PHP sessions?

Posted: Wed Jun 25, 2003 5:15 am
by hhfbrouwer
Hi,

I want to use PHP to manage restricted access pages. They have to be of course 99,9% safe.

First, I want to use a MySQL database to manage groups/members

I know two methods: .htaccess and sessions.
I think using sessions is better because you can integrate the login screen in a page and you're not dependent on the .htaccess files.

But is is a PHP Session variable

Code: Select all

$login = "ok";
together with

Code: Select all

if ($login == "ok") dispay_page();
safe enough (read: as safe as .htaccess)?

Please share any thoughts you have on this issue.
Regards,
Hessel

[/i]

Posted: Wed Jun 25, 2003 7:34 am
by cactus
I think your getting a little confused with the terminology, Sessions do not equate to security they are just a method for maintaining data between pages (granted that data is not on the client so could be considered secure, but IMO that would be reaching).

.htaccess is just a method for implementing per directory options or to affect the Apache/PHP (etc) config and as such does not actually equate to security.

IMO (and depending on how "secure" you need to be), you need to implement a combination of ".htaccess", Sessions and SSL (you pick) but the only real "secure" method is SSL and some form of login.

BTW, you don't need to use ".htaccess" to get the benefits of HTTP Auth. PHP has a perfectly good implementation of that which you can link into your sessions/dB/login solution.

Ref: http://www.php.net/manual/en/features.http-auth.php

Regards,

Re: PHP & security: .htaccess or PHP sessions?

Posted: Wed Jun 25, 2003 11:42 am
by BDKR
hhfbrouwer wrote:Hi,
But is is a PHP Session variable

Code: Select all

$login = "ok";
together with

Code: Select all

if ($login == "ok") dispay_page();
safe enough (read: as safe as .htaccess)?
Something you may want to consider about the above:

What if someone passes the url as 'http://yourpage.com?login=ok' ?

It shouldn't work since version 4.2, unless you are doing something like...

Code: Select all

$login=$_GET['login'];
Then you're bummin'! 8O

I prefer to just pass around a session variable. That session variable can be moved around in a number of different ways. Most people use cookies. Another thing to consider is where or how that session variable is handled. PHP has built in fuctions for this. I store the session data in a database. With the sessions info stored in a database, data used to control the state of a session never need to be sent to the user.

Cheers,
BDKR

Re: PHP & security: .htaccess or PHP sessions?

Posted: Wed Jun 25, 2003 11:53 am
by nielsene
BDKR wrote:I store the session data in a database. With the sessions info stored in a database, data used to control the state of a session never need to be sent to the user.
But how do you store/track the key ueed to index into the database? Your "session id"? Unless you're using the clients IP addy(insecure) you're forced to send something over the link....

Posted: Wed Jun 25, 2003 4:12 pm
by McGruff
Doesn't answer your question exactly but might be useful:

http://httpd.apache.org/docs-2.0/howto/htaccess.html

Re: PHP & security: .htaccess or PHP sessions?

Posted: Wed Jun 25, 2003 4:47 pm
by BDKR
nielsene wrote:
BDKR wrote:I store the session data in a database. With the sessions info stored in a database, data used to control the state of a session never need to be sent to the user.
But how do you store/track the key ueed to index into the database? Your "session id"? Unless you're using the clients IP addy(insecure) you're forced to send something over the link....
Yes, the session id. I send the session id back and forth. Isn't that better than storing user name and password data in a cookie as some have actually written articles suggesting? And it's also better, not to mention more scalable and flexible, then storing the info in a temp file.

If I'm missing something here, please let me in on it.

Cheers,
BDKR

Posted: Thu Jun 26, 2003 10:24 am
by nielsene
When you said:
BDKR wrote: With the sessions info stored in a database, data used to control the state of a session never need to be sent to the user.
I thought you were saying that the sessionid was not being sent to the client I thought you were implying that writing your own database handlers for session variables was more secure (in terms of network security) than the default file-based method.* But it looks like that's not what you meant.

I'll agree that sending the minimal about of data required for security/tracking is appropriate and that using session variables is better than sending loads of cookies.

However, I'll stand by my view that PHP's session implementation is flawed and insecure. And current versions do not provide a tool for making secure sessions without sending an extra cookie.**

PHP uses the phpsessid value as an authenticator for tracking state. However it misses three important features:
1. No tamper-detection of the sessionid
2. No tamper-detection of the expiration time
3. No server side checking of the expiration time.

Combined this makes session hijacking and reply attacks trivial. Its possible to send a proper authenticator in a cookie, or in a GET string or where your script compares the PHP passed sessionid with the manually passed sessionid in the authenticator.

*. Yes, on a shared host a database based session handler is more secure from local users than the defaulty bahavoir.
**. Actually I think I might be wrong here. It might be possible to play around with setting session_iid manually. The last time I tried though was in the 4.0.4pl? version, which caused crashes. I should try again and report results. However, will I can add the data needed to make it a good authenticator, I would not be able to "build-in" the proper tamper-detection or server-side expiration without using application code. This means that for 90% or more of the PHP programmers out there, sessions will remain insecure.

Posted: Thu Jun 26, 2003 12:02 pm
by BDKR
Well, I was just curious for the most part if there was some gross error I was committing. 8O
nielsene wrote: However, I'll stand by my view that PHP's session implementation is flawed and insecure. And current versions do not provide a tool for making secure sessions without sending an extra cookie.**
You'll get no dis-agreement from me on that one.
nielsene wrote: PHP uses the phpsessid value as an authenticator for tracking state. However it misses three important features:
1. No tamper-detection of the sessionid
2. No tamper-detection of the expiration time
3. No server side checking of the expiration time.
Once again, I agree. However, it does help people get in the ballpark rather quickly and easily. I'll give it that much credit, even though I roll my own sessions stuff.

Another good thing about storing sessions data in a db is that it scales better than a file based approach, and moving an application to a web or server farm doesn't break it's sessions handling.

Cheers,
BDKR

Posted: Thu Jun 26, 2003 12:58 pm
by nielsene
BDKR wrote: Once again, I agree. However, it does help people get in the ballpark rather quickly and easily. I'll give it that much credit, even though I roll my own sessions stuff.
True. However, I wish they would improve the default. Security isn't easy. Most people know next to nothing, or only enough to be dangerous to themselves. It would be nice if PHP could, by default do more to protect the sessionid so coders don't have to roll-their-own session security solutions. If the default were secure, then its less important for the average user to worry about it. People who really need security would probably still need to adapt/extend/invent. If the default were more secure than the default of other web-services languange it greatly raises the bar for hacking a php based site, and attackers would go elsewhere first if they are just looking to "grief" someone.

But when i raised this issues last year, the php people took the stance that security is application-centric and not their problem....

Posted: Thu Jun 26, 2003 5:58 pm
by BDKR
nielsene wrote:
If the default were secure, then its less important for the average user to worry about it. People who really need security would probably still need to adapt/extend/invent. If the default were more secure than the default of other web-services languange it greatly raises the bar for hacking a php based site, and attackers would go elsewhere first if they are just looking to "grief" someone.
Well said. I sent you a message elsehwere (I think?) about this.

Cheers,
BDKR

Posted: Thu Jun 26, 2003 10:56 pm
by nielsene
Yup you did, hopefully I get around to it soon :)