The Magento and Facebook Conversion API Conundrum

Apple is well known for being a privacy-first company. One needs to look no further than the ongoing news stories about their refusal to unlock iPhones for the FBI to understand this.

Recently Apple has shook things up for marketers with new privacy focused policies introduced in iOS 14. One significant impact that has prompted many discussions with our clients is around Facebook pixel tracking.

Want to learn more about these impacts? Head on over to the Rightpoint blog.

Something Digital - magento

New Open Source Tool for Magento

We’re pleased to announce a new open source tool for Magento to add to your security toolbelt: SomethingDigital_InvalidateAdminPasswords.

Here’s the use case: your Magento website has experienced a breach and you want to reset all admin credentials.

I had previously blogged a quick tip for how to do this here, but this module offers a much better experience:

  • Invalidation is handled via a bin/magento command. No raw SQL queries needed 😅
  • It sends an email to all admin users instructing them to reset their password (process documented in blog post had no way of notifying users).
    • The email can be customized from the Magento admin panel.
  • Invalidates two-factor authentication user configuration (assuming 2FA is via msp/twofactorauth).
  • Functionality is covered by integration tests and hooked up to Travis CI.

 

It’s important to note that the module currently does not kick out any users with active admin sessions. However, there is documentation in the README explaining what can be done to achieve that.

You never know when you might need this feature and don’t want to be scrambling to have it when it’s already too late, so install this module now!

Hope you enjoy it!

Something Digital - magento

Securely Connecting Magento BI to Magento On-Premise 

Magento BI (“Business Intelligence”) is an analytics platform which aggregates data from various sources to create beautiful and actionable dashboards and reports. If you’d like to learn more about what Magento BI is and does check out our blog post “Magento BI and why you need it”.

In this blog post, we’ll look at what’s involved with connecting Magento BI to Magento from a technical standpoint, and how to do so in the most secure manner possible.

How Magento BI Connects to Magento

Per Magento’s official documentation, Magento BI connects to Magento through a MySQL connection. You’ll also see that an SSH tunnel is recommended for the connection. We agree with this recommendation as it ensures that the connection is encrypted and allows you to keep port 3306 completely closed from public access.

Securely Setting Up the Connection via an SSH Tunnel

When setting up the connection between Magento BI and Magento the principle of least privilege should be followed. In other words, Magento BI should be given the minimum level of access required on the Magento system to function.

Magento also provides documentation on setting up the connection via an SSH tunnel which follows this principle well. A few important things to call out:

  • A dedicated Linux user should be set up for Magento BI.
    • We recommend using a restricted shell as documented here.
  • A dedicated MySQL user should be created.
    • The user should not be given write access to the database as documented here.
    • Access should also be limited only to the required tables (e.g. the connection does not need access to the admin_user table).

 

Additionally, in an environment using master / slave replication, Magento BI should be configured to connect to the read slave, not the master.

Magento Commerce Cloud

If you are using Magento Commerce Cloud the process differs and is documented here.

Security Lock

Security Best Practices: Security.txt

With the rise of cyber-criminal rings like Magecart, security is becoming an increasingly relevant topic within the ecommerce space. In this post we’ll explore an emerging specification, security.txt, and explore its relevance within the Magento ecosystem.

What Is It?

The usage of security.txt can be read about on the project’s homepage.

In a nutshell, websites publish a file named security.txt, in the .well-known/ folder. Here is an example of a published security.txt file, https://github.com/.well-known/security.txt. The file provides information on how security issues should be reported to the owner of website in question.

Why Is This Relevant?

As reported by Dutch security researcher, Willem de Groot, Magento extension are now the top cause of Magento breaches. “Internet Bad Guys” are proactively scouring the source code of Magento extensions looking for vulnerabilities and using them to compromise Magento sites. As such, it’s more important than ever for Magento extension providers to facilitate responsible disclosure of security vulnerabilities identified by responsible security researchers.

