At the recent Magento Live Australia Event I hosted a DevExchange table on the topic of:
Security and Magento and Extensions
With security every participant of the ecosystem has their role to play. With bad actors turning their attention to exploiting popular extensions (see for example Willem de Groot's article here ) it is time to focus on improving the status quo. Let's discuss what strategies around disclosure and communication would make a real impact. What would you like to see and what do you think would make a difference?
as part of our ExtDN efforts on improving the security of extensions in the Magento ecosystem.
Thanks every one for attending and for sharing their thoughts.
Before moving into the summary I did want to mention one point expressed by a developer working for a merchant. Indadvertently creating a security hole is always on one's mind. Additionally not many resources and tools are well known to help in writing securer Magento code. I remember Anna Völkl's slides as a good article to get started but I think there is room to educate more and make information more accessible for those that want to improve their code. Some extra tips are also here from the Mage Security Council and a presentation by Talesh Seeparsan.
Summary
As a lot of things in life a solution usually involves communicating better. I try to summarise the different communication aspects below. We didn't focus too much on the first two aspects as we took these mostly for granted and the last one is the hardest to solve.
Communicating a security issue to the developer
There are few things that be can done in this area but it can be summarised as having a published way to reach out.
Publishing a security relevant release
The negative example in this category would be an extension developer not receptive to the idea that their code could have a security issue. And instead trying to sweep it under the rug in the hope of avoiding negative publicity. The falacy in this assumption is pointed out well in Max Chadwick's article - even one of the most valuable companies in the world was unable to avoid the recent Facetime issue or exposing the root user account a while ago.
Communicating the need to upgrade an insecure extension
The status quo can currently only be described as inadequate. Currently best case is that a developer looking after a store periodically scans vendor websites and twitter for security upgrades affecting the store. Some extensions add notifications directly inside the admin - these usually come with varying degrees of nuisance. They are also often hindered by proxy and firewall setups.
From an extension developer perspective it's near impossible to reach the current user of the extension (short of including license management with all code) due to a variety of reasons:
- quite often the buyer is not the owner of the store
- merchants change developers more frequent than extension providers
- reaching people is notoriously hard - even adding up all communication channels, website, twitter (Karen puts active Magento community at >1% and I would agree) and email I believe we only get through to, at best, 30%
- customers use named email addresses which cease to work once someone leaves the company or if someone used a role based email address we get in trouble trying to import it into a newsletter tool like mailchimp (ie admin@ or accounts@ get rejected)
Overview of existing solutions
MageReport
It's mostly for core Magento but does cover some extensions
Magento 1
Magento Vulnerability Database
A community led effort to maintain a database of vulnerable Magento 1 extensions. Uses magerun on the command line to check.
Magento 2
Roave SecurityAdvisories
This would be a great effort to piggyback on. The problem is that a huge proportion of Magento 2 extensions are not managed by Composer. A cursory manual survey by myself would put the number of extensions not managed by Composer at 50%+. Maybe an M2 hosting provider can provide some better figures here from a bigger sample size.
Web Setup Wizard
The Magento 2 Web Setup Wizard could theoretically be a starting point as well. It's already bundled with Magento 2 and it already lists installed extensions. The downsides are it's Composer based (see above) and it is fairly tightly coupled to Marketplace which only covers a subset of all Magento extensions. And it's probably fair to say it has been neglected (for example there is an open issue for about 2 years that hides the Web Setup Wizard in a default server setup).
Related thought
Changelogs (we follow keepachangelog) are surprisingly hard to turn into an accurate list of vulnerable packages in an automated fashion
Ideas
Trying to come up with a solution, every one agreed that something like an installed extension dashboard should exist from within Magento.
To make something like this work two main components would be required. An extension that adds the dashboard and a maintained public database with release information. There are lots of issues to work out in detail but I for one am keen to see how far we can get. To get the most buy-in from the extension developer side I am currently inclined to aim big. In other words a database with all releases, and then work out a way to feed the security relevant ones to some of the above mentioned projects.