3 ms·

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/Dru

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-in-2016 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)

dnet 10y ago
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.
- CiPHPerCoder 10y ago
  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."

dnet 10y ago

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.

CiPHPerCoder 10y ago
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."