Hacker News Reader

Comment by dnet | Hacker News Reader

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.)

View on HN

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