General structuring of security.

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
sHobbsWW
Forum Newbie
Posts: 15
Joined: Wed Jul 16, 2008 10:48 am

General structuring of security.

Post by sHobbsWW »

The subject might sounds complex but the question is quite simple.

In general, how does one know how to go about the structure of his or her website design (in terms of code).

By that I mean, I am creating a web site for a company with a (to me) complex back-end system featuring content management that will store their clients information and file: blueprints, contracts etc..

I am a bit of a beginner level developer and am curious to how the pros go about the following things:


1) When it comes to login / logout, do you store their login information inside cookies / sessions. Information such as their login name and their authorization level. Is this somehow at all a bad idea, does it leave a future possibility of security issues?

2) Should stylized divs inside of a website be left out of php? As in is it a bad idea to have functions that spit out divs that contain ids or classes that are controlled in css?

I know that when it comes to number 2 I'm just over thinking code as having a "set" style of writing. I understand how a person writes code makes them unique to others. But just wanted to ask your thoughts and comments.
crazycoders
Forum Contributor
Posts: 260
Joined: Tue Oct 28, 2008 7:48 am
Location: Montreal, Qc, Canada

Re: General structuring of security.

Post by crazycoders »

My first suggestion is to never accept any data without checking it. Your code is never secure enough, you could even check it when it gets out of the database but thats a killer.

For sessions, use the session mechanism. I suggest you implement a session highjacking system that compares IP stored in the session vars with ip from requester. IP changes? Drop the session. Else, use whats in the session variables.

For passwords, always keep them hashed and use a salt to make it harder to brute force the value. Read more on hashes on http://www.phptalk.net/, it's a website from kaisengrell that produces excelent articles on security. (Cheers kai)

For the rest, i'll never stress enough... NEVER TRUST user input. Validate type, range, allowed values, escape values when going to database. Using a DB layer is a good thing as they prevent errors happening.
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: General structuring of security.

Post by VladSun »

crazycoders wrote:For sessions, use the session mechanism. I suggest you implement a session highjacking system that compares IP stored in the session vars with ip from requester. IP changes? Drop the session. Else, use whats in the session variables.
What about users that have multiple routes connection (e.g. traffic load balancing)? They will be dropped even if they are legitimate users...
I'd prefer locking sessions to browser name/version, screen resolution, etc.

Also HTTPOnly cookies could be useful against session stealing.
There are 10 types of people in this world, those who understand binary and those who don't
crazycoders
Forum Contributor
Posts: 260
Joined: Tue Oct 28, 2008 7:48 am
Location: Montreal, Qc, Canada

Re: General structuring of security.

Post by crazycoders »

Since when a loadbalanced user will go in and out of their organisation with different ip? I've never heard of that, usually load balancers control only 1 ip at a time and load on different hardward afterwards such as servers, routers, switches and more.

I'm not trying to tell you that you are wrong, but i surprised at this comment... Can anyone confirm what vladsun said?
User avatar
allspiritseve
DevNet Resident
Posts: 1174
Joined: Thu Mar 06, 2008 8:23 am
Location: Ann Arbor, MI (USA)

Re: General structuring of security.

Post by allspiritseve »

crazycoders wrote:I'm not trying to tell you that you are wrong, but i surprised at this comment... Can anyone confirm what vladsun said?
I can't specifically confirm what he said, but I have often read that you can't rely on an IP never changing. The only thing that you can rely on not to change across requests, as far as I know, is the user agent string. I have seen sites that offer the option to use the IP for extra security. That's probably your best bet, and then users whose IPs might be prone to changing can just leave the box unchecked.
crazycoders
Forum Contributor
Posts: 260
Joined: Tue Oct 28, 2008 7:48 am
Location: Montreal, Qc, Canada

Re: General structuring of security.

Post by crazycoders »

Ok cool then i'll update my code, i've always been using that but never got a complaint that a user had redundent hacked sessions. It musnt happen very often that this situation occurs IMO. But thanks...
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: General structuring of security.

