security

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.

Advertisement

OWASP, A PHP Ostrich?

As a member of the PHP community for the last 10+ years, I’ve seen the topic of security come and go. PHP’s always had a bad reputation for being an insecure language and, honestly, that’s a valid point to make. It’s PHP’s own low barrier for entry and lack of a cohesive plan that’s made it such an “interesting” language to use over the years. I’ve also had a foot in the security community for the past few years and I’ve seen an interesting disconnect between it and the world of PHP.

I constantly see articles talking about how insecure PHP is compared to other languages and how no one should be using PHP if they’re concerned about protecting their users and data. As such, PHP seems to have been mostly dismissed by the security community as a sort of “toy language” that’s not suitable for the enterprise like Java or .NET are. I can’t tell you how many companies I’ve seen looking for people to fill application security analyst roles that only want Java or .NET experience. PHP makes up such a small part of their market that they don’t even bother looking. This is very surprising considering how much of the web is running on PHP (based on statistics, take that how you’d like).

This focus on the .NET and Java worlds has bled through to other parts of the security community too. Take the Open Web Application Security Project (OWASP) group as an example. If you’re a member (I am) or even just a casual reader of the information they have to offer, there’s a very clear bias towards these two languages. There’s been a few initiatives they’ve started over the years to try to enhance the PHP-related information they provide, but sadly a good bit of it is falling out of date and isn’t as useful as it once was. Things like the PHP Security Cheat Sheet  have had a few additions and wording changes, but even then there’s quite a bit of information that’s just missing from its content.

There’s something that concerns me more than just incomplete content on a wiki page, though. I was looking through some of the PHP security libraries that are being worked on by OWASP members (such as phpsec) and noticed something interesting. There is a lot of “Not Invented Here” going on there. Sure, PHP developers are guilty of this too, but it seems this hints at a larger point: is the OWASP group doing more harm than good by not embracing some of the well-known security tools that exist outside of their own organization? In fact, the only PHP library the OWASP group has on Packagist is their RBAC (role-based access control) tool that seems to ignore standards like PSR-4 (or even PSR-0) for autoloading, separation of concerns and good design practices that have become well-used in the PHP community in recent years.

So, what’s my point in all of this? I think the OWASP project can do better, honestly. They’re users of the PHP language but, with a few exceptions, don’t seem to be a part of the PHP community. They almost have their head in the sand when it comes to some of the practices that have come to define the language and community around it. It feels like PHP is an after-through on most of their initiatives and that there’s not much reaching out to the PHP community as a whole to find reusable packages that fit their needs, are more robust, well tested and proven.

The security community inside PHP is growing up and I think having large projects like OWASP understand it and be a part of it can help the news of this renaissance spread even further. PHP developers, more than ever, need as much up-to-date information and tools to help protect their applications. Consider this a call out to both fellow OWASP members and PHP developers as a whole to get involved in the wider security community, share these new advancements and openly share ideas across these borders.

Shatter those old conceptions of what PHP was and replace them with new techniques, practices and knowledge across communities. Only then can we help the wider web understand that PHP isn’t what it once was.

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!

PHP Security Intro on O’Reilly’s Programming blog

The article I wrote for the O’Reilly Programming blog has been published this morning – Preventing Problems in PHP Security. In it I talk about three of the major threats (the top three from the OWASP Top 10) – SQL injection, Cross-site scripting and Cross-site request forgeries – and some basic methods of how to prevent them.

I do want to put a disclaimer on the article, though…as one person pointed out already, this article is definitely not comprehensive as far as the methods of prevention. The purpose was to raise awareness about some of the most basic methods for prevention to hopefully spark further research. There’s also a few websec.io articles that can help if you’re looking for more information:

If you’re not already familiar with the concepts behind the OWASP Top 10, I’d definitely suggest you at least read through the latest version to get an idea of what some of the most prevalent threats are out there.

Starting Secure Development

As I’m trying to get back into some more regular article writing for the websec.io security tutorial site, I thought I’d ask on Twitter for some of the things people might be interested in reading. I thought I’d gather them all up and share them here (since Twitter is sooo good at tracking this kind of thing…). There were some good responses and some things I hadn’t thought about yet:

> Top 10 pitfalls and how to avoid them. @calevans
> how to actually filter input and escape output correctly. @skoop
> I’d like the ability to answer to the question “Is it safe?” with confidence. @AmyStephen
> Data sanitization, escaping, and authentication. @codeguy
> how to test for secure code. @scottmattocks
> One of my largest stumbling blocks has been learning how to write proper (library-less) templates in a secure and flexible manner. @mkmcdonald

You can see all of the responses here. There’s a few articles related to these posted already:

If you have any other suggestions let me know!

iniscan: a security scanner for php.ini

I do a lot of talking at conferences and in the articles I write about application security, mostly in PHP. There’s been a resurgence of interest in creating secure applications and some of the best practices around it. There’s lots of examples of bad code out there but thankfully there’s a growing base of good reference materials that show how to Do Things the Right Way too. Most of these focus on good code practices, though, and don’t think too much about something fundamental to the PHP language and key to any installation – the php.ini configuration.

PHP’s configuration has quite a few settings (and is getting more all the time) so it can be confusing to have to keep it all straight and be sure you’re “thinking secure” in your app’s setup. There’s lots of sites out there that offer recommendations about how you should set up your config file to follow along with the best security practices, but they’re either all the same thing (copy and pasted?) or refer to settings that are now deprecated. So, in an effort to make it easier for developers (and sysadmins) to set up a php.ini file with a more secure configuration, I created the “iniscan” tool (catchy name, huh?).

