Securing PHP

An Open Suggestion to OWASP (or How to Bridge the Gap)

In a previous post I made a call out to the security community (mostly the OWASP group) about some of the lacking involvement in the world of PHP. There were some good comments on the post, and there’s some I’d like to give my own feedback on to maybe explain things rolling around in my head even better.

First off, there was the comment I knew was coming even before I hit the “Publish” button. In this comment Ryan turns some of my comments back around and wonders if the lack of PHP involvement by OWASP is more of a reflection of how much involvement the PHP community has with it. While I agree with this to a point, I’d also suggest that it has to be a two way street when it comes to communicating effectively with developers. An organization that wants to provide information about how to secure applications should be involved with the groups it’s trying to help. Likewise, that group can’t effectively provide the information developers are looking for without guidance from those developers themselves. After all, what good would a guide about not using “safe_mode” be to people using PHP 5.4.0+? More on this topic later…

Another comment brought up a few more specific issues around the tooling that the OWASP group provides, suggesting that it’s less attuned to what PHP developers actually need and is more of a direct port of an existing Java or .NET version of a similar project. The influence is definitely there and it makes me wonder how much PHP experience the author had in the language (not just writing PHP but actually knowing PHP…there’s a difference). The PHP community is a rapidly evolving one by the nature of the language and if you’re not keeping up with trends, advancements in the language or where the state of security in the language is at, your tool will be deprecated before it even hits 1.0.

Finally there’s the comment I hoped I’d get from a representative of the OWASP group themselves, a member of the board no less, Michael Coates. I’m glad that the response was one of openness and a desire to make things better. It’s easy to see how, especially in a community that tends to err on the side of keeping things under a rock, that the group I was mentioning was paying attention. Michael’s comment asks for direct suggestions about things that can be done to help the situation I put out there. With the somewhat wide chasm between the two words, I can see a lot of room for improvement, but I think there’s one suggestion I’d make to Michael and the rest of the OWASP folks (including those already involved in PHP-related projects under the organization):

Get involved.

Sounds simple, right? Honestly, I think the biggest problem here is the communication between the two groups. I feel like the OWASP group, while having good intentions, sometimes comes across as more of a “we’re security professionals and we know how to write the tools correctly” kind of mentality. As a result, you end up with projects like the PHP ESAPI  or the work being done on the PHP Security Project that’s recreating tools that already exist in the PHP ecosystem for the sake of having a “one tool to rule them all.” Essentially what it ends up being is a mish-mash of tools that a developer could use to secure their applications. What it doesn’t end up being is a useful tool that PHP developers want to use to secure their applications.

The goals of the project are admirable, but their time could be much better spent encouraging the package mentality the PHP community has evolved over the past few years and enhance the security features of pre-existing and well-tested/vetted libraries already in wide-spread use. Let me illustrate with a list of things the owasp/phpsec project includes that already have packages that solve the problem:

– a database abstraction layer (not an ORM or even ActiveRecord, just a layer on top of PDO)

– a “download manager” that seems to not do much more than stream a file to the given output

– an encryption class that does some crazy stuff to encrypt a string

– A HTTP request class that most frameworks have anyway (or even HttpFoundation)

– A Logging class that can output to a database, file, mail or syslog (or just use Monolog)

– A cryptographically secure random number generator (how about RandomLib instead)

– A sort of “security scanner” that looks for a limited set of keywords (try Parse instead)

– A session handler that forces database use and doesn’t plug into the SessionHandler interface

There’s a lot of other features in the tool that could go on this list too, but it feels like there’s just a big disconnect here between the goals of the project to provide a useful library PHP developers will want to use. While I get the whole idea that other packages are “written by developers and not security experts”, there’s a lot of things they’re reproducing here that have already been solved.

So, my suggestion to the group working on the PHP Security Project is this – stop with the Not Invented Here development and get involved in the work that’s already been done to make these “decoupled libraries” people are actually using. Help show the PHP development community that you’re interested in being a guiding force for security concepts and techniques rather than building something in a silo most developers would never even use.

The PHP community gets better tools and OWASP gets known in the community as an organization that cares about keeping PHP safe. Seems to me like this is a win/win situation for both sides.

The Usual Suspects…now with XSS!

I’ve just pushed the latest update of the most recent book in the Securing PHP ebook series – The Usual Suspects – and included an entire chapter covering cross-site scripting:

Next we come to something that’s probably a bit more widely known but often misunderstood, especially when it comes to the power that it offers to the attacker. Part of the confusion comes from the name of the attack. When you think about the attack method an XSS vulnerabilities allows, the only thing “cross site” about it is that it can possibly come in as a link from another site. Other than that, a cross-site scripting vulnerability can be more closely associated with injection. In fact, the main reason a site might have a cross-site scripting issue is because of improper output escaping.

This new chapter has loads of information about the different types of XSS issues, the different contexts it can happen in and plenty of code and configuration examples of how to prevent them. If you haven’t picked up a copy of it yet, there’s no time like the present!

Don’t forget about the first book in the Securing PHP series too! Core Concepts is a great introduction to security terminology, methods and principles that can help you lay a good foundation for more secure applications.

Securing PHP: The Usual Suspects Released

I’m happy to announce that the next book in the popular “Securing PHP” ebook series has been released – “Securing PHP: The Usual Suspects”!

You are the developer, you hold the power in your hands to protect your users and their information. They trust you with it, shouldn’t you do everything you can to keep that trust?

Let me guide you through a look at some of the most common issues with web applications and suggest ways to correct them along the way. Even if you’re a novice to security or to PHP, this book can help you get started down a more secure path. The OWASP Top 10 is a great guide to the common vulnerabilities, but it doesn’t provide the useful, concrete examples you need to be a more effective and secure developer. I’ll provide this foundation on topics like:

  • Cross-site scripting, what it is and how to prevent it
  • Poor authentication and authorization practices
  • Preventing several types of injection
  • Auditing potentially vulnerable components
  • Protecting your users’ sensitive data

This book will help you sleep better at night knowing you’ve put in the time and work to protect your applications and the users that trust it.

You can grab a copy of it over on LeanPub right now for just $19.99 USD. The book is on an incremental rollout schedule, so right now just the first two chapters are included. The first covers various injection types (including SQL injection, one of the most widespread) and how to prevent them in your applications. The second chapter covers some of the common problems around authentication and authorization.

Securing PHP: Core Concepts Released!

I’m happy to announce that my latest labor of (PHP) love has officially been released – the Securing PHP: Core Concepts ebook is now available over on LeanPub. It’s been a project I’ve been tossing around for a while now and, with encouragement from the stories of others, finally made it a priority.

I’m really happy with how the book turned out – here’s a summary of the book in case you hadn’t see it yet:

Security is a big topic. I mean *really* big. If you break it down into little chunks, there’s lots of important bits to pay attention to but it all really starts with the application. Without good secure coding practices, your application could be doomed from the start. We as PHP developers have had trouble in the past integrating these practices into our day to day development. This book walks you through some of the most common terms and practices, giving you a better picture of the whole of application security.

I’ve just put it on sale this morning and it’s already getting a great reception. You can find out more about the book and pick up a copy on the Securing PHP: Core Concepts ebook page on LeanPub.

Thanks and happy reading!