Comment by CiPHPerCoder | Hacker News Reader

Comment by CiPHPerCoder | Hacker News Reader

What Evert is referring to (the "reputation" of PHP and people's reactions) is even worse in infosec. I very frequently get accused of being a charlatan simply because I write PHP.

Some people openly question if a PHP developer who understands security exists at all: https://twitter.com/MalwareJake/status/506488937096183808

This is silly when you think about it. If so many systems run PHP, wouldn't you want your infosec people to know PHP and work with it more often? Why are we, culturally, encouraging such a blind spot by ostracizing folks who know it well? That part never made sense to me.

This conversation plays out more frequently than I like:

  Rando: Hahaha PHP security is an oxymoron.
  Me: Okay, then hack paragonie.com. It runs PHP. Logically, you should
      be able to hack it _just for running PHP_ if PHP is so insecure.
  Rando: But that website's mostly static content!
  Me: Yes, but it runs PHP. So it must be insecure, right?!

So far, despite giving people permission so the prospect of CFAA convictions don't discourage them, none of these "PHP is inherently insecure" folks have succeeded. I wonder why. :)

TL;DR - A lot of the hate against PHP is founded on ignorance and peer pressure. Be open to constructive criticism, of course, but a lot of the hate you'll hear is bullshit.

My company does penetration testing and most of the projects involve web apps. Our clients use PHP, J2EE and .NET, and after 7 years of operation, we clearly see a trend where the number and severity of security issues are highest in PHP apps, lowest for .NET, with J2EE in the middle. Of course, there's the odd secure PHP app and the .NET project with gaping holes, but the trend is obvious.

So it's not peer pressure, we actually have data to back this up, and if you think about it, the whole thing boils down to motivation. Sure, you can write secure and insecure code as well in any language/environment. But defaults are powerful, and it makes me feel sad every time I have to write in reports that "you should've paid attention to opt-in to the secure solution every time you do X" vs. when we do demos to developers and we have to work really hard to disable every protection built into ASP.NET. (And no, I don't like Microsoft at all.)

Please tell me more about these PHP projects, if you have the data available to you.

* Did they support EOL'd versions of PHP?

* Are they legacy WordPress/Drupal/Joomla projects that haven't been updated in years?

* Are they in the "we (didn't use a framework|rolled our own framework) and used the mysql_* functions" league?

* Did they attempt to do something weird/crazy (i.e. store all session state in an encrypted cookie instead of server-side like normal, but forget to authenticate the ciphertext)?

Those are the kinds of things that I rarely find in modern PHP projects.

One thing I think Evert neglected to mention in his post: There's definitely an ecosystem problem. Incidentally, I've been working on cleaning it up on multiple fronts:

* Improving the quality of information developers will find via Google search or StackOverflow

* Writing blog posts that address security concerns e.g. https://paragonie.com/blog/2016/02/how-safely-store-password...

* Improving the security of the tools and frameworks developers use

* Working to improve the language itself (part of the reason why PHP 7's CSPRNG functions don't fail open is because a few of us were very vocal on how/why that would harm security)

I know little about most of them, since we did penetration testing (simulating what could an attacker over the 'net do) most of the time, as few of our clients have the budgets for a proper source code review. No CMSs were used, we had one Wordpress, but that was actually almost perfect, since they kept it up to date. These projects were custom-made business applications, not "dynamic" web sites.

Frameworks were sometimes used, although their effect on security is somewhat baffling at first sight -- and this is regardless of the platform, although we found most issues with PHP and J2EE. Sure, when you use the framework for security-critical things such as constructing SQL queries (SQLi) or HTML output (XSS), things work quite well. However, since most developers don't think about these issues, the single time they have to "escape" from the framework, since it doesn't (or they just think it doesn't) support a certain scenario, they don't know about all the things PHP and in smaller ways, J2EE requires to do for security.

Of course, this way, the framework protects 9x% of the application, but the asymmetry of security is that the attacker only needs a single vulnerability while the defender must patch it all.

Groovy! Thanks for the insight.

I'm not surprised to hear that custom-made business applications fared so poorly. Back when I worked for a telecommunications company, I saw some of the worst code imaginable endorsed by corporate and deployed to production with wild abandon. I reported no less than 10 vulnerabilities in my first day with a new codebase and they were all ignored. My boss took me aside and said, "There's some politics going on right now, just keep that in your back pocket in case you need to bring it up later. Now's not the time."

Reply on news.ycombinator.com