Post by VladSun »

crazycoders wrote:Since when a loadbalanced user will go in and out of their organisation with different ip?
http://lartc.org/howto/lartc.rpdb.multiple-links.html

I've implemented it some time ago and there were problems with websites using session/ip locking.
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: General structuring of security.

Post by VladSun »

crazycoders wrote:usually load balancers control only 1 ip at a time and load on different hardward afterwards such as servers, routers, switches and more.
I couldn't understand that one (maybe you meant SNAT?)
There are 10 types of people in this world, those who understand binary and those who don't
crazycoders
Forum Contributor
Posts: 260
Joined: Tue Oct 28, 2008 7:48 am
Location: Montreal, Qc, Canada

Re: General structuring of security.

Post by crazycoders »

I just mean that a load balance goes in front of two similar pieces of hardware... For example in the event of webservers, if i'm not wrong the load balancer is the one being referenced by the DNS server and each server may have their own dns entry. The user doesn't actually realize he's talking to a loadbalanced cluster (2 or more servers)...

I guess this same principle goes for anything such as switches or routers but hey i'm a developper, not a network admin :) My instinct just told me that it didn't make sense for a load balancer to listen to two IPs, it is a balancer, not a router!
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: General structuring of security.

Post by VladSun »

crazycoders wrote:I just mean that a load balance goes in front of two similar pieces of hardware... For example in the event of webservers, if i'm not wrong the load balancer is the one being referenced by the DNS server and each server may have their own dns entry. The user doesn't actually realize he's talking to a loadbalanced cluster (2 or more servers)...
I guess this same principle goes for anything such as switches or routers but hey i'm a developper, not a network admin :) My instinct just told me that it didn't make sense for a load balancer to listen to two IPs, it is a balancer, not a router!
//offtopic

Yes, soon after I posted my previous post I realized what you meant :)

As you noticed, I was referring to user's side point of view - I used "traffic balancing" to stress on it's IP (I mean Internet protocol, not IP address) nature, rather than HTTP. So, I'm referring to user traffic load balancing and you are referring to server traffic load balancing :)
I've set up a router that uses 2 ISPs to Internet - 2 ADSLs from the first one and 1 ADSL from the second. So, imagine a user behind this router trying to access session/IP locked service :) It will appear that on every HTTP request user changes his IP address (one of those three IP addresses), so his session is dropped.
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: General structuring of security.

Post by kaisellgren »

sHobbsWW wrote:1) When it comes to login / logout, do you store their login information inside cookies / sessions.
It is a bad security principle to store usernames or passwords in cookies or sessions.
crazycoders wrote:I suggest you implement a session highjacking system that compares IP stored in the session vars with ip from requester. IP changes? Drop the session. Else, use whats in the session variables.
Just like VladSun said, an exact comparison of IP addresses could perform as a DOS. I feel sad for your AOL customers and for those some Chinese customers plus anyone who might have a too frequently changing IP :P
VladSun wrote:I'd prefer locking sessions to browser name/version, screen resolution, etc.
The purpose of it is to prevent hijacking into the session. Checking for the IP address is "good" due to the fact that you can't spoof an IP. However, an attacker can easily gain the client's browser name, the whole user agent string as well as all those screen resolutions and such. So, bear in mind, that kind of system you have provides only a minimal layer of protection.
crazycoders wrote:For passwords, always keep them hashed and use a salt to make it harder to brute force the value. Read more on hashes on http://www.phptalk.net/, it's a website from kaisengrell that produces excelent articles on security. (Cheers kai)
Thanks for the promote :) and thanks for pronouncing my name "correctly" :)
VladSun wrote:Also HTTPOnly cookies could be useful against session stealing.
HTTPOnly cookies will make sure that the cookie data is never exposed except in the HTTP requests. Therefore, it helps against hijacking attempts, but it is no way a defense.
Post Reply