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.
Don't use a shared host.
'Nuff said.
"Those who use essential PHP and expect security deserve neither."
(*sniff, sniff*... mmm... do I smell karma roasting?)
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.
WTF? Who modded this down?
While you CAN control whether people can access your website or not, you CANNOT control what number of amateur insecure scripts reside on the same host.
Where I work, we've had a number of problems due to using a shared host for our website. Mass site defacements is one of them.
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
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.
yeah big deal AFAIK slashdot s in perl....
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.
I have a feeling people read the first few words of my post, saw that it looked whiny, and completely missed the joke (therefore labeling it "offtopic", which baffles me). Sad. It wasn't that bad a joke.
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.
Here! This is what I mean! YOU figure out the rest!!
[html]
[head]
[title]
PHP Code sample etc. etc. etc.
He who knows best knows how little he knows. - Thomas Jefferson
http://tomcat.apache.org/
Seriously, I've worked on a whole bunch of PHP sites, and every single one of them had numerous vulnerabilities, primarily SQL injection vulnerabilities. How do you avoid SQL injection attacks? You must use a DB layer that prevents them. PEAR provides protection IF it is used consistently and correctly (sorta like something else that provides protection, maybe the Slashdot crowd doesn't know about it though).
But really, PHP is hostile to the idea of secure code. Every variable can be a string, variables don't need to be declared, a function has no idea what type of input its getting, and most sites don't use proper database layers.
In the Tomcat world, every variable has a type, a variable may not be used before it is declared AND initialized, both these are enforced at COMPILE TIME (something which doesn't exist in PHP), and most sites use reasonable database layers, either PreparedStatements or even better, Hibernate.
I think PHP would be better if sites ran in strict mode (or whatever they call it) but I think few of them do, and to get a legacy codebase to run in strict mode is a major task.
All software should go through a syntax check before it is deployed, a syntax check which checks over every line of code, without waiting for the code to be exercised. That syntax check is often performed by a COMPLIER. Code should be compiled.
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!
#!/usr/bin/perl -w
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.
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.
Out of curiosity, what's wrong with gluing together components? The painting by numbers analogy to programming can work as long as the template and palette is acceptable. Granted, you still have to understand how the systems behaves in its entirety, but you have to in either case.
Do you even lift?
These aren't the 'roids you're looking for.
As an experienced PHP developer who has been involved in many small and large projects, usually involving several other programmers, I can say that the problem with PHP's security is not PHP itself but rather the inability of exploits to punch the programmer in the face.
[alk]
PHP runs on the server, it behaves exactly the same no matter what broweser you use (assuming you don't have any browser checking code). You probably mean a HTML/CSS bug.
Lets see, I work in the security area for my employer and have done web development (not design) work as well. I say that PHP can be used to create rich dynamic sites that are secure. So, now, would you care to back up your accusation of PHP as a programming language being insecure with some real facts?
Sure, there have been holes in countless PHP applications. However, this is not the fault of the language. In fact, almost all of these problems come down to programmers not properly validating user input before processing it. This is true of pretty much all languages. PHP gets a bad name because its easy to learn and people pick it up and write insecure apps with it. Thats like blaming the hammer when the house falls down.
So, I guess this is more generic web development security right? I'd appriciate a book that covered generic web development security, I don't think it has to be language specific. It's all the same principles in most languages. :)
Would you mind accommodating your +1 Insightful and tell the world why?
The same reason that MySQL is crap, because you really, really need stored procedures, views and transactions to keep track of 20.000 messages in 1.500 threads?
The same reason that Java sucks for everything, always and C never does?
The same reason that compiled languages are always better than interpreted ones?
Of course, that reason I'm referring to is arrogance.
Don't get me wrong. I'm actually halfway to a MSc in Computer Science, and frequently have my ego challenged by kids and their flash 'applications', drag'n'drop VB crap and funny web apps that trust me to let it pass critical information in the URL.. These kids tend to think that I'm learning useless crap because they already know. Naturally I'm all warm inside when I get to give their 'application' 500% speedup by adding an index to a table.
But what makes PHP itself unsecure? Yes, PHP wants to be proporly configured. And if you let 50 kids run amok on the same server, sure they'll fuck something up (though never outside of the PHP user).
Now imagine a production webserver, to where only qualified developers has access, and only tested PHP code is put on. Works for me, has for a long time.
Oh, and concluding that all PHP is paint by numbers because it's a scripting language is just ignorant.
#include stdio.h anyone? Not enough of a real man to write your own IO routines, so you're stuck with gluing together libc stuff "in a paint-by-numbers style"? bah..
This isnt Jeopardy. give us an "answer" to the question, or i cant see why this shouldnt be modded as flamebait ;/
Since when does being a Socialist mean 'someone who has a different opinion than me'?
Yuck.
To look at the code I am once again reminded why I always feel sick when someone tells me that I am going to have to work together with a person with a degree. As far as I know they passed with this project yet it is totally and utterly crap. Oh of course it does not work cross-browser. Yes it has many bits of codes wich don't actually doesn't do shit. A 100 line switch statement that always does the same thing for instance but that ain't the worst of it.
The worst of it is that security is non-existent. They use the old '?page=page1' in the url to switch content. I like this approach in itself as it leaves you with only 1 code file wich is accessible from the outside. I also like to make fucking sure that 'page' is filled only with values that I expect. They just insert it in an sql statement and execute it.
Shudder.
Could a book teach guys like this about security? NO.
It is not the first time I see shit like this. To many IT students just are to young and naive to think about security. Or rather to not think about security but just do it. Nobody had to teach me that trusting userinput is bad. I know it is. How?
Well, I don't know I just do. Perhaps it is all the years of low level cracking of games where you alter a string somewhere to give you more health/money whatever. Perhaps it is just being a suspicious bastard.
Security is not a set of easy to follow rules, security is not trusting people.
PHP is a usefull enough language that unfortunally in its basic install comes with some features that can really bite you in the ass. I always disable them on any server I control and then have to spend a lot of time correcting everyone elses code to work on a secured server. Oh and if I see one more person use PHP native sessions I am going to kill that motherfucker. Especially when it is used to store 1 value. Just use a fucking cookie instead of glogging the HD in resource eating insecure way.
ANyway, the review of the book? Well it covers the very basics. If you still need to be told this, just stay away from the web. This is akin to a cooking book telling you not to have a boiling pot of water on the first burners of your stove when a little kid is around. What I read of it all falls into the 'duh' category.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
It's a definitely a web browser problem. Unfortunately, because I'm using PHP and the way my template is laid out, CSS is not working on Safari. Unlike a security problem, this probably won't be fixed soon unless I re-work my template.
http://jigsaw.w3.org/css-validator/validator?uri=h ttp%3A%2F%2Fwww.creimer.ws%2F
( Enter your web site URL into http://jigsaw.w3.org/css-validator/ )
It looks like you have some parse errors in your CSS.
Maybe those are causing Safari to mis-render it ?
Lima India November Uniform X-ray
Save yourself some money by buying the book here: Essential PHP Security. And if you use the "secret" A9.com Instant Reward discount, you can save an extra 1.57%!
So, I guess HTS will have to update some of their hacking challenges.
Disable the PHP easter egg:
0 AA001ACF42
http://www.php.net/?=PHPE9568F36-D428-11d2-A769-0
640YB ought to be enough for anybody.
Why? What should we use?
A clever person solves a problem. A wise person avoids it. -- Einstein
That's no surprise... I personally wouldn't touch code written by someone just out of school without (a) extra money, and (b) the option to scrap and rewrite it.
Like any other job, it takes a while to actually get good. It's not unique to the computer industry.
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.
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
Mod down please
Judging from his comment (which was a bit hard to read at times), he doesn't mind the ?page=page1 technique. What he objects to is then doing something like "SELECT * FROM Pages WHERE $_REQUEST['QUERY_STRING']". Which is perfectly understandable.
As for native sessions, I don't know why he's so vehement against them, but implementing session stuff yourself isn't to hard. When a user logs in, generate a unique ID, give it to them in a cookie and store it in a database table. At the top of every page, have a bit of code that checks for the cookie and, if it exists, look it up in the database. Add a time field, a user field, and a data field with a serialized PHP array and you've pretty much got all the stuff you need to do whatever the native system does.
I'm not sure what advantage the homebrew type system has it's database based (may be more efficient I/O wise, but that's only going to be an issue on sites expecting a very large audience) and you can encrypt the session data stored on disc (a bit of overkill IMO, especially if you're on a dedicated server - I never store anything important in session vars anyway)
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
FYI to other readers of parent comment, that does nothing to help secure PHP or your PHP code. It won't even run my sample application below:
make your CSS valid and try again
You're mixing up replies.
The reply by Chris Shiflett you point to is in response to a much earlier comment by Stefan Esser. It is not a reply to the comments Stefan made with regards to his book.
paul reinheimer
So Safari is choking on the CSS file even though the elements causing a parse error are not being used? Is Safari that sensitive to the CSS file?
What happens when someone alters the url by hand, to say something like ?page=fuckofyoufuckingfucker.
Well nothing, except it won't load a page (probably I don't know what you called your pages) but what if they actually make it more complex and insert a complete sql statement with escape codes? You see the problem is that you can do that, you can insert one sql statement into another. I am to lazy to search for an example but it is a widely used attack.
What should you do instead? Well at least "select * from pages where page = 'Mysql_Escape_String($page)'" (not proper PHP) wich escapes any escape codes making it a simple string with no harmfull side effects.
Personally I like to go further. I use a regex to make sure it only contains those characters I expect and in the case of pages where I know the range of options I check wether it is a legal page name. For instance not to long or to short. Just to be sure. Remember it is okay to be paranoid on the web where everyone really is out to get you.
As for PHP native sessions, the other post again answers it very accurate but not why I dislike them. A it is not enabled on all servers. This is bad because PHP code should be portable. B it is blocking, only 1 thread can work on a sessions data at a time. This is bad on high performance servers. C. it uses the filesystem for something wich it is not meant to do. D. it is a bitch to admin. E. the alternatives are just so much better.
What is the alternative. A simple database (whatever form you like) with a cookie.
So the first method is perfectly fine just CHECK the content of $_GET['page'] before you use it. The second method just doesn't scale well. It is overkill for simple stuff where you only need a user side stored cookie and it is to simple and inefficient for more complex needs.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Rule #3: User Contributed Notes are Wrong and Probably Dangerous.
http://outcampaign.org/
I bet if you posted the url to your server to slashdot as a response, you'd find out how secure it was...
I'd like to invite you and encourage you to master the ten domains of the Common Body of Knowledge (www.isc2.org) and to take the CISSP exam. Obviously you have a lot to contribute and are eager to do so. One of the major benefits of the CISSP exam is that it shows that you're well-rounded and can converse, at least on a basic level, about all parts of security. The challenge faced by all security professionals is to be comprehensive, which involves, among other things, realizing the limitations of specific layers and approaches. A cursory look through your book seems to indicate a lack of fundamental grasp of access control models, something that the PHP community as a whole can use some guidance on. Every one of these domains relates to "PHP Security" on some level. Here's the CBK list:
Access Control Systems and Methodology
Applications and Systems Development Security
Business Continuity Planning (BCP) and Disaster Recovery Planning (DRP)
Cryptography
Law, Investigation and Ethics
Operations Security
Physical Security
Security Architecture and Models
Security Management Practices
Telecommunications and Network Security
I'm confident that the time you spend working toward the CISSP credential will be genuinely useful to you in your consulting practice, as it has been to me, especially insofar as it involves information systems security.
Regards,
MKC, CISSP
PHP Consulting
http://tinyurl.com/4ny52
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.
One of the things I liked about this book is that you don't need to be sat next to your PC to read it. Though it has many nice and clear code examples, it's mainly about principles and theory. Excellent to have on the bedside table.
It isn't a very thick book, but is written in a clear and accessible style, and I found myself going 'aha' all the way through. I read it quickly but have a feeling that I'll return to it often until all those best practices are memorised and I'm 'doing' them.
What is most useful about this book is the aggregation in one place of descriptions of all of these security attacks and vulnerabilities in PHP code, along with suggestions on dealing with them.
The only specific attack missing which I would like to have seen information about is email spamming through website forms. However the general principles described in the book will help prevent these attacks as well.
This book will definitely be a long-term desktop reference for me and mandatory reading for all the PHP developers in my work place. I would definitely reccomend this book to aspiring PHP developers and think it would also benefit some of the more experienced folks out there.
--
Webmaster of Spy
Don't discount someone right out of school. A person with a two-year technical degree may not understand the concepts of security; but a person with a masters in computer science or engineering most likely would. It doesn't take an engineer to program PHP, but it does take some common programming knowledge to create well-structured applications.
... other fine books like the Amish Phone Book or List of Human Rights in Comunist China
Laugh, it's funny....
please excuse my apathy
That may or may not be true. A CS student may have a solid foundation in security, but they might have no foundation at all in security. If your doing "pure" CS such as queue theory, or algorithm analysis, then security, let alone things like exception handling and even logging, are irrelevent. One could argue that the two year diploma types know only about all that irrelevent fluff, except in the real world that irrelevent fluff takes up 80% of the project. Consider the distinction between physics and engineering; a scientist may give you an answer to the Nth decimal place (ignoring friction), but an engineer will give you one rounded up to the next highest existing part, after a 50% safety factor. Both answers are right, but only one is right in the real world.
The code does something, mainly, echoing 'your name is:... and then not displaying the return value to the browser.
There are 1.1... kinds of people.
Unfortunately you are right it is one a case to case basis. One student may have enrolled in a security course while another completely skipped over it. Security really should be a requirement for all CSE and optional for CS even though the degrees (these days) seem interchangeable.
I'm sorry - with all the PHP holes over the last year - PHP and Security seems like a contradiction in terms!
Horns are really just a broken halo.
"The mistakes in the book don't just disappear because Stefan wasn't polite when he pointed them out."
I totally agree with this statement, in principle, but I've looked at the errata. Unless I'm missing something, there are no real mistakes to speak of. As the reviewer says, "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."
I also just read that blog entry - what a waste of time.
Stefan Esser is clearly some kid who's jealous of the experts and their "fame" or whatever. You see this all the time in open source. Nothing new here, but it's still annoying.
If he went through the entire book, and all he can come up with is this "mistake" that is based on his own assumptions (which are wrong), it speaks highly of the book. These are clearly arbitrary paths, and although I haven't read the book, I'm sure it has nothing to do with what's being discussed. Try again, kid.
Plus, you can tell he struggled to even find his own point:
"However when you look at the example above and have a clue about file permissions you should start to laugh, because it should not work. Then you try it and wonder that it actually works."
Can't you just see this kid? "Oh, I've got them this time! Oh wait, it actually works. Awww man." Give me a break.
The other thing you pointed to is yet another example of this:
"I suggest that you also read Chris Shiflett's comments about this article in his blog. It is an entertaining read, because he says that I haven't understood the CSRF problem, and blames me for not initialising the variables in my example. Which is kinda strange, because the example was copied one to one from his security guide and therefore any error in it, is his fault."
Seriously, if this kid doesn't understand that session variables persist across pages (and therefore examples), he's not worth listening to. He assumes (wrongly, again) that you shouldn't initialize session variables, and based on this assumption, he thinks he's found an error. Then he thinks he can weasel his way out. I can't believe anyone takes this guy seriously. My freshmen students could code circles around this kid.
The author should just ignore punks like this. Hopefully he already is.
I know it's been ages since you posted that and you're probably not going to see this, but I can't let a comment like that get by without telling you how wrong you are.
Let's take an overly extreme example. Some people need to walk over a tightrope between some mountains. Sure, it's possible to cross. So why are all those people falling and dying? It can't be the fault of the language; it must be the fault of the people for falling off. Those people need to learn not to fall off and die! There's no need to make the tightrope wider or stronger, add safety nets so people don't die, or add guiding ropes for people to hold on to. No, it's not the fault of the language.
PHP the language is very much at fault. Take register_globals. How can the user be at fault when PHP encouraged (thankfully it encourages it no more) insecure features like this? Take the lack of taint checking. No-one was really going to use it anyway, were they?
Oh, and if I build a house using a hammer that breaks nails, it sure as hell is the hammer's fault.