Demystifying two common misconceptions with e-commerce security

Online shopping has seen a dramatic increase in the months following the Covid-19 outbreak as more and more people opt-out of visiting physical stores. Such a phenomenon does not go unnoticed or without additional consequences. During the same time period, we have seen an increase in the usual scams but also digital skimming, the online equivalent of credit card theft.

As a consumer, you may be hearing different tips on how to shop online safely. A common one is to look for the “https” in the site’s URL, but what exactly does that mean in the case of a compromised site?

As a merchant, processing transactions securely is one of the top requirements in order to achieve SAQ-A level PCI DSS compliance. Many businesses choose to work with a Payment Service Provider (PSP) and use iframe containers. Once again, how do those fare when malicious code is at play?

When it comes to online security there is always a caveat, and the important thing is to understand the sometimes subtle nuances of technology concepts and their limitations.

The padlock

When we visit a website, our browser makes a series of requests to a web server via the HTTP protocol. The server will in turn reply with responses that include the text and images displayed on screen.

There was a time not so long ago when most websites were not using encryption and therefore exposed communications between server and browser. In other words, an attacker could capture sensitive data you might be typing into a website because that data was sent in clear text.

With the adoption of HTTPS, HTTP requests and responses are encrypted via the TLS (Transport Layer Security) protocol, the successor of SSL (Secure Sockets Layers). In addition, HTTPS authenticates web servers such that when you browse to https://www.facebook.com, private and public keys using the site’s SSL certificate are matched to guarantee the legitimacy of the server. (Note: we still commonly use the term “SSL certificate”, but the technology behind it is TLS).

Today, there really is no valid reason for a website not to have an SSL certificate anymore. Not only can they be obtained for free, but browsers will display a warning that could deter people from visiting your website.

One recommendation you might hear about when it comes to shopping online is that if the site is secure, its URL should start with “https://” and include a lock icon on the shopping cart page. While technically this is true, the meaning of ‘secure’ needs to be properly defined.

Indeed, a number of people will wrongly assume that a site using HTTPS is secure, and therefore can be trusted to buy from. The SSL certificate guarantees that the connection to the site is secure (meaning, encrypted) and that the site is who it pretends to be, but that’s it.

To drive the point home, at Malwarebytes we detect thousands of websites that all use HTTPS and are yet dangerous or outright malicious. In fact, when it comes to e-commerce, almost all of the sites that have been injected with a credit card skimmer do use HTTPS.

When a website has been compromised, an SSL certificate does little to guarantee your online safety. This is why it’s important to understand the difference between a secure communication protocol and a secure website.

Websites run on software that can have vulnerabilities and be exploited by threat actors. A hacked site may contain malicious code that controls what you see and do within your browser, whether it uses HTTPS or not.

The irony is that online criminals themselves have adopted SSL certificates too. And there’s not much comfort in knowing that your credit card data has been stolen and exfiltrated ‘safely’.

There is no doubt you should stay away from sites that have not adopted the latest secure communication protocols. However, you should not take for granted that a site is secure (in the sense of safe to shop) simply because you see a padlock.

iframe protection

A number of online shopping sites use a Content Management System (CMS) such as Magento where the checkout page relies on third-party forms to handle sensitive data. The integration is meant to be seamless in order to give shoppers the best experience possible.

One popular option is the iframe container, where a merchant site integrates a third-party script within an iframe on the checkout page. In technical terms, the provider script is inserted within an iframe container where the customer will enter their payment details (i.e. credit card number, month and year expiry and CVV). This means that no cardholder data is stored, processed or transmitted by the merchant.

The same-origin policy (SOP) enforced by modern browsers ensures that code contained in one page can only access data in another page if both web pages have the same origin. In other words, if the merchant site gets hacked, SOP prevents malicious code from stealing data within the protected iframe.

Unfortunately, there are many ways to bypass iframe protection and it usually comes down to having control of what is loaded onto a page. The PCI Security Standards Council states in one of its reports that “If an attacker has compromised the merchant’s website, however, they can create alternative content for the frame, which then allows completion of the payment process as well as creation of a copy of the cardholder data for the attacker.”

In an attack we observed recently, threat actors were targeting Braintree Hosted Fields to inject their very own iframe within the same container after disabling the legitimate one.

As you can see in Figure 2, the legitimate Braintree iframe (braintree-hosted-field_number) has its display property set to none while a malicious iframe (fpmt) takes it place.

This means that the attackers now have direct access to the credit card number field and can steal it once the customer types it in, completely bypassing the iframe container protection.

Containers still have value for merchants as they can help them achieve PCI compliance and also generally augment their overall security posture. However, externalizing the payment process does not mean that your platform is secure from hackers.

Security in layers

There is no absolute in the security field, and if one technology claims to solve all problems it probably is too good to be true.

As the threats targeting online shoppers evolve, so must our response too. Credit card skimmers can target just about any platform and business, but there are some higher risk areas and behaviors. When evaluating a shopping site, you need to look well beyond the HTTPS padlock and even security seals.

• Is the site up to date? While technically this would require scanning the CMS core files to determine their version, some things such as copyright notices showing dates of years past are a giveaway.
• Is this a small ‘mom and pop’ website? Those are generally at greater risk because the owners have fewer resources to invest in security.
• Does the site offer payment options that may be more secure such as a separate payment gateway, or token system?
• Does the checkout page render properly without any odd looking elements? Skimmers often try to inject phishing forms or hijack existing fields, which can sometimes be noticed visually.

After doing due diligence checks on the site, you can still thwart the risk of online skimming by using security software, and in particular browser extensions that can block malicious code from loading. Malwarebytes Browser Guard was designed to filter out ads, scams and malicious content.

As an online merchant, there are a number of security decisions to make when you run a website. It would be difficult to list them all here, but as a general rule it’s good to remember that security is not an end state but a constant process that requires resources. Being proactive to anticipate attacks and have a plan in case of a compromise is also critical.

There are a number of services that provide security hardening and monitoring with varying costs. These can be a good option for a merchant that does not have its own IT team. As a side note, most web developers or web agencies (unless specified otherwise) will only build a website but not provide ongoing security updates and monitoring.

The post Demystifying two common misconceptions with e-commerce security appeared first on Malwarebytes Labs.