I'm wondering if it would be better for me to code in security as I go, or worry about it when the mass of my website is done.
I personally seem to be more worried about the functionality of the site than the security of it ATM. After I get done though it will be on my agenda. But I'm worried that when I get to securing the site, that I may have to re-code a large sum of it due to the method of my coding. Or does most of securing PHP go with just securing the input and output of the data (ie - MySQL injection and so-forth)?
Opinions?
Basic Security
Moderator: General Moderators
I've done this both ways, in php, and I gotta say its a painfully obvious difference between the two after the fact.
I highly recommend coding for security as you code.
Here is an example..
Lets say you code 2,000 database calls. You don't bother with any escaping while writing them, because hey - security can be added later.
A few months later, the site is compromised by an sql injection (one of the most common forms of web attacks these days), and suddenly you have to *manually* rewrite 2,000 database calls to do escaping. You can't just do a search/replace because the format of escaped database calls requires unique ordering on each.
Thats an obvious one. Then there is input filtering. You could write a unique way to import form input from the dozen+ forms you are writing, or, you could write one input filter, apply it to all forms, and in the process gain consistent form input too.
Now, thats not to say you need fort knox answers day one. For example, its not too bad to use md5 for storing passwords at first, and later transitioning to sha256.
If you have encrypted password storage, filtered input, escaped output, and a consistent approach for each, you will already be better than 90% of the php apps on the net today. (And you'll have saved time coding too).
I highly recommend coding for security as you code.
Here is an example..
Lets say you code 2,000 database calls. You don't bother with any escaping while writing them, because hey - security can be added later.
A few months later, the site is compromised by an sql injection (one of the most common forms of web attacks these days), and suddenly you have to *manually* rewrite 2,000 database calls to do escaping. You can't just do a search/replace because the format of escaped database calls requires unique ordering on each.
Thats an obvious one. Then there is input filtering. You could write a unique way to import form input from the dozen+ forms you are writing, or, you could write one input filter, apply it to all forms, and in the process gain consistent form input too.
Now, thats not to say you need fort knox answers day one. For example, its not too bad to use md5 for storing passwords at first, and later transitioning to sha256.
If you have encrypted password storage, filtered input, escaped output, and a consistent approach for each, you will already be better than 90% of the php apps on the net today. (And you'll have saved time coding too).
-
kaoskorruption
- Forum Commoner
- Posts: 28
- Joined: Tue Jul 18, 2006 2:09 pm
I'd say do it as you go. A lot of times you could easily overlook something when you go back and recode security, so that's a bit risky. Plus if you do run into something that requires you to rethink how you've coded something, you won't have to recode EVERYTHING, just what you've done so far.
It'll probably seem to slow down your progress, but in the end it's better.
It'll probably seem to slow down your progress, but in the end it's better.