What Is Something Digital Doing About This?

I’m happy to announce that Something Digital now publishes a security.txt file:

If you discover a security vulnerability in any of our open-source modules, our website, or on the any of our client’s websites please report it to us responsibly as we’ve documented in our security.txt file.

How Being Available on GitHub Has Changed Magento Development (for the better) at SD

Magento has always been an open source platform. If you ask me, this fundamental tenant of the software is likely the biggest contributor to the platform’s success.

With Magento 2, however, this open source ethos has been taken to the next level. Now, the source code for the software is hosted on GitHub, where a dedicated “Community Engineering” team is responsible for triaging issues and pull requests contributed by the Magento community.

In this post, I’ll discuss how being available on GitHub has changed the Magento development experience at Something Digital, for the better.

A New Approach To Implementing New Features / Platform Improvements

In the Magento 1 days, if you wanted to add a new feature to the Magento platform, the approach was simple. Build a module to implement the desired functionality and install it on the code base in question. At Something Digital, we’ve done that countless times. In fact, we have made many of those publicly available on our GitHub page, and there are even more that we’ve decided to keep private.

With the Magento 2 code base being available on GitHub, however, things have changed. Now we’re presented with a few options…

1. Custom build and install a module as we would have done in the pre-GitHub days

2. Contribute the changes back to the Magento code base via a pull request and upgrade when the changes become available

The main benefit of the latter option is that the code we write and submit via a pull request becomes an official part of the Magento code base. As such, we do not have to worry (hopefully ?) that future changes to the Magento code base will break our customizations. Further our changes are now available to and will be used by the Magento community, meaning Magento core developers or Magento community contributors can enhance or bugfix the changes we introduce.

The main downside to the second approach is that going through the code review / release process adds some additional time to the overall turnaround of the change which may or may not be tolerable. However, while the changes are going through review, we can generate patch files to apply to our client’s sites, prior to upgrades being available through official Magento releases.

As you can imagine, we typically favor the latter option whenever possible.

GitHub Issues

Another major improvement that has come with GitHub hosting is GitHub issues. While there are many channels for “Googling” Magento (StackExchange, Magento Forums, various blogs), GitHub issues provide a unique environment that is unparalleled by any other.

Among other things, issues on GitHub provide references to specific lines of code, labels and responses from Magento core engineers, and workarounds identified by community members. They’ve been invaluable for our team to get to the bottom of issues reported by our clients.

Git Blame / Pull Request Audit Trails

Finally, by being on GitHub, we are able to use the powerful Git tools such as git blame to understand the code archeology of any and all code in the Magento code base. We can then review commit messages and conversations about the changes that happened via a GitHub pull request. Again, this has come in handy more times than I can remember.

Conclusion

All in all, being available on GitHub has been very beneficial to our development process at Something Digital. If you’d like to continue the conversation feel free to hit us up @SomethingDigitl on Twitter or on our contact form!

Code Review at SD

At Something Digital, all developer code goes through a review process before being integrated into any codebases that we manage. This Code Review process sometimes raises questions from clients, prospects, and job candidates alike. In this post, I’ll answer some common questions that come up about our code review process.

Why Do You Do Code Review?

Whether it’s code, an important email, a proposal, or a report; it’s always good to have a second set of eyes review the work. Code Review helps reduce the risk of introducing problematic code that cause immediate issues or problems in the future.

What Are You Looking For During Code Review?

Reviewers use several criteria in their evaluation, and we document them to ensure consistency in the process. Here are several important things we check during code review:

– Clarity: Is the code easy to understand and to determine what it delivers? Difficult-to-understand code is likely to introduce maintainability issues in the future.

– Performance: Are there signs that the code might negatively impact performance? We don’t want new code to slow the page.

– Security: Are there any obvious security issues with introducing the code? For example, do we see opportunities for XSS or SQL injection?

