PHP

Developer Security Outreach

I’ve been thinking a lot lately about how to try to bring the security and development communities together, most specifically for PHP (see these two posts for more on that). PHP has a long standing reputation for being an insecure language that it’s had to overcome. I like to think that evidence in more recent years is helping to dissuade that, but it’s an uphill battle. Anyway, that’s not what I’m hear to talk about. True to the title of the post, I want to talk about developer outreach as it relates to security and secure development practices.

While comments were made on my two previous post about the relationship going both ways, I want to focus in on things from the perspective of the organization with the bulk of the knowledge – the application security group/company. Yes, it’s good for developers to contribute back to shared resources so both parties can benefit, but with so many new developers coming to the language every day, I see a real need for engagement. There are a lot of groups and individuals out there on the security side that specialize in training and resources to help developers write their code more securely. They provide training classes and white papers on new technologies that can be used to get the ideas across, but usually only in a limited fashion. They write blog posts about the latest exploits and vulnerabilities or even speak at conferences with case studies and their own real-world experience in the world of application security.

So, take a step back – do you see a problem with this model? Most of these things I’ve listed involve talking at the developers and not with them. Sure, some of the training classes are more hands-on and can be much more effective at getting the speaker’s ideas across. However, these kinds of resources are mostly provided if requested or actively sought out by the developer. There’s a wealth of information out there about securing applications, even PHP ones, that’s tucked away and only shown when the right Google search is performed.

Is there a solution? In thinking about it some this morning, I see a pretty obvious one – developer outreach. I’ve mentioned this same idea before in another post, but that one was more targeted towards the OWASP group and the services/resources it provides. It still surprises me when I ask in my sessions at PHP-related conference how many people have heard of OWASP and some hands go up but a lot don’t. Likewise, there’s a lot of companies out there that provide application security training (such as the Denim Group, WhiteHat Security or even SANS) but those are still presented as passive resources. Developers, by their nature, are notoriously lazy. They try to find the most efficient, most robust solutions to problems. How much would they benefit from someone from the Denim group reaching out to them or even just the PHP community as a whole and sharing what they have to offer.

Am I suggesting they hop on the various community mailing lists and start spamming them with ads for their training courses? Of course not. Here’s what I am proposing:

If you provide training, resources or any other kind of resources that developers could benefit from to create more secure applications, find an advocate (or a few) in the community of your choice and request their help to get the word out. I’d even go so far as to suggest having someone dedicated to working with communities, maybe even different people for different communities. This person should be dedicated to not only sharing what kind of things the company/group has to offer the developer community but to also act as a guide to keep them on the right path.

There’s a security subculture in just about every language out there. The key for those with the security knowledge and resources to do is to tap into it. Break into the community with a sense of humility, an open mind to learn about its members and a passion for teaching and sharing knowledge on a personal level.

Advertisement

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.

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.

PHP, PDO & HP Vertica

As part of my new role, we’ll be working with HP’s Vertica for some of the data storage. I’ve been struggling the last few days to get it working on a Vagrant-provisioned linux box (VirtualBox) and finally have the process down. I thought I’d share it for those out there needing some help. I’m working with a Ubuntu server box, but these instructions could be pretty easily adapted to other distros:

1. Ensure you have the Unix ODBC package installed. This is what PDO uses to connect to the Vertica instance:

sudo apt-get -y install unixodbc

2. Ensure that your PHP installation has PDO support with ODBC handling:

php -m | grep -i odbc

You should see something like “PDO_ODBC” there if it’s installed.

3. Grab the latest Vertica linux drivers from the My.Vertica site (requires a login). Click on the Downloads section and scroll all the way down to the drivers. Grab the right ones for your linux installation. I used the Linux ODBC 64-bit.

4. Make a “/opt/vertica” directory on your system and untar the archive there.

sudo mkdir /opt/vertica
sudo tar zxvf vertica-odbc-6.1.3-0.x86_64.linux.tar.gz -C /opt/vertica/ > /dev/null

5. Create the configuration files where needed. There’s three of them – odbc.ini, odbcinst.ini and vertica.ini. Here’s the examples and the paths for them:

In /etc/odbc.ini:

[VerticaDev]
Description = Vertica Dev
Driver = /opt/vertica/lib64/libverticaodbc.so
Port = 5433
ServerName = your-hostname-here.com
DatabaseName = database-name
UserId = database-username
Driver = Vertica

In /etc/odbcinst.ini:

[Vertica]
Description = Vertica driver
Driver = /opt/vertica/lib64/libverticaodbc.so

In /etc/vertica.ini:

[Driver]
DriverManagerEncoding=UTF-16
ODBCInstLib = /usr/lib/x86_64-linux-gnu/libodbcinst.so.1
ErrorMessagesPath=/opt/vertica/lib64
LogLevel=4
LogPath=/tmp

If all goes well, you should be able to make a script like this to test it:

<?php
$dbName = 'your-database-name';
$hostname = 'your-hostname.com;
$account = 'your-username';
$password = 'your-password';
$driver = 'Vertica';

$dsn = 'Driver='.$driver.';Server='.$hostname.';Database='.$dbName;
$pdo = new PDO('odbc:'.$dsn, $account, $password);
var_export($pdo);
?>

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