How PayPal’s Braintree Payment Service Illustrates a Fundamental Flaw with iframe-based Security

Getting Paid Online is a Tricky Business

Processing payments online while maintaining the standards mandated by the Payment Card Industry Data Security Standard, commonly known as PCI-DSS, is a daunting task for merchants. Because of the complexity of maintaining a secure, compliant and profitable payment process most online merchants rely on external payment processors such as Paypal, Square, and Stripe, amongst others, to outsource the cost and time associated with accepting payments.

These payment processors use a variety of advanced techniques to ensure that payment information remains secure during transactions. This is essential because hackers and hacker groups like Magecart are highly motivated to find ways to steal that information, causing harm to visitors, merchants and brands.

One such technique, known as ‘foreign iframe enclosures’, ‘hosted fields’ or ‘secure fields’ has been thought of as a best-of-breed solution to the problem of digital skimming. By essentially bringing payment fields from a separate source into the merchant’s website, while at the same time smoothly integrating into the look-and-feel of the site, this technique seems like an ideal way to defeat digital theft. 

Unfortunately, this widely used technique has been shown to be completely ineffective in securing against the sophisticated attack techniques employed by hackers today. Because Magecart and other hackers have adopted such an intense focus on the client-side (i.e., the web browser) of a website new ways to defeat established techniques are being developed every day. 


Outsourcing Compliance with iframes

In April of 2020 it was reported that an online merchant using a ‘hosted fields’ solution provided by PayPal’s BrainTree service had been compromised, something which was previously thought impossible. 

Put briefly, this security technique relies on having a payment processor provide a JavaScript file to include in the merchant’s website that dynamically builds hosted fields to accept payment data. Input fields, or fields for short, are text boxes where shoppers can enter information into a webpage, such as size or quantity of a product, or payment information to complete a transaction.

In the case of hosted fields, the input boxes do not truly exist on the merchant’s web page but are created by the payment processor’s technology and remain separate from the storefront webpage. They are visible to the shopper and appear no different than any other element on the page. They also eliminate the burden of securing and ensuring that the merchant is in compliance with PCI-DSS. This is made possible by a technology known as an iframe, a way to instruct a web browser to basically put content in a box and allow it to work separately from the main webpage.

So how was the attacker able to steal data even though iframes were being used to protect the visitor’s payment data? The answer lies in JavaScript, specifically 3rd party JavaScript, and the immense power it can exert within the web browser. 

Anything is Possible with JavaScript

JavaScript, the language which makes webpages interactive, has no inherent security controls, permissions, or limitations on its ability to interact with the webpage, the shopper’s experience, or their data. This is the case for both first party JavaScript, such as that written by the merchant themselves or code they might integrate into their site provided by a payment processor, and 3rd party JavaScript, which is retrieved from somewhere else on the Internet as the web page loads. 

In this specific case, the attackers were able to introduce — through 3rd party JavaScript — malicious code which replaced the ‘secure’ fields provided by the payment processor with exact replicas that were controlled by the attackers. From the perspective of the shopper, nothing would seem to be different on the page.

Beyond that, the attackers also constructed their fake payment fields such that the information entered would also be accepted by the payment processor as if it had been provided by the payment processor’s own technology. The transaction would appear legitimate, the payment would be completed successfully and the merchant would receive their money.

Putting all of this together, the net result is that the shopper will receive their goods, the merchant will be paid for the transaction, and the attackers will have stolen another credit card for direct fraud or resale on the darkweb. 


An Essential and Insecure Tool for Online Merchants

JavaScript is an integral part of how the web works today, and 3rd party JavaScript is an essential part of any customer-driven website. By providing critical services such as analytics, social media integrations, customer engagement tools and a myriad of other functionality, 3rd party services are one of the most common and most beneficial tools available to online merchants.

Unfortunately, this essential tool also provides an excellent opportunity for hackers to commit crime on a massive scale with a fantastic potential for profit. Because of this, they are motivated to create newer and more innovative ways to steal data from websites, even when those sites are protected by a time-tested and widely trusted technique such as the one described here. 

As merchants, payment processors and really anyone responsible for the security of commerce online evaluates the challenges that we face today, it is essential to reevaluate old ideas and consider the risk that lives within the web browser itself. As the web grows both more vital to business and more complex to secure, it is essential to consider security solutions that not only safeguard those parts of the system within the organization but also solutions that can extend that security to the client-side. 

Scroll