Slashdot Mirror
Essential PHP Security
Michael J. Ross writes "Given the remarkable popularity of PHP for developing dynamic Web sites, as well as the ever-increasing need for security on those same sites, one would think that there would be great demand for — and comparable supply of — books that explain how to create secure sites using PHP. However, such is not the case, and even the most extensive general purpose PHP books may only devote a single chapter to this critical topic, if that much. Essential PHP Security, written by PHP expert Chris Shiflett, aims to fill the gap." Read the rest of Michael's review.
Essential PHP Security
author
Chris Shiflett
pages
109
publisher
O'Reilly Media
rating
7
reviewer
Michael J. Ross
ISBN
059600656X
summary
A concise introduction to PHP security principles and practices.
O'Reilly has a Web page for the book, where they offer a sample chapter (Chapter 4: Sessions and Cookies), in PDF format, as well as the book's table of contents, index, errata, and links to the online version of the book, in O'Reilly's Safari service. As of the writing of this review, the confirmed errata is reassuringly sparse, and the unconfirmed errata is nonexistent, which speaks well of the author keeping on top of reader feedback — a worthy quality not shared by all technical writers. The author also has his own Web site dedicated to the book, where he has posted a table of contents, brief reader reviews, and two free chapters in PDF format: Chapters 2 (Forms and URLs) and 4.
In the book's forward, Andi Gutmans briefly explains how increasing Internet usage has resulted in a corresponding increase in security risks, for individuals and businesses operating online. He also notes that most of the security problems related to PHP-based applications, are not the result of weaknesses in the language itself, but rather in the way that developers have used the language in creating those applications. The intent of the book is to bring together the guidelines and lessons learned for writing secure PHP code, into a single volume. He concludes by noting that most of the principles presented in the book apply equally well to other Web development languages.
The bulk of the book's material is organized into seven chapters, focusing on the following topics: forms and URLs, databases and SQL, sessions and cookies, includes, files and commands, authentication and authorization, and shared hosting. These are preceded by an introduction, which oddly is labeled as a chapter. The true chapters are succeeded by three appendices, which cover the topics of configuration directives, functions, and cryptography. A short index rounds out the volume.
In the introduction, Shiflett presents the security-related PHP features, principles, and best practices that he uses as a foundation throughout the rest of the book, when focusing on the specific PHP topics covered by all of the subsequent chapters. The two features of PHP discussed are: register globals, of which most experienced PHP developers know the dangers, and PHP's error reporting capabilities. The four principles espoused by the author for writing secure PHP systems are: safeguard redundancy, minimum privileges, clarity through simplicity, and minimizing data exposure. The heart of the book appears to be his four recommended practices: tempering usability with security, tracking input and output data, filtering all input, and escaping or encoding output to preserve its meaning.
The seven topic chapters that follow the introduction provide fairly terse coverage of how those principles and practices are put to use, when designing and implementing forms, URLs, SQL commands, sessions, cookies, etc. Each subtopic within them is discussed briefly, and illustrated with code snippets.
If anyone is well-suited to writing such a work, it is Chris Shiflett, a well-known authority on PHP security, a respected contributor to the PHP community, founder and spokesman of the PHP Security Consortium, and founder and President of Brain Bulb, a PHP consulting firm.
In light of the author's expertise, one would presume that he would make every effort to write the definitive volume on PHP security — covering every conceivable topic, including: execution of system commands, verification of user IDs and authorization, e-mail spamming via Web forms, (the related topic of) exclusion of bots, and remote procedure calls. However, Essential PHP Security does not discuss those critical matters specifically. Moreover, the topics chosen are discussed in a rather cursory manner. The code samples throughout the book are generally quite minimal, with little to no explanation as to how they work. In addition, many of the techniques presented are but variations on the theme of "filter user input." These weaknesses may be why the book clocks in at only 109 pages. In fact, the seven core chapters comprise only 71 pages, leaving the reader to wonder how PHP security could possibly be adequately plumbed by such a short treatment.
On the other hand, there is something to be said for terse writing, as wizened fans of Kernighan and Richie's C language classic can attest. In agreement would be any developer who has purchased one of the many 700+ page technical tomes that turn out to be padded with excessive margins, poorly-tested code, and pointless appendices lifted from the respective products' documentation. Perhaps Shiflett intended his book to be more a primer on PHP security, rather than a comprehensive coverage — and hence the title of the book. As such, it would primarily be of value to PHP developers unfamiliar with basic security pitfalls and defenses. Regardless, any PHP developer would be wise to begin with this book as a first step towards PHP security mastery, but even wiser if they were to follow it up with more substantial works, as well as keeping current by reading security-focused Web sites and other current publications.
Michael J. Ross is a freelance writer, computer consultant, and the editor of PristinePlanet.com's free newsletter."
You can purchase Essential PHP Security from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
O'Reilly has a Web page for the book, where they offer a sample chapter (Chapter 4: Sessions and Cookies), in PDF format, as well as the book's table of contents, index, errata, and links to the online version of the book, in O'Reilly's Safari service. As of the writing of this review, the confirmed errata is reassuringly sparse, and the unconfirmed errata is nonexistent, which speaks well of the author keeping on top of reader feedback — a worthy quality not shared by all technical writers. The author also has his own Web site dedicated to the book, where he has posted a table of contents, brief reader reviews, and two free chapters in PDF format: Chapters 2 (Forms and URLs) and 4.
In the book's forward, Andi Gutmans briefly explains how increasing Internet usage has resulted in a corresponding increase in security risks, for individuals and businesses operating online. He also notes that most of the security problems related to PHP-based applications, are not the result of weaknesses in the language itself, but rather in the way that developers have used the language in creating those applications. The intent of the book is to bring together the guidelines and lessons learned for writing secure PHP code, into a single volume. He concludes by noting that most of the principles presented in the book apply equally well to other Web development languages.
The bulk of the book's material is organized into seven chapters, focusing on the following topics: forms and URLs, databases and SQL, sessions and cookies, includes, files and commands, authentication and authorization, and shared hosting. These are preceded by an introduction, which oddly is labeled as a chapter. The true chapters are succeeded by three appendices, which cover the topics of configuration directives, functions, and cryptography. A short index rounds out the volume.
In the introduction, Shiflett presents the security-related PHP features, principles, and best practices that he uses as a foundation throughout the rest of the book, when focusing on the specific PHP topics covered by all of the subsequent chapters. The two features of PHP discussed are: register globals, of which most experienced PHP developers know the dangers, and PHP's error reporting capabilities. The four principles espoused by the author for writing secure PHP systems are: safeguard redundancy, minimum privileges, clarity through simplicity, and minimizing data exposure. The heart of the book appears to be his four recommended practices: tempering usability with security, tracking input and output data, filtering all input, and escaping or encoding output to preserve its meaning.
The seven topic chapters that follow the introduction provide fairly terse coverage of how those principles and practices are put to use, when designing and implementing forms, URLs, SQL commands, sessions, cookies, etc. Each subtopic within them is discussed briefly, and illustrated with code snippets.
If anyone is well-suited to writing such a work, it is Chris Shiflett, a well-known authority on PHP security, a respected contributor to the PHP community, founder and spokesman of the PHP Security Consortium, and founder and President of Brain Bulb, a PHP consulting firm.
In light of the author's expertise, one would presume that he would make every effort to write the definitive volume on PHP security — covering every conceivable topic, including: execution of system commands, verification of user IDs and authorization, e-mail spamming via Web forms, (the related topic of) exclusion of bots, and remote procedure calls. However, Essential PHP Security does not discuss those critical matters specifically. Moreover, the topics chosen are discussed in a rather cursory manner. The code samples throughout the book are generally quite minimal, with little to no explanation as to how they work. In addition, many of the techniques presented are but variations on the theme of "filter user input." These weaknesses may be why the book clocks in at only 109 pages. In fact, the seven core chapters comprise only 71 pages, leaving the reader to wonder how PHP security could possibly be adequately plumbed by such a short treatment.
On the other hand, there is something to be said for terse writing, as wizened fans of Kernighan and Richie's C language classic can attest. In agreement would be any developer who has purchased one of the many 700+ page technical tomes that turn out to be padded with excessive margins, poorly-tested code, and pointless appendices lifted from the respective products' documentation. Perhaps Shiflett intended his book to be more a primer on PHP security, rather than a comprehensive coverage — and hence the title of the book. As such, it would primarily be of value to PHP developers unfamiliar with basic security pitfalls and defenses. Regardless, any PHP developer would be wise to begin with this book as a first step towards PHP security mastery, but even wiser if they were to follow it up with more substantial works, as well as keeping current by reading security-focused Web sites and other current publications.
Michael J. Ross is a freelance writer, computer consultant, and the editor of PristinePlanet.com's free newsletter."
You can purchase Essential PHP Security from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
For sessions, I find it more practical to drop the native PHP session system and create my own session system by connecting a user cookie to a database entry. Then you can have better access to the session data and more security, even encrypting the session data inside the database if you want. You can also modify the cookie "key" every so often to hinder someone who may have compromised the user's machine and is looking for session cookies.
Also the advantages of doing this:
1. You are given the option to separate the user sessions database from page navigation/scripts on different servers if you anticipate massive amounts of traffic someday and want a cluster of servers.
2. It is not less efficient than the PHP session system. The native PHP sessions are file-based and also access the disk. With the user account_id as a primary key as a part of their cookie, session data access is very fast, perhaps faster in some cases.
It wouldn't surprise me if that is why the author doesn't talk about PHP sessions much. Extremely high-traffic applications shouldn't use them IMO.
I wanted to reply to one thing, because it's a very valid point:
I deliberately chose to focus this book on the 80%, and I'm actually happy that I did. PHP's reputation suffers because of security concerns, and I'm sure you'll see some of that expressed here. I want PHP developers who read this book to focus on what's most important, and the principles and practices that they learn along the way should prepare them to deal with more minor concerns.
The execution of system commands is covered, but you're right that email injection is missing. HTTP response splitting is another. The second edition might include these, but they really boil down to the same thing as so many other vulnerabilities. If you filter input and escape output, neither are a concern. (After a recent change to header(), HTTP response splitting is no longer a concern, but we'll have to work with older versions of PHP for quite some time.)
Thanks for reading, and I hope it helps!
The real problem with PHP and security is that it's perceived as insecure. There are countless stories of people losing their forums, blogs, websites etc to hackers, defacers and script kiddies.
This book might address how to code in PHP more securely, but that is not going to address the much more perceivable problem of "THIS SITE HAS BEEN H4X0RZED".
What's needed is for some *real* professionals to sit down and go through all the popular open source packages - phpbb, nuke etc - and identify and remove as many problems as possible.
That would obviously be a huge effort, but it's a necessary step imho.
At the least, a solid, secure framework should be released that the softwares could be based on so there is a rigorous, thorough filtering of all input/output, and the onus is partially removed from the people who mean well but write shitty software.
I disagree with the last part of your post the whole everything in this book is under the 'duh' category. myself for example my current job is the first time i've worked with php and also with databases in any substantial way. so describing sql injection and xss attacks doesnt tell me not to trust user input it tells me what type of input to look for as malicious. and yes yes i know you should not try to exclude what a user cant do you should find the minimun subset of input that the user requires to do whatever they are trying to do in that field. more restrictive is always better. But as you should know thats not always an option.
Please do note that Stefan, while occasionally not the most well-spoken advocate is both well-informed, and intelligent. He is an active contributor to the internals code of PHP itself, runs the hardened PHP project, reports vulnerabilities in a wide variety of opensource applications (responsibly!).. the list goes on.
:)
He's also the first man to crack the Xbox using software-only exploits.
He's got a solid set of credentials. I happen to respect both Stefan and Chris, and I've found value in the work of both men. With that said, I find Chris to be more eloquent, and Stefan to be more vigilent and active in fixing problems. (Chris is an educator, Stefan is more of a developer).
Humorously, Chris recently commented in a blog post that he wanted to code more again soon, and Stefan is working on completing his graduate work. Perhaps I'm not the only one thinking those things.
Think of them as Linus Torvalds and Alan Cox - a powerful combination.
GPL'd web-based tradewars themed space game
What about administrator perspective? I administer a LAMP site with lots of daily hammering in the style of "index.php?wget; chmod 755; ./script;blah...". Some of it actually got through, and it launched a DOS attack on some other site. Although server is grsecurityised, apache runs under nobody, there are still problems. How can I contain each virtual host in its own environment, cpu time limiting, stuff like that? Any keywords for google?
The worst of it is that security is non-existent. They use the old '?page=page1' in the url to switch content.
Oh and if I see one more person use PHP native sessions I am going to kill that motherfucker.
Do you have any examples of the alternatives? On the whole these methods seem very straightforward (and I use the first method myself) but I'd very much like to learn alternate, more secure ways of doing this kind of thing, especially as they are the most common ways to access and deliver content.
--
onedotzero
thedigitalfeed.co.uk
Every variable in PHP has a type as well, and using an undeclared variable gives an E_NOTICE level error, PHP recommends running in E_ALL which will cause scripts to output errors when you use uninitialized variables. FYI PHP does check the syntax of your script, if you try to run a script with a parse error it will not run at all. Whether or not a developer chooses to run their applications with E_ALL error reporting is their problem, there's also pros to running an interpreted script over compiled code.