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.
this is the first time i've already owned a book before a slashdot review of it came up. It gives me that warm and fuzzy feeling inside.
I think the reviewer hit just about everything important about this book. The only thing I would add is I didnt feel the discussion about sessions was in depth enough. Nothing about how session data is actually stored on the server or how to secure it.
other than that great book, because it is so short everything is easy to find.
What are the credentials of Chris Shiflett? He's widely touted as a "PHP security expert", but Stefan Esser has a beef with him, and claims that this book contains serious flaws and misunderstandings.
I understand that people in the public eye like book authors are vulnerable to any crank that comes their way, but the problems that Stefan has highlighted do seem to point to a severe credibility problem, and Stefan, while prone to flaming, certainly knows what he is talking about.
In the interests of fairness, you should also read Chris Shiflett's response.
Bogtha Bogtha Bogtha
I have read this book in the past month, and it is very good at explaining PHP security from a very general perspective. It talks about encryption theory, SQL injection in genereal, filesystem permissions, etc. Very good read/reference for web developers who aren't as familiar with system/network security.
If you're looking for a system-wide approach to PHP Security, one that covers everything from shell commands and service tuning up through application-level security policy implementation, you should check out Apress' Pro PHP Security.
Cheers!
The problem is Not PHP Security, but general Coding practice. If you code bad, you will do it in any language. There are lots of thumb up rules (like defensive programming, checking value input, never trusting anyone, etc...) - know these, and you will not need to read books like these.
A good code on that (and a lot more) probably would be Code Complete, and Code Complete2
If you want to save some money and also support the author (me), please use this link:
:-)
http://phpsecurity.org/buy
You get the book for less than $20.
You can use the PHP native session support and write your own backend for it, thus giving you the advantage of PHP handling the cookies and rewriting the URLs, but the ability to put it in a database.
If corporations are people, aren't stockholders guilty of slavery?
You're welcome to read the reviews and the (very thorough) errata yourself:
:-)
http://phpsecurity.org/reviews
http://phpsecurity.org/errata
You'll be hard-pressed to find anything beyond simple typos and unclear sentences, I think, and the reviews have been very positive.
Do you even lift?
These aren't the 'roids you're looking for.
Virtual Private Servers are probably the answer for small budget coders. You can found pretty good VPS services at $50 a month.
Instant Karma's gonna get you, Gonna knock you right on the head (John Lennon, 1970)
Great, that's a good general security tip, but what does that have to do with how secure your scripts are???
The book is about PHP script security. You could have the most secure server in the world but if your scripts allow unfiltered user input then you're still screwed. NO amount of server securitty will help that.
The last I heard on this subject from the phpBB guys is that they're doing precisely this sort of code audit to make sure the new version of the software isn't plagued by so many vulnerabilities as the 2.0 line has been... but only time will tell whether it's manageable.
Trouble with this sort of job is that the real professionals also happen to charge a fortune for their services, and that's something that most open-source projects can't afford.
The perception that PHP is insecure is based on the fact that it was in the past incredibly insecure, not just because of bad programmers, but by design as a language/deployment environment. Perhaps it was too long ago for you top recall, but it used to be that register_globals was on by default. register_globals was inherently insecure, and including it in the language at all was a huge security compromise, and pathetically enough since there are still PHP packages out there that depend on it, it has not been removed from PHP.
m lm lm lv =3&i=50#widely4v =3&i=23#other1v =3&i=28#widely4v =3&i=48#exploit1
Also letting include() take a URL is batshit crazy. While handy (like most security compromises), it means that if anyone can figure out a way to sneak a string in to that include call, then they can import any malicious code they want. register_globals was often a handy way to do that in the past...
There are a few other things that I think are a sign of poor security design, but most would likely just cause language wars, so I will leave it to those above to illustrate that PHP, especially in its earlier incarnations had a poor design with respect to security.
PHP itself has had its fair share of security vulns, for instance:
http://www.hardened-php.net/advisory_202005.79.ht
http://www.hardened-php.net/advisory_152005.67.ht
http://www.hardened-php.net/advisory_142005.66.ht
http://www.sans.org/newsletters/risk/display.php?
http://www.sans.org/newsletters/risk/display.php?
http://www.sans.org/newsletters/risk/display.php?
http://www.sans.org/newsletters/risk/display.php?
There are more, but I am too lazy to find a more complete list, and that is enough to illustrate the point.
So while it's true that there are a lot of bad security habits that many PHP programmers have used, PHP's bad reputation is something they have earned all by themselves.
Hyperbole is the worst thing ever.
I can't but get a little sick when I see a whole book written on something so incredibly simple.
/bin/sh -x /tmp/mybot.sh just fine on most linux distros even if /tmp is noexec. So dammit go toss the 3 lines of code in /bin/sh that keps uid/gid 99 from doing that.
/dev ... make sure you took ALL the tools away that helps people get bad code onto your box in the first place. /dev/tcp is just as lethal as leaving wget available on a fedora / RHEL installation. Use mknod and make them safe. Same with /dev/udp .. remake them.
... stop making instant setup hosting accounts. Use fraud screening services. Remember a security hole is only a problem if you sell space to someone who's intention is to exploit it.
:) But I do things a bit differently than most. There's things you (yourself) can do if your stuck on shared hosting to ensure and nudge your host into securing their boxes.
The reason you see PHP being exploited is not the security of the host OS, not the security of PHP (well almost never) , its the lack of knowledge by the person owning the computer hosting the sites and companies like The Planet who hand them out to literally anyone with a Paypal account or credit card number.
I can in 20 minutes show any experienced Linux system administrator how to run PHP completely wide open as far as functionality is concerned on a shared hosting environment and how to do it relatively safely.
Your average web hosting company is a business person who has money to buy servers with idiot proof (nearly) control panels such as C-Panel / WHM.
They're also likely to come with RHEL, Centos 3 or 4 or Fedora. Very rarely do I see a Debian server used in a shared hosting situation (That should also tell you something).
These boxes are not secure yet they go immediately into production.
SO! To anyone who cares, (and reads this far) here is Tinkertim's checklist :
1 - Egress filtering (firewall the damn box),
2 - Get rid of that fat, bloated leaky modular kernel. Monolithic kernels are too easy to build not to do it. Don't forget to keep iptables, test with your firewall when done.
3 - Seek and loop world writeable directories, or mount them as noexec. Even doing that is not going to save you all of your trouble. As nobody I can run
4 - Don't even THINK about using apache/proxy on a shared hosting setup. Thats just incredibly stupid and self destructive.
5 - Look around in
6 - Get rid of what you don't need. Rename what you do and use scripts to help govern them. Lynx / wget / POST / GET (and everything else RHEL/Centos comes with) can be used to do dastardly things. Take advantage of user / group ownership that is found in Unix.
7 - lsof is your friend. Write a script to check for open accepting inet sockets that don't belong.
8 - (finally) VERIFY YOUR ORDERS
Web hosts are the scurge of the planet. I know , I am one
I may just re-post later or re submit with that list too. I'm off the soap box now. My point is this. We (shared web hosts) made this problem. We have a responsibility to admit it and stop it. I'll work on some checklists and scripts to do it for the lazy bastards and GPL them. Tired of people getting rich writing books making hype about what (should be) a very trivial issue.
The author specifically deals with this issue in Chapter 8.