As part of the Magento Imagine 2013 Barcamp, I attended Tom Stripling's session on extension security. It is evident that ebay are dedicating a lot of time towards ensuring the security of Magento. It also works with reports from the community to security@magento.com. These together with the priority that security was given since the start have resulted in the platform having survived relatively unscathed from security media exposure.
Maintaining Security
One problem that we do face, however, is ensuring that security is maintained after installing third party Magento extensions. The Magento core code has the advantage of the community and the "many eyes" rule of security. Third party extensions do not always benefit from this and often are installed to provide functionality without a consideration for vulnerabilities that they may be adding.
We have to remember the first rule of security which is that a system is only as secure as its weakest link. Therefore, it can only take one vulnerability in one extension to provide an attacker with total control of the website. We have to consider the drawbacks as well as the benefits of using extensions and our responsibility to protect our customers.
Trusted Extensions
One (drastic) option is to move towards a closed system, similar to the Apple App Store. This would require every extension to undergo a code review by a trained team. While many would appreciate the peace of mind that this offers, this system has a much larger resource overhead when compared to the current system. Hence, this sort of change would be difficult and require significant investment. In actual fact, there was a similar scheme that was briefly introduced called "Trusted Extensions", but unfortunately with the takeover by ebay and the massive growth that Magento has seen in other areas, it has been left towards the bottom of the priority list.
We should consider the size of the task at hand with around 7000 extensions in the market place, the speed of growth, and the number of updates that get released. Magento would require a sizeable and skilled team to manage it. I believe for this to be feasible, Magento would either need to charge for listings or begin hosting and taking payment for extensions although that opens another can of worms.
Saying this, there are still whispers that Magento are heading back in this direction. Tom Stripling mentioned an idea that is being discussed internally about running automatic static code analysis on extensions to check for bad practice and security weaknesses. By his indication, this is very much still in the ideas stage and he welcomes feedback from the community. In my opinion, I only see this working with community extensions until Magento begins hosting commercial extensions.
Our Responsibility
So what can we and must we do now as developers? Our challenge is to ensure that our customers can retain the assurance that their sensitive data stays secure. We do this by prioritising security and reliability over software reuse and the short-term cost benefits it offers. It is our responsibility to our customers and to the rest of the Magento Community to offer our expert opinions. We need to review every extension that we install on a client system and provide early warnings of any long term sacrifices that are being made. If these sacrifices are too great, then the extension should not be used. Hopefully, the extension developer offers a refund and then it's only time that is wasted.
From the point of view of a Magento solution provider, when there are extensions on Magento Connect that appear to solve a problem, we need to decide whether the advantages of using the extension outweigh the negatives. Most commercial extensions are around the $50-$100 mark, and an average hourly rate of a Magento developer might be in the range of $100 - $150. The extension tends to offer a significant short-term cost and time saving. With deadlines, budgets and an eagerness to say yes to clients, it is easy to give the extension developer the benefit of the doubt and assume that it will perform wholly as described.
In reality this is rarely true and we have to consider the hidden cost of Magento extensions. How much additional developer and project management time will be spent diagnosing and resolving issues? Or worse still, imagine the cost (monetary or otherwise) of a security breach.
As an agency, many purchases come down to trusting the extension developers and the quality of code that they produce as well as the support that they offer.
Obfuscation and Encryption
This is a popular method by extension developers to protect their code. When extension developers do this it makes our life a lot more difficult to recommend them. I do, however, sympathise with why developers choose to implement these mechanisms. Magento extension piracy is a real problem and understandably developers want to ensure that they get the maximum return on investment given the number of hours it takes to design, build, test, document, support and maintain an extension.
It was reported recently by NBS System, a Magento hosting partner, that only 2.7% of stores that are running their popular Nitrogento full page caching system have paid the license fees for it. The effectiveness (assuming a goal of profit) of DRM is a wider-question in the world of software at the minute, especially with its problems in the gaming industry recently. Its use is debatable but not an argument that I will delve into here.
What I will offer are the reasons why we choose to release extensions free of obfuscation and encryption. In fact, a number of our modules are open source including DIY Mage (remember the difference between free speech compared to free beer). The route we took with licensing this extension was to release it under the "GPL 3.0 or later license" but implement a ping-back server so that we know where it is installed. This can never effect the functionality of the system and render it useless (e.g. when the ping server is unavailable). Although, with open-source, this functionality could easily be removed.
One reason we choose this is transparency. We want our customers to be confident in their understanding of the workings of the module and to trust it. By providing access to the code, this not only encourages us to build reliable and tested code but also enables others to review it.
Another reason is extensibility. It is normal for solutions to require multiple extensions in order to meet the requirements but rarely does each extension satisfy a requirement in its entirety or in precisely the required manner. At this point, we are required as solution experts to extend further. Extensions that are a black box do not allow for this and is is then hard to deem them fit for purpose.
Alternative Magento Extension Stores
Analysing third party extensions is a reasonably expensive process and solution providers want to be in a position where they know they can trust an extension before purchasing so that a project plan can be made.
To assist with where Magento Connect is lacking, there are efforts by members of the Magento Community to provide validation and verification as a service, by providing their own market places. Ones of note include the Netresearch App Factory and the WebShopApps AppShop. Both are still new and predicting their success is difficult and highly reliant on reaching critical mass. Netresearch are likely in a slightly better position because of their neutrality between system integrators, extension developers and merchants. However, AppShop currently has a more restrictive approval system with developers requiring to meet not only code quality but also support requirements. This is a positive move to ensure that only quality extensions from trusted developers are provided and is a courageous effort given the potential overheads should it grow.
The new Magento Connect review system is an improvement on the previous one. Previously it was common for the review section to be used as a support system, a purpose for which it was not designed nor built for. Hopefully, the review system, now with multiple rating attributes, together with the removal of unused extensions will make it easier for solution partners and store owners to choose which extensions to purchase. My next request to Magento is to improve the search mechanism. Although I do expect the ranking mechanism to change as the review scoring system becomes sufficiently populated.
Interestingly, Netresearch have recently released the first version of a tool for automatic static code analysis, named Judge. While this is also a large project, I personally think that it is a great idea and they already have made a great start. The Meanbee Community extensions can already be found there and average a score of 72. Trying out some of our commercial extensions ourselves and it has already been great at noting areas for improvement. Quality is something that we pride ourselves on. For this reason, we dedicate to use this tool and not release a module that receives a score lower than 70 and endeavour to do our very best in terms of Judge Score. What I ask in return is for others to have the same passion for improvement and hopefully this is can result in an overall increase in quality and approval of extensions within the community.
As Judge tool develops, with further tests being added and the scoring system refined I hope that Magento will recognise its benefits and add it to each extension page on Magento Connect.
I believe that the average cost of Magento extensions could increase with those developers that get high Judge scores as it gives the customer reassurance on the quality of module. It's certainly something that we would recognise as making an extension more valuable to us and our clients.
Extension Security
Returning to extension security talk by Tom Striplings, he explained a three pronged approach. The first is automated static analysis which could be provided by the Judge tool. The second is penetration testing which no solution or service provides at this time and should be undertaken by the solution provider. The third is community involvement which uses the "many eyes" principle that I discussed earlier. I believe this is already in effect with community naturally sharing their experiences with extensions and vocalising their issues. Another way that this is happens is the mass distribution and use of the module, the developer should receive feedback from all of these eyes should there be a problem. Note that this relies on the code not being obfuscated or encrypted.
During the barcamp, a vulnerability in an extension was shown whereby user input was intercepted and changed to something that the developer did not account for. In this instance, this allowed read access to any area of the system that the webserver had access to. User sanitisation is a basic task for a developer but yet still easily missed. Doors left open are easy to walk through, but they are also easy to lock - we just sometimes we become too complacent and focussed on where we are going.
As developers, there are simple steps that we can take to prevent these weaknesses. And these aren't specific to Magento development, they are just best practice.
- Sanitise user input!
- Don't just focus on making things work.Add negative tests too to ensure that all edge cases are accounted for.Tom Stripling referred to these nicely as "abuse cases" to your use cases.
The last thing that Tom re-inforced was that security@magento.com is not just for core Magento code. Reports should also be made for extensions as actions can be taken.
Conclusion
In summary, we are in a difficult position as solution providers. There is a wealth of knowledge and extensions out there that our clients can benefit from. Each time that an extension is used, we have to take on the responsibility of validating its use and performing a code check rather than blindly installing it.
I am very grateful for Magento, as well as people in the community like Karen Baker and Thomas Fleck for their continued and unwavering efforts to push the Magento Community forward.