Basic Security

[JDex]

Hello and Happy Holidays to the family...

 

I have been learning PHP for a few weeks and I really think that I have picked up the basics and intermediate uses quite well. I have assembled the basic structure of my new site and I am loving the uses of Server Side Dynamic pages... My current thought processes have gone to Security and User authentication. While I am not one prone to reinvent the wheel, I am prone to trying to understand everything that is happening so that I can make modifications as needed and not have to rely solely on the help of others... In addition to a lot of googling and sifting through results I have scanned the entire TCH Security forum and have come up with some TCH questions, as well as some conceptual questions that hopefully my new family can assist with.

 

Firstly let me give you some background on my expected security needs... I don't need first-rate Fort Knox type security... I will not be handling overly-sensitive user data... no credit cards or social security numbers... basically I will just have "registered user" areas that I want to be "relatively" certain are being viewed by registered users.

 

Intro on my current plan

 

I will be using cookies and sessions for redundancy as well as coverage for users w/ cookies disabled.

 

I have protected my included/required files with a set of custom functions called establishHackCheckL#() and runCheckHackL#() that I will explain in a bit.

 

I have buried my database connection info in layered requires.

 

I intend to setup folders containing sensitive data (such as function definitions and db connection info) so that if accessed directly, they fail to send data to the browser.

 

Details of what I have done

 

Use of cookies/sessions...

 

Rather than store Username and Password info in the cookies... I am creating a "authentication code" using the sessionID and a random sequence generator... Upon login the authcode is placed in a cookie called user as well as an entry in the database attached to the user's ip address and current timestamp. The Session recieves a serialized variable called auth and the authcode is placed within. On each page the authcode will be referenced against the ip address in the DB, and if false the guest would need to login. If the session in non-existant, because the user is visiting the site again the site will check for the cookie and validate the authcode/ip relationship then establish the session again. Since many visitors may visit from multiple locales (school, home, work etc...) the authcode tracking table actually will keep tabs on 5 ip addresses and should there be a sixth login point, the system will overwrite the entry that hasn't been used for the longest period of time... Now I know that people with Dynamic IP addresses (which is alot of people) will have to login everytime their addy changes, but I am confident that my audience is okay with that.

 

 

establishHackCheckL#() and runCheckHackL#()...

 

All of my rootpages have a sans-$ variable (I think the term is pagevar) that is established and the entry in that variable is a long static alpha-numeric code... 99% of the sub-pages (included and required files) all check to see that the variable is established, and that the entry is the expected code... if this two-layer check fails, the page dies and all available data is logged in a db via a db connection that only has insert access to a db that only has one table... and it is dedicated to logging hack attempts. If any ip is logged 10 times in a 24hour period it is flagged and a message shows up in the admin panel I have constructed... if it is logged 20 times in the same period the ip is banned (via php/mysql) for a 72 hour period and the admin is notified. Then I can decide if I want to perma ban the ip and look deeper into it.

 

 

DB Connection info in Layered Requires

 

 

After the above "Hack Check" is established in a root page, a page is required that houses the db select info "mysql_select_db()"... before selecting however a second HackCheck is established (Level2) and a page is required that calls the "mysql_connect" command... on that page, again before connecting to the host, it checks for the Level 2 hack, establishes a Level 3 hack and requires yet another page that houses my host name, username, password, db name... Overkill, probably.

 

 

Based upon these brief descriptions, does anyone have any immediate "red-flags" that go up regarding hackability or implementation problems? I can go into more detail and provide generic-ized code to explain further if neccesary...

 

 

Now for some questions... One of the initial resources I have used for learning PHP/MySQL basics is the VTMs at http://www.3dbuzz.com They are very beginner level, but great. In the Integrating PHP/MySQL video they edit the httpd.conf file in Apache to make folders unaccesible in a direct manner, but files within "include-able" and "require-able"... I am wondering if TCH users can accomplish this, or if it is something we cannot access. If it is unavailable, is there a way that we can make access to a folder limited in the same manner?

 

Is using PHP/MySQL in conjunction with weekly changed passwords likely to provide enough security for my admin pages, or should I use the directory level password protection built in to the cPanel... I can use either, but I there are some decent benefits of using PHP based... I had hoped to make some dynamic code in all my pages that offer admin privileges directly on the page...

 

I am sure I'll have other questions, but I don't want to overwhelm over the holidays... thanks for indulging me and an any input will be appreciated.

 

