As web developers we often find ourselves in the awkward situation of reviewing extension/plugin for our CMS. You know, project managers tend to look into ways to eliminate waste (as according to LEAN methodology) by using already existant plugins. That’ perfectly fine  – had it not been for that most plugins suck. Sure – they offers us what we need when we need it. My problem with them is three fold.

  1. They are often not backed up by a company, or at least a dedicated development team.
  2. As a direct result of pt. 1 they are most often outdated.
  3. General lack of security.  This is my topic of the day.

The review workflow has been almost the same in every company I have been in touch with. It goes something like this:

  1. Project manager or customer wants a specific feature -and forces the developers to go hunting for suitable plugins.
  2. A suitable plugin is found and put into production straight away.
  3. X project hours are spent debugging since the plugin has brought with it a bunch of security holes and broken features.

In order to ease myself and my colleagues I have snuck a valuable tool into this workflow. Meet cvedetails.com. CVE Details is a site that offers a comprehensive datasource for CVE vulnerability data. When I find a plugin, or for that sake, a new CMS, I go directly to this site and look it up.

If I find the tool listed – this site will give me a very nice overview over vulnerabilities over time both graph wise and through a summary table. One feature I find my self using the most is the list over vulnerabilities discovered the current year. This list is kind of hard to read – but not a real issue. Clicking an CVE entry brings me information about confidentiality impact, integrity impact, availability impact, access complexity, if authentication is needed in order to reproduce the hack, which access is obtainable and of course the vulnerability type. Of course – there are also a section devoted to references regarding the CVE (most often blogs on how to reproduce and support ticket information from the vendor).  Maybe the most interesting detail is the CVE registration ID itself. Armed with this tool I can ‘grep’ the plugin repo log for any fixes or mentions, or Google to find further information regarding it.

After writing this I feel I need to address the nature of plugin developers – after all I am a developer myself. We developers have  a filthy habit. We see solutions everywhere. When there’s a problem we simply register a new project on Github and starts developing with no mind set on customer support. Code for developers by developers. This results in my simple list of three agonies mentioned above. Still addressing the third point: security doesn’t always mean a security hole by default. It might also be the lack of proper documentation on how to use and secure the plugin. And that is the worst kind. Finding an entry on CVE Details does not mean that the plugin is uttermost useless. It might very well be that the plugin must be set up in a special way – but the nature of how users use it might in fact be the subject of the CVE entry due to lack of proper documentation. I hope I made it clear.

This was a very simple introduction to this tool and I hope you’ll find it worth using. There are many other tools like this on the net. Just remember – your manager might not agree on your decision on not to use the desired plugin. Most often, from experience, features over security is always favored. And by the way – if you are a developer finding yourself butt hurt – good! Start cranking on making the world better.

Advertisements