– Standards: With multiple authors contributing to a single code base, it quickly becomes messy if everyone follows their preferred coding styles. For this reason, we’ve standardized on PSR-2 and check that authors follow these standards.

What’s The Difference Between Code Review and Quality Assurance?

The distinction is important—code review is not quality assurance. Code review ensures the code is of high quality, but does not guarantee that code is bug-free or meets precise requirements. Instead, code review compliments quality assurance with a shared goal to deliver a high-quality and maintainable product.

As A Client, How Do I Benefit From Code Review?

There are several ways that clients benefit from code review, including, but not limited to, the following:

1. Code review spreads knowledge. It increases the number of team members who understand your codebase, which is important when your lead engineer is unavailable or on vacation and issue arise.

2. It’s much more likely than standard QA to find performance or security issues.

3. It ensures error handling and other standards are followed, helping comply with PCI requirements. In fact, code review itself is mandatory for PCI compliance.

In fact, code review itself is mandatory for PCI Compliance.

Do You Use Automated Tools?

Yes! We use Scrutinizer which runs static analysis against each pull request our developers submit, which helps to automate this process.

Contact Us

If you have any questions about our code review process that aren’t specifically answered in this post, we’d love to hear from you!

Building Tools For A Better Patching Process

On May 31st, Magento announced security patch SUPEE-9767 and Magento Enterprise Edition v1.14.3.3. These security updates address 16 separate platform vulnerabilities, 8 of which are considered high severity.

The patch notes call for manually updating a setting in the admin panel prior to deployment.

Before applying the patch or upgrading to the latest release, make sure to disable Symlinks setting in System > Configuration > Advanced > Developer > Enable Symlinks. The setting, if enabled, will override configuration file setting and changing it will require direct database modification.

Magento SUPEE-9767 patch notes

This step is required to properly implement the fix for the vulnerability identified as “APPSEC-1281”, which Magento has classified as high severity.

This setting must be set to “No” for patch to be correctly applied

As part of our patch assessment process we decided to build a small Magento module which automates the steps required to toggle this setting. Not only does this save us time as we roll the patch out across our client base, but, more importantly, it helps reduce the risk of human error during patch implementation.

We’ve made the module publicly available through GitHub. Hopefully this helps improve the process of patching across the entire Magento ecosystem.

Happy Patching!

Rolling Out MasterCard 2-Series Compatibility at SD – Part 2

In part 1 of this series we looked at the high-level process of how SD rolls out updates that impact its entire Magento client base. Specifically, the following questions were posed:

– Which versions of Magento are affected?
– What options are available to remediate the issue?
– What are the potential pitfalls developers will encounter when applying the required fix to the code base?
– How can we QA the fix to confirm it has been correctly incorporated into the code base?
– How quickly does this change need to be rolled out? (E.g. security patches need immediate response, changes such as Mastercard 2-Series compatibility can be scheduled in advance)

This blog post will answer each of these questions individually, using the example of the Magento 2-Series compatibility changes.

Which versions of Magento are affected?

The fix for 2-Series compatibility was incorporated into Magento 1 Enterprise Edition version 1.14.3.0 (Community Edition version 1.9.3.0) and Magento 2 version 2.1.3. Therefore, any client running Magento 1 less than version 1.14.3.0 or Magento 2 less than version 2.1.3 is affected.

What options are available to remediate the issue?

The issue can be remediated by upgrading the Magento code base to a version that includes the fix, or applying a Magento supplied patch dubbed “SUPEE-8967”. Something Digital prefers upgrading clients to the latest version of Magento whenever possible, but sometimes it is impractical, in which case patches may be applied.

What are the potential pitfalls developers will encounter when applying the required fix to the code base?

Magento is a highly extensible platform. This is a feature that makes it attractive to developers and merchants alike. However, with this flexibility comes the power to make customizations that lead to incompatibility with future Magento updates.

Specifically, in the case of the Mastercard 2-Series patch, there are the following risks (warning, technical jargon follows):

