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.
blog.phpdev 
This quote resonated with me: ‘other packages are “written by developers and not security experts.”‘ This is, to be frank, utterly insulting. Many of the existing packages already gaining traction in the community are successful in large part because there are security experts either leading or actively involved in them.
As examples: RandomLib and password_compat from Anthony Ferrara. Zend\Escaper, which was written largely by Padraic Brady. Zend\Crypt\Bcrypt, written largely by Enrico Zimuel. These are all people who are themselves security experts and who are choosing to work in the PHP ecosystem, not in a silo; saying that packages outside the OWASP group are not as secure is elitist.
That’s my primary problem with the group — it dictates security practices, and anything they do not approve must inherently be insecure, regardless of the source. This is not an attitude that fosters collaboration or trust, particularly in the world of open source.
LikeLike
If we take two topics: software and documentation. OWASP currently has both. Thereafter we hit the problem outlined by Chris – neither has all that relevance to the PHP community.
Software has been written within the community and it’s “out there” on Composer. There remains an element of poor security knowledge evident even in certain popular packages (and nobody should discount that entirely – we do have a disproportionate number of programmers with formal training (or no training) in non-PHP languages to be constantly wary of), but Zend Framework and Symfony, for example, are reliable, well monitored and have working security policies. They helped set a trend that made being secure important, rather than an add on annoyance that could be ignored (and I do get ignored at times!). These frameworks do screw up on ocassion, but they do then go nuts applying fixes, disclosing them, and backpatching versions. Everyone screws up. The difference is in how screwing up gets handled ;).
It is incredibly easy in PHP to find quality secure packages. Just follow the dots from the tribal security “gurus” and you’ll be fine. We all write code, blog and generally moan a lot on Twitter ;). We are few in number but vocal.
The documentation offered by OWASP, as it does not relate to PHP, is generally of a high quality. I’ve referenced their cheatsheets enough times :P. The PHP Cheatsheet that I could locate is however poorly written, wholly incomplete, outdated, sometimes runs contrary to other cheatsheets, and is incorrect in several places. It shouldn’t be hosted under OWASP for people to appeal to authority over. I would prefer we all collaborate on something like PHP The Right Way with a security variant of that excellent resource. Something accessible to the community, open for editing by the community, and not overly siloed on a page deep in a wiki. Chris even has new books out, and I have bitterly complained about the horrors of pre-existing “PHP security books” more than once.
Importantly, it’s essential that PHP is not lumped in with or treated identically to any other language. All programming languages share elements which means they have security issues and weaknesses in common. However, PHP is its own independent thing with its own independent bugbears and nuances. For example, it has those streams which until PHP 5.6 disabled all SSL peer/domain verification by default when hitting up a HTTPS URL. Folk will notice that PHP 5.4 and PHP 5.5 remain living versions. This is the scary stuff that needs documenting. When it is documented, you notice that people react and change, that getting quality information, even in tiny slices, out there does make a difference. Others take an interest, they get suspicious of the status quo, they write new code, the world gets a little better. It’s not easy work, and you sometimes feel like a broken record on its 1000th loop, but it’s worth doing.
LikeLike