Cheers.

[JDex]

Hmmm... No comments or responses. Holiday?

[TCH-Rob]

Sorry JDex,

 

I am not smart enough to follow along and I personally cant answer that question. I am sure others will be along that can though.

[zathros]

Hey there.

I'm new to TCH and all, but I have done a few things with MySQL and PHP. While I'm not an expert on all the PHP security issues, I think I have a decent understanding of what's going on, and I've done a couple authentication systems in PHP (with and without MySQL).

 

I have a few questions/comments about the system you're designing, and I'll post them in response to your summary.

 

I will be using cookies and sessions for redundancy as well as coverage for users w/ cookies disabled.

So far, I haven't needed to use cookies in my systems, but it looks like you're not storing anything that could cause problems that are too big if it were compromised and used elsewhere. I guess the worst that could happen is maybe somehow the cookie gets "stolen" and someone is able to login as someone else. No?

 

I have protected my included/required files with a set of custom functions called establishHackCheckL#() and runCheckHackL#() that I will explain in a bit.

 

This whole thing seems like overkill to me. All PHP code gets parsed by the web server as it brings up a page. I think it would be difficult for PHP to fail in such a way that it displays the source of the PHP file without bringing down the rest of the web server. Is that incorrect? Includes are cool for modularity, but I don't see why it's necessary to bury stuff into includes for security. Maybe I misunderstand what you're doing. The establishHackCheckL#() and runCheckHackL#() functions sound like they would be useful to force someone to come through a specific entry-point to the site. However, I don't understand why you wish to do that. Are you only authenticating users at that one point? I would suggest that each page verify that a session has been established and react according to what kind of user is logged in. Would that not be good enough?

 

Based upon these brief descriptions, does anyone have any immediate "red-flags" that go up regarding hackability or implementation problems?  I can go into more detail and provide generic-ized code to explain further if neccesary...

From what I understand of what you're doing, it seems like you've got a pretty good system. It might be a little too much, though, and that could make it rather complex... which doesn't have to be a bad thing. Just as long as you've got it straight and know what's really happening.

 

Now for some questions... One of the initial resources I have used for learning PHP/MySQL basics is the VTMs at http://www.3dbuzz.com  They are very beginner level, but great.  In the Integrating PHP/MySQL video they edit the httpd.conf file in Apache to make folders unaccesible in a direct manner, but files within "include-able" and "require-able"... I am wondering if TCH users can accomplish this, or if it is something we cannot access.  If it is unavailable, is there a way that we can make access to a folder limited in the same manner?

 

I don't know what specific tutorial you're referring to, and I'm not familiar with that site, so I don't know exactly what they did. However, I would suspect that this can be accomplished well enough simply by placing the necessary files in a directory that is not under the web server's wwwroot. In the case of the TCH site, this would mean not under your public_html directory. You would then give the complete path to the file in your PHP include or require statement. As long as the files are readable by the user that the web server runs as, you should be fine. This might be easier than messing with httpd.conf, which we wouldn't have access to. However, you might be able to do something similar to whatever they did with a .htaccess file. We'd have to know exactly what it was they did and do some research to find out.

 

Also, you might have to figure out what the full path to your user directory is for that last thing. Some TCH support people might be able to answer that question. Basically, you want to know what is the full path to the home directory? /home/username, maybe? You could also find this out with a test script that prints out the location of the current directory.

 

Is using PHP/MySQL in conjunction with weekly changed passwords likely to provide enough security for my admin pages, or should I use the directory level password protection built in to the cPanel... I can use either, but I there are some decent benefits of using PHP based... I had hoped to make some dynamic code in all my pages that offer admin privileges directly on the page...

 

Personally, I think the PHP authentication is what I'd consider good enough. It is my understanding that attacks against sessions and cookies do exist, but you said you don't have super-critical information in there. Plus, I think you're doing good not putting anything that would give away the user/password pair in your cookie. I'd think the directory authentication is not as flexable as your PHP stuff, and I don't consider it more secure as long as the PHP stuff is done right. Does anyone else have input on this?

 

Anyway, unless you're really using SSL for all this in addition, it's rather pointless to spend a huge amount of much time on the authentication system. Someone could just snatch your users' passwords as they login, if it's sent in cleartext.

 

 

Overall, I'd say the system sounds pretty good.

Let me know what you think about my comments/suggestions.