Page 1 of 1
General structuring of security.
Posted: Sat Mar 14, 2009 2:59 pm
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.
Re: General structuring of security.
Posted: Sat Mar 14, 2009 6:10 pm
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.
Re: General structuring of security.
Posted: Sun Mar 15, 2009 5:12 am
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.
Re: General structuring of security.
Posted: Sun Mar 15, 2009 9:02 pm
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?
Re: General structuring of security.
Posted: Sun Mar 15, 2009 10:00 pm
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.
Re: General structuring of security.
Posted: Mon Mar 16, 2009 6:41 am
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...
Re: General structuring of security.
Posted: Mon Mar 16, 2009 6:52 am
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.
Re: General structuring of security.
Posted: Mon Mar 16, 2009 6:55 am
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?)
Re: General structuring of security.
Posted: Mon Mar 16, 2009 9:19 am
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!
Re: General structuring of security.
Posted: Mon Mar 16, 2009 1:30 pm
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.
Re: General structuring of security.
Posted: Sun Mar 29, 2009 11:37 am
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
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.