Web application security is not an issue you can deal with once and forget about. Unfortunately, in order to keep your application secure, you will have to revisit it on a fairly regular basis as new security threats occur. Knowing this, there are some habits you can cultivate to make your code easier to secure, even six months or a year after you finish the application.
One of the best ways to ensure that your application starts out secure and remains that way is to keep a tight rein on new features. First, make a list of the features that are absolutely essential to the application. Next, list any features that you intend to add later. Set the list aside for a day or a week, if you have time. That way you can add or subtract from the list over a period of time. This allows you to be fairly certain that you haven’t missed anything. It also lets you look objectively at some of the extras that you may have added in a burst of inspiration; you may decide they aren’t really all that crucial once the excitement has died down.
After a few days, you can begin to design your application around the final feature list. It’s always best to plan and design for the complete feature list at the beginning, rather than trying to crowd in extra features later. Even if you don’t plan to implement the entire list all at once, you can still leave room in the application if you know you’ll be adding things later. However, once you’ve started to write code, resist the temptation to sneak in just one more thing! Go back and reread Chapter 16, “Plan A: Designing a Secure Application from the Beginning,” for a more detailed, step-by-step breakdown of this process.
What’s so bad about adding extra features to an application? First, when you squeeze in extra code, you risk breaking something unintentionally. Of course, if you’ve written a comprehensive test suite, as we discuss in Chapter 14, “Introduction to Automated Testing,” you’ll know fairly quickly if you’ve broken something. Unfortunately, it’s also very difficult and time-consuming to write tests for every possible breakage point, so there is still the potential that a bug will slip through the cracks.
Second, when you begin slipping things into an established code base, you begin to create spaghetti code. Spaghetti code is a term that refers to any code base that is harder to follow than a pile of hot spaghetti noodles (sauce is optional). “So what?” you’re thinking—we can hear you!—“I know my own code!” Sure, you know your own code now … but how good is your memory? Are you going to remember all those twists and turns when you haven’t seen the code in six months?
Finally, keep in mind that there will always be newer, faster, greater technology. For programmers, it’s tempting to add in the latest and greatest new function or feature the day it’s released. And like most temptations, it’s a bad idea. New technologies need several months of experimentation and good old-fashioned pounding before they’re really ready for production use. So unless you don’t mind turning your users into guinea pigs, don’t add new features and technologies just because they’re there. Odds are your users won’t be all that impressed by the latest and greatest technology anyway.
One of the problems with updating, maintaining, and writing bug fixes for an application of more than a few hundred lines of code is remembering what it is that the existing code base is doing, and what your intentions for the application originally were. Throw in a couple of extra features during the coding process, and it could take you hours just to figure out where to start looking for bugs.
The solution to this unintentional obfuscation is self-documenting code. Writing self-documenting code does not imply that you can skip the precoding design process, or that you don’t have to write end-user documentation. Actually, it doesn’t even excuse you from commenting your code when necessary and helpful. So what is self-documenting code, if not a way to avoid writing documentation?
Writing self-documenting code is all about consistency and accurate naming. When you’re coding your application, you should write the code in a consistent style. For example, all of the code samples in this book have used the following style for if() statements:
if (x == y) {
// Do something here
}
This is really a matter of habit and personal preference. The code samples would work perfectly well if they were written like this:
if (x == y)
{
// Do something here
}
If you were to mix both conventions in your code, you (or another programmer looking at your code) would still be able to figure out what was going on, but having to mentally switch between conventions makes the code more difficult to read. The coding style gets in the way of someone trying to get at the meaning behind the code. You don’t necessarily have to write out your coding conventions, especially if you’re the only one working with the code, but you should get into the habit of doing things the same way every time. Not only will your code be easier to read, but it will be easier to write as well.
Consistency in naming is also crucial to writing self-documenting, easy-to-read code. You could name your variables a, b, and c, pulling the next letter off the alphabet every time you needed a new variable. You could also beat your head into a brick wall. It’s hard to tell which would be more painful—the brick wall or trying to maintain code with such meaningless variable names! The same goes for naming functions.
Since variables represent things, it’s common to use nouns to name them. currentDate, username, and dateStamp are all good, noun-based variable names. They tell you exactly what the variable holds. Functions do something, so it makes sense to use verbs to name them, such as getNextRecord, encryptPassword, or updateUserRecord. If you find that you’re having trouble naming your variables or functions using this method, take another look at the code. You may be trying to put too much meaning on one variable, or too much processing into a single function. You’re much better off breaking up a function into several smaller ones, with one single task per function, as we’ve done in the code samples in this book.
Writing secure code doesn’t imply that you have to write every line of it from scratch, using nothing but the core PHP interpreter. In some cases, the less code you write yourself, the more secure your finished application will be. Once you have a solid understanding of the issues surrounding user authentication, for example, you may be better off using an off-the-shelf code library rather than writing the entire authentication system yourself. For one thing, the person who wrote the library put as much time and energy into that one small piece of code as you put into your entire application. That much focused attention means that odds are all the little details of the library have been examined and most of the bugs avoided. Also, since most of the libraries available for PHP are released under one of the open-source licenses, they’ve been under constant peer review since the day they were released. (We’ll talk more about peer review in the next section.)
Take the user authentication system, for example. If you write it from scratch, you may be the only person who ever looks at that code. If you use a set of library functions to assemble a working authentication system, many other programmers have used those same library functions as well. If the functions don’t work properly or introduce security holes, odds are someone else has already found the problem and complained to the developer—or fixed the problem and submitted a patch for the library code. The more eyes there have been on a given piece of code, the more confident you can be that the code is solid and secure.
That being said, don’t use off-the-shelf libraries as a crutch. You should know exactly what’s happening within your application, and how each system works, before you hand off any of that functionality to a library function. Why bother learning the intricacies of encryption schemes, when you can just plug in a library function that does it all for you? First of all, you need to understand the concepts so you can choose the correct function for your application. Second, part of the implied responsibility of using open-source code is that you will submit any bugs you find and code fixes when you can. If you don’t really understand how a system is supposed to work, you won’t see the bugs until something catastrophic happens, and even then you won’t have a clue how to fix them.
An integrated development environment, or IDE, is another tool that makes writing solid code easier. Most IDEs include tools that don’t come bundled with PHP, such as a debugger and the ability to step through the code. It’s not absolutely essential to write PHP in an IDE; we’ve written commercial applications in nothing but a simple text editor, when the corporate environment dictated which tools we had available. It’s just a whole lot faster and easier to use the tools bundled into an IDE if you have the option.
As with any tool, there is a learning curve associated with any IDE, so it makes sense to try a few to see which interface is most intuitive for you. Most IDEs have the same basic features, so it really is all about the interface and the cost. We’ve listed a few good IDEs in the Appendix. Start with the demo versions and see which one best matches your budget and the way you write code.
The final bit of advice we’d like to offer is to find a good peer reviewer. Ideally, this should be someone who knows how to read and write code as well as or better than you do and who can offer suggestions and criticisms constructively. There are two types of peer reviewers to avoid at all costs—they are worse than no reviewer at all:
• The Yes Man—a friend who will tell you your code is great no matter what condition it’s in. Someone who doesn’t know PHP all that well also falls into this category. If such people don’t know the language or aren’t very experienced programmers, they will be unlikely to spot and point out the errors in your code.
• The Bully—someone who will rip apart every line of your code and complain that you didn’t use the most obscure functions available (when more common ones work perfectly well), just to make sure you understand that he or she is more of a PHP guru than you are. Don’t waste your time.
The best peer reviewer will help you become a better programmer, just as your comments on others’ code will help them improve their programming habits.
Code reviews aren’t just the domain of big corporate programming departments. They are an incredibly useful exercise for any coding project of more than a few hundred lines. You are too close to your own code to really see the potential for errors and insecurities. No matter how diligent you are, something will escape your notice. But hand that same code to someone who has never seen it before, and the problems will stand out clearly.
Ideally, you shouldn’t have to tell a peer reviewer what a certain segment of code is supposed to do—because you’ve written consistent, self-documenting, well-commented code, right? If your reviewer comes back to you in under an hour saying, “Sorry, I just can’t follow this. What’s that function supposed to be doing, anyway?” it’s probably not a lack of intelligence on the part of the reviewer. Go back and take a hard look at the code. Is it as clear as it could be, or have you taken a lot of shortcuts that work, but that obfuscate the meaning of the code to a human reader?
Becoming a better programmer is a process. You’ll improve your programming skills and habits every time you work on a new piece of code. By following these suggestions, you’ll have a head start on becoming the type of programmer who writes clear, effective code that doesn’t induce migraine headaches at the very thought of updating or maintaining it.