General structuring of security.
Moderator: General Moderators
General structuring of security.
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.
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.
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.
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.
What about users that have multiple routes connection (e.g. traffic load balancing)? They will be dropped even if they are legitimate users...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.
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.
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?
I'm not trying to tell you that you are wrong, but i surprised at this comment... Can anyone confirm what vladsun said?
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: General structuring of security.
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 wrote:I'm not trying to tell you that you are wrong, but i surprised at this comment... Can anyone confirm what vladsun said?
-
crazycoders
- Forum Contributor
- Posts: 260
- Joined: Tue Oct 28, 2008 7:48 am
- Location: Montreal, Qc, Canada
Re: General structuring of security.
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.
http://lartc.org/howto/lartc.rpdb.multiple-links.htmlcrazycoders wrote:Since when a loadbalanced user will go in and out of their organisation with different ip?
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
Re: General structuring of security.
I couldn't understand that one (maybe you meant SNAT?)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.
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.
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!
I guess this same principle goes for anything such as switches or routers but hey i'm a developper, not a network admin
Re: General structuring of security.
//offtopiccrazycoders 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 adminMy 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!
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
There are 10 types of people in this world, those who understand binary and those who don't
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: General structuring of security.
It is a bad security principle to store usernames or passwords in cookies or sessions.sHobbsWW wrote:1) When it comes to login / logout, do you store their login information inside cookies / sessions.
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 IPcrazycoders 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.
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.VladSun wrote:I'd prefer locking sessions to browser name/version, screen resolution, etc.
Thanks for the promotecrazycoders 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)
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.VladSun wrote:Also HTTPOnly cookies could be useful against session stealing.