PHP

5797398751_e47d90690a_z

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.

Some “Why Won’t Solar Work” Tips

With more and more people installing and using Solar all the time, theres some questions that get asked quite a bit. I wanted to help with some of those questions by providing some simple answers here. Here we go…

  • Tip #1 – Be sure that you have your App directory correctly set in the configuration file. If you don’t add it to your front controller Classes setting, Solar has no idea where to find it.
  • Tip #2 – Class names on the controllers are important! Be sure it follows the directory tree like Project_App_Controller. Also be sure you’re extending the right thing. I usually use a Base controller/setup to provide an overarching “global” place to put things (like a layout) and extend that, so it’s usually “extends Project_App_Base”
  • Tip #3 – You can change the values that the Solar_Form login functionality uses to trigger the automagic login process by setting it in the adapter for your authentication object (like a Solar_Auth_Adapter_Sql) via the process_login and process_logout values.
  • Tip #4 – Be sure to include everything you need to get to “magically” through Solar in the set_include_path in the front controller. For example, you can add in another directory with external libraries so that in your application, you can just call it and let the __autoload handle it.
  • Tip #5 – You might get some complaints from Solar about not having a “sql” object it can work with. I good way to handle this is to check in your _setup function of your controllers to see if there’s one registered. If not, make one with a factory call and register it for the framework’s use: Solar_Registry::set(‘sql’, Solar::factory(‘Solar_Sql’));