The challenge for 2019 has just got real
I am a regular listener to the Security Weekly Podcasts Network, that includes Hack Naked News, Business Security Weekly, Enterprise Security Weekly, Secure Digital Life and Application Security Weekly. I really love their shows and over the years I've been listening to them, I learned a lot about business leadership, communication and security. If you're in tech, I can highly recommend listening to their podcasts. And since I'm always on the go, these are great shows to listen to while driving around.
But… and here it comes: for some reason they have a love-hate relationship with PHP, where their disliking of the technology is omnipresent in their shows. Particularly in their Application Security Weekly they love to pick on PHP and blame it for all the evil that exists on the internet. On one hand, I cannot blame them since the strength of PHP lies in the fact that anyone can write a dynamic website within a few minutes. The downside is also that anyone can write a dynamic website within a few minutes. So I understand where they are coming from. Do I like it? Nope.
During episode "In Flames - Application Security Weekly #44" they were picking on WordPress that released version 5.0.1 with a series of security updates for version 5.0.0 that was released a couple of days earlier. The host Keith Hoodlet's comment "WordPress, you should have this down by now, I think" got me all fired up.
I'm not knees deep in the inner workings of WordPress, but I do know that it's a vibrant, active community that just want to give users the best experience for the many users worldwide. The only time many security researchers are actually looking at the code (and vulnerabilities) is when the code is released. If half of them would take part in the development process before the release is done publicly, many of these issues can be tackled upfront.
But that's the thing with open source: people expect that everyone is on top of all the things and that you are fixing bugs in an instant. I've been in professional development since 1990 and I've seen over the past decades the industry putting more and more requirements on developers but not providing them the time to actually learn properly what needs to be known resulting in an ever lasting chase of the technology rabbit. Those who actually invest large portions of their off-work time to learn and adapt, understand what gap needs to be filled.
So after listening to the rants of both the show hosts Paul Asadoorian and Keith Hoodlet, I decided it was time for me to take on a new challenge for myself and the PHP community I love so much: I need to learn the security aspect of web application development in general and PHP in specifics so I can educate and mentor those in the community to build more secure, robust PHP applications so by the end of 2019 I can convince Paul and Keith that PHP is as secure as any other technology stack out there.
I don't know what I'm getting myself into as I have only a basic understanding of web application security (OWASP Top 10, OWASP Web Application Security Testing Cheat Sheet, PHP Security, PHP Security Consortium and the Basics of Web Application Security by Martin Fowler. I was also lucky that my compony partnered with RIPSTech who have a superb security scanner for all sorts of PHP vulnerabilities, and I love their annual PHP Security Advent Calendar where each day of December they are challenging the audience to identify the vulnerability.
Let me use this blog to share my experiences as I go through the process of learning security and I'm reaching out to my friends in the PHP and Testing community to come to my aid to point me to things I'm not yet aware of (the dreadful unknown unknowns). And hopefully I become a wiser developer by the end of 2019 so I can convince the hosts of Application Security Weekly that PHP is not better and not worse than any other technology.
Excellent initiative, the PHP community needs to have more security attention since it corresponds to 80% of the WEB, nothing more natural than to suffer more attacks. In addition to the links you mentioned I would add the PHP CVE https://www.cvedetails.com/vulnerability-list/vendor_id-74/product_id-128/PHP-PHP.html
ReplyDelete