This is part three of a conversation I had with Anthony Ferrara – PHP core contributor, security expert, and Senior Architect at NBCUniversal – at the PHP BeNeLux '13 conference. In part one of our conversation, we talked about open source as an ethos and how it affects business. In part two, we talk about what the Four Freedoms mean to us as IT and web professionals, and the growing impact and influence of open source software.
Anthony Ferrara is a prominent member of the PHP community and creates many free tutorials and materials "to help people understand complex topics in simple ways". His blog, about PHP, security, performance and general web application development is at blog at http://blog.ircmaxell.com/ and his YouTube Channel is here: http://www.youtube.com/user/ircmaxell.
"PHP is as secure as any other major language"
"The first fundamental misconception about PHP is that people think PHP isn't secure. That is absolutely not true. PHP is as secure as any other major language. The problem with PHP is also the problem with every single other language: you can write insecure code in it," he underscores his point, "but that's a fundamental problem in every single programming language. The job of security is not up to the language. It's not up to the tools that you use. It's up to the people that use the tools. Even the best tools can be misused and lead to major security issues."
Every single developer need to think about security when writing code. This doesn't mean being a security expert, but everyone should be aware of security and best development practices.
Using many of the PHP frameworks and tools that have come out in the last few years, "It actually becomes quite easy to do security and not have to think about it." This can lead to its own problems, of course: "If you depend too much on those tools, those tools become weak points." Anthony suggests being pro-active with your tools and I'd add you should never trust them blindly. If you do, you lose one of the advantages of working in open source, the freedom to study and understand your code.
Fixing vulnerabilities in PHP and elsewhere
Anthony describes how newly discovered vulnerabilities get reported and handled in so-called "white hat" and "black hat" scenarios. The "white hat scenario" involves someone discovering a problem and reporting it responsibly (privately) to the security team, giving them a chance to fix it before releasing the technical details of the problem.
The dangerous scenario is when a vulnerability is discovered by the security team in the aftermath of a security breach of some kind. "You have a black hat, a 'bad guy' who finds that vulnerability and they start using it to attack sites and we learn about it after it's already being used in the real world. That's when you can tell the difference between proactive and reactive projects: The proactive project will be able to identify it quickly, get a fix, and get it out there and then communicate the level of severity and get the problem fixed in the real world. Rails, Drupal, and PHP core do this very well."
The security equation: everybody is part of it
The project maintainers or security team are only half of the equation. As Anthony puts it, "A project can fix a vulnerability within five minutes of it being reported and release a new version, but if nobody upgrades for six years, what good is it?" It comes down to cooperation between the project security teams, "who we trust to handle these issues appropriately and release the new versions," and the developers, system administrators, and users also have to "play their part", drop everything and fix the problem right now."
Open source gives you reason to trust
"I think that's the amazing thing about open source. There still needs to be a level of trust, but in open source, it's not blind trust. We trust people are going to do things the proper way, but when they do it, outside experts can also come in and look and ready and verify what has been done." Or they can say something still needs work, it's not fixed yet. "We can work [together] to get things done better. With proprietary software, they release a fix to a security issue and you update, you think everything's fine, except when five days later another black hat comes along and finds another vulnerability in their fix."
In an open source project, I can check a new security patch myself and even help to improve it if I find a problem with it. "You hear rhetoric from time to time like, 'Well anybody can read the source code so anyone can find a security vulnerability and therefore open source is less secure.' In reality, if that were true, that would mean security through obscurity" ... think of an ostrich with its head in the sand ... "is really good." Security through obscurity is not security at all. With open source software, you don't have to trust obscurity ... The beauty of it is that there are so many people out in the world who are doing it, that in practice, you tend to find that the number of critical vulnerabilities is reasonably low.
What makes for good security?
Anthony defines software security by how quickly a security team responds, is the response appropriate to the severity of the issue, and are the issue and fix communicated effectively.
"All software is going to have a vulnerability the same way all software is going to have a bug. The amount of money and work it would take to produce bug-free and vulnerability-free software ... borders on infinite."
Open source projects' issues, "tend not to be major breaches ... For the most part, the security issues we see in Ruby on Rails, Drupal, or PHP tend to be harder [he means difficult to actually exploit in the wild] and not as critical as the public may think."
Drupal: a study in good security practices
Anthony specifically praises the responsiveness and responsibility of the Drupal security team. Here is an infographic and article that explains how that team works in detail: Keeping Drupal Secure - How the world's largest open source CMS combines openness and security. You can see Anthony's description of the security fix process works reflected in this.
Security Related Resources:
- Webinar OnDemand: Ensure Security Compliance with Drupal
- Webinar OnDemand: Running a Secure website on Drupal
- Webinar OnDemand: Protect Your Drupal Site Against XSS Vulnerabilities
Credits, thank you's
Music for this podcast by Podington Bear. Used by permission. Thank you!
Additional voiceovers provided by Campbell Vertesi, Francesca Ballarin, Victoria McGuire, and Oliver McGuire. Thank you!