– validation.js, the JavaScript file which validates credit cards may be overridden in the local theme.
– The site may be using a custom payment method that implements its own validation logic, separate from the fix to Mage_Payment_Model_Method_Cc provided by Magento.

How can we QA the fix to confirm it has been correctly incorporated into the code base?

Given this risk, it is important to find a QA process that the can followed to ensure the fix has been applied correctly.

In this case, we can confirm the patch has been applied correctly by ensuring we can get past the “Payment” validation section of checkout. We can use a testing credit card number for this – Authorize.NET lists a couple. If the patch has not been applied correctly, we’ll see an error like the following.

If everything is OK, we’ll get past Magento’s validation and the transaction will be sent off to the payment gateway.

How quickly does this change need to be rolled out?

Sometimes, these types of changes need to be applied very quickly. For example, when the shoplift vulnerability was announced, SD worked to get its client base patched as quickly as possible.

In the case of the Mastercard 2-Series, there was roughly a one month window over which SD could review and roll out the patch.

Talk to Us

We’d love to tell you more or answer any question you have about Mastercard 2-Series compatibility, or our process in general. Contact us if you’d like to hear more. We’re looking forward to hearing from you!

Rolling Out MasterCard 2-Series Compatibility at SD – Part 1

Starting in June 2017, MasterCard 2-Series credit cards will start to appear in the wild.

This is a new line of MasterCard credit cards that start with the number “2” (previously MasterCard’s had started with the number “5”).

Some versions of Magento 1 and 2 contain credit card validation logic that will flag these credit cards as invalid, preventing users with 2-Series cards from completing checkout.

Here, we’ll take a look at how Something Digital is rolling out these types of fixes across its SEG client base.

Research

Whenever an update affecting SD’s entire client base is announced, the first step is to research the issue. A few questions always need to be answered:

– Which versions of Magento are affected?
– What options are available to remediate the issue?
– What are the potential pitfalls developers will encounter when applying the required fix to the code base?
– How can we QA the fix to confirm it has been correctly incorporated into the code base?
– How quickly does this change need to be deployed?

The Patch Assessment

Once SD has thoroughly researched the issue, a patch assessment is prepared. The intention of the patch assessment is two-fold:

– Collect relevant details on the change into a document that can be circulated to SEG clients.
– Document technical implementation process so that it can be executed on by developers and QA.

Execution

Next, we circulate the patch assessment to our client base. Our Strategic Engagement Managers are of course available to answer any questions as needed.

Once the information has been circulated, SD moves forward with implementation, following the plan documented in the patch assessment.

Conclusion

From a high level, that sums up SD’s general process for rolling out updates like MasterCard 2-Series compatibility that impact its entire Magento client base.

In part two of this series we’ll look at how this process is implemented specifically using the example of the Mastercard 2-Series compatibility changes.

Talk to Us

We’d love to tell you more or answer any questions you have about Mastercard 2-Series compatibility, or our process in general. Contact us if you’d like to hear more. We’re looking forward to hearing from you!

How SD Monitors Your Magento Site’s Health

Does your agency know when something goes wrong on your Magento store?

At Something Digital, we developed a custom Magento healthcheck module aimed at solving exactly that problem.

The module’s core healthchecks are focused on monitoring several critical security protections. For example, we check that the /downloader directory (a common brute-force attack vector for Magento 1 stores) is not publicly available.

However, the module was built with extensibility in mind and allows custom health checks which are relevant to the requirements of individual merchants to be added.

For the technically-oriented crowd, the module features a simple “healthcheck” endpoint which returns a yes / no response. We leverage Pingdom’s reliable uptime monitoring service to regularly hit the endpoint. If anything goes wrong, a log entry is generated on the server with additional details about the incident and Pingdom sends us an alert, so that we can investigate.

The module has been rolled out widely across Something Digital’s client base.

If you’d like to learn more about our health check module or our process in general, contact us. We look forward to hearing from you!