I want to thank Ed Finkler for the foundational work he did on the PHPSecInfo project a few years back. PHPSecInfo was a web-based tool that you could load in a browser and report back similar information as what the iniscan tool reports. A lot of the rules in the iniscan tool are inspired by the ones he defined.

The tool runs from the command line and evaluates the php.ini file you’ve given it and evaluates it based on a set of pre-defined rules to provide a pass/fail grade on your current configuration. The goal behind it was to create something that was easy to install and easy to use to reduce the barrier for adoption and lead to an increased awareness about what a hardened php.ini looks like.

You can install it using Composer and call the command line “scan” command to get the results. They look something like:

== Executing INI Scan [11.09.2013 01:51:13] ==

Results for /private/etc/php.ini:
============
Status | Severity | Key                      | Description
----------------------------------------------------------------------
PASS   | ERROR    | session.use_cookies      | Must use cookies to manage sessions
FAIL   | WARNING  | session.cookie_domain    | It is recommended that you set the default domain for cookies.
PASS   | ERROR    | session.cookie_httponly  | Setting session cookies to 'http only' makes them only readable by the browser
FAIL   | WARNING  | session.save_path        | Path /tmp is world writeable

[...more test results...]

15 passing
6 failure(s)

Each of the tests gets a pass/fail grade with a bit of color-coding to help the really bad issues stick out a bit more. It looks at settings like:

  • session.cookie_httponly
  • register_globals
  • safe_mode
  • allow_url_fopen
  • expose_php
  • register_long_arrays

…and more. The tool, by default, reports back the information in a “table” output directly back to the command line. There’s options you can pass in that will change the output format into something a bit more machine-friendly (like JSON and XML).

If this sounds interesting to you, check out the github repo for it and try out the latest version (v2.5 at the time of this post). I definitely welcome feedback so I can help make this an even better tool for the PHP community overall. Many thanks to the PHP community members that have already contributed back to the project – Eric Hogue, Jeremy Cook, Hari KT and Alexandru G!

iniscan

Speaking at Day Camp 4 Developers on Two-Factor Auth

Well, the official announcements are making the rounds now, but the next Day Camp 4 Developers,(Master Series) will be coming up in October (the 18th) and will feature several security related talks. I’ll be one of the four folks presenting at this event and will be giving a talk about two-factor authentication. Here’s the summary:

Two-factor authentication has gotten a lot of attention lately. It’s being praised as a way to help eliminate identify theft online and already has several major companies adapting their practices to use it. Let me guide you through the world of two-factor authentication and explain some of the basic concepts and dive deeper into the associated protocols and RFCs. I’ll also show you some common implementations with standalone and web service options to get you started quickly.

Other topics that’ll be a part of this PHP Master Series (Vol 2) are:

  • Fred Alger – The OWASP Top 10 and You
  • Mike Stowe – Prison Theory of Web Development Security
  • Anthony Ferrara – Password Storage (And Hacking) in PHP

Tickets are already on sale, so you can go ahead and reserve your spot. We hope it’ll help encourage more PHP developers to get proactive about the security of their applications and expose them to some of the good practices and new ideas they can use.

Development Security isn’t an Add-on

Thanks to O’Reilly’s “DRM Day” promotion yesterday, I picked up a copy of a book I’ve been meaning to but could justify because a) full price of the ebook is around $25 USD and b) it was written back in 2003 – almost ten years old! The book, “Secure Coding: Principles and Practice” is more of an overview of things to think about when it comes to secure development and less about specific language-related tips. What’s interesting to me is that, despite the book being 10 years old, it seems like the same challenges they were facing then, we’re still facing now.

Even the introduction reinforces something I’ve been trying to advocate in the PHP community for a while now – security is not an “add on” that you can drop in at the end of the development process. Security must be a part of the planning and architecture of your applications from the beginning. If you “go back and secure things” you’re doing it wrong. Now, this doesn’t mean you have to have some kind of security review process retrofitted into your SDLC. I know of lots of teams that have their workflow down and are cranking out the code and features like there’s no tomorrow. How does a team like this start “thinking secure” without having to add a lot of extra overhead? It’s pretty easy really – all it really takes is a shift in mindset.

When most developers I know start out on problems, they ask themselves questions to figure out how to start in on their solution. They wonder about things like the “best way to do it” or “the most efficient way” to get the job done. Their minds start filling up with object structure and SOLID principles, trying to find the best solution (and maybe even technologies) for the job. To start thinking secure, all it takes is one more question:

How can I break this?

Easy, right? Well, like anything else in development, one question always leads to at least 10 more. This one simple question sets you down the right path, though. It’s too easy to get focused on making things work and writing up unit tests that pass when everything’s good. I want to challenge you as a developer to do one thing in your next project. I want you to take a step back from the code – maybe grab a fellow developer to help – and look at the application from the outside and determine what could be exploited and where (the “attack surface“). A lot of times this is easier when you’re not neck deep in the code, so if you have doubts, find an outsider.

Here’s some related websec.io articles I hope can help get you in the right state of mind as you work to integrate secure principles into your development. There’s lots of other topics in there that devs would find useful, but this will get you started:

Let’s all help make the integration of security and development a thing of the past. Then, ten years down the line, people wil be reading books from 2013 and wonder what it was like “before”. 🙂