Recently, I’ve been giving some thought to the risks associated with the “Miscellaneous HTML” and “Scripts and Style Sheets” (a.k.a. “Miscellaneous Scripts” in Magento 1) features in Magento. For those who don’t know, these are two text fields that accept any arbitrary input which is then rendered globally in the footer or header (respectively).
This was mainly spurred by Willem de Groot’s findings on credit card skimming. These fields are typically implicated in these types of exploits. I took Twitter to voice some initial thoughts on the matter.
My Tweet there was just something that had popped into my head, but at this point, I’ve had more time to think on the matter and wanted to share my thoughts.
First and foremost, I think that administrators should have the ability to turn this feature off entirely. There are tools that offer similar functionality such as Google Tag Manager (“GTM”), which… 1) Is officially integrated into Enterprise Edition; 2) Has been integrated into both Magento 1 and 2 via unofficial (free) community tools.
GTM can function exactly like “Miscellaneous HTML” with very little effort, but also supports much more sophisticated use cases via the Data Layer. It also offers many advanced features which make it more secure including…
Luna Metrics published a great post outlining the security features built into GTM.
Turning the feature off should…
Since most Magento power users are accustomed to having this feature available, it should default to “on”, but official Magento security resources should state that turning it off removes a potential attack vector.
For stores that, for whatever reason, want to keep the feature on, Magento should build in some additional security related features. In my mind, the main thing needed is the ability to monitor and audit changes to these fields.
Similar to functionality offered by GTM, Magento should maintain a log of changes to both of these fields. In addition to hooking in to save events in the Magento admin, MySQL
TRIGGERs should be used to detect any changes that might result from SQL injection. Changes to the data detected by the
TRIGERRs without corresponding changes stemming from admin actions should set off alarms.
There should be an area in the admin where these changes can be audited showing before and after for each. Another thing that could be added is a daily cron job which sends a digest of any changes to a configured email address (e.g. an individual in charge of security for the store is notified of all changes).
One other topic I’ve been thinking about in all this is content security policies. For those who don’t know, the Content Security Specification allows the server to send back a response header (
Content-Security-Policy) which outlines from which origins scripts can be executed from (and whether or not inline script is permitted). It is supported in all modern browsers other than Opera Mini.
Implementing a content security policy can additionally help mitigate the dangers of accepting “Miscellaneous HTML” (or even using Google Tag Manager, if an admin user’s Google account were to get hacked). It would be interesting to see Magento pursue introducing the ability to utilize a Content Security Policy.
If you have any comments, feel free to drop a note comments below. Of course, as always, you can reach me on Twitter as well.
Hi, I'm Max!
I'm a software developer who mainly works in PHP, but also dabbles in Ruby and Go. Technical topics that interest me are monitoring, security and performance.
During the day I solve challenging technical problems at Something Digital where I mainly work with the Magento platform. I also blog about tech, work on open source and hunt for bugs.
If you'd like to get in touch with me the best way is on Twitter.