How can I tell if the site I shop from is secure?
Payment card breaches concern customers and businesses alike. A recent epidemic of e-commerce breaches is focusing attention on what makes a website more or less secure than others. The old advice of looking for the “security lock” and the “green location bar” are simply not-adequate anymore.
While fully evaluating the security of an e-commerce site is a bit technical and involved, we wanted to provide a simpler resource to help people understand the risks. It isn’t uncommon for a merchant’s compliance department, project manager, or system owner to not know the details of their website. Rather than asking the web developer/maintainer, our idea was to present a simpler procedure that could be quickly used by anyone, even a curious consumer. This method doesn’t require sophisticated security tools or skills, just your browser and a little patience.
Why are “Locks” and “Bars” not enough?
Much of the standard advice on secure shopping focuses on knowing your merchant (good advice) and external technical indicators like “locks” and “bars” which aren’t enough.
- A missing “security lock” is a bad sign; if the site you’re shopping on doesn’t have one, you should leave. But having one is only the first most basic step because anyone, even crooks, can get a security lock for free – https://arstechnica.com/information-technology/2018/03/lets-encrypt-takes-free-wildcard-certificates-live/
- The “green location bar” may have seemed like a good idea to show extra attention to security, but they aren’t really useful. Most companies simply don’t buy the special “EV” certificates, and most people will never see them if they do – https://www.troyhunt.com/extended-validation-certificates-are-dead/
Under-the-covers, many e-commerce websites are insecure
To understand why “locks” and “bars” aren’t enough, it necessary to look beneath the covers at how most e-commerce websites are built.
Merchants want to provide their customers with a rich, full-featured, easy-to-use website and a great shopping experience. They also want to be able to optimize their website using sophisticated analytics and tracking tools. Payment processing is typically a tiny portion of the website commonly implemented a form that accepts card data and directly posts it back to the merchant’s payment processor. A typical e-commerce website embeds third-party scripts from potentially dozens of websites. Every script on the page has visibility into that form. Every third-party website and every change made to them can potentially impact the security of the website and your card data. This is a key selling point for a number of legitimate tracking and web replay software. However, many of these have been shown to have security problems. It’s also exploited by criminals. Yet many website developers are either unaware or unconcerned with this risk and aren’t addressing it.
As a direct consequence of this development style and lack of focus on supply-chain security a number of organized criminal gangs have been using this method to actively exploit e-commerce sites. To date over 100,000 sites have been compromised including Newegg, British Airways, and Ticket Master. These attacks are collectively known as “Magecart”.
For more information on Magecart and the problems with Web Replay software see “Learn More About E-Commerce Insecurity” at the end of this article.
One of the best ways to defend against these attacks and errors is to use IFRAMEs rather that direct-post forms. The IFRAME will effectively sand-box the card entry to the processors site. And while it won’t eliminate all risks, it will provide a significant security boost. Alternatively, a full redirection to the payment processors website will provide a similar defense.
Which types of payment sites are the most secure?
The questions you want to answer for your e-commerce site are,:
- Which of the following scenarios apply
- How secure is the handling of the payment card?
- What is the risk?
|Malicious URL||Merchant URL||Acquirer or Payment Gateway URL|
|How secure is this method?||This site is compromised. Leave immediately.||Less secure||More secure|
|How does this method work?||
The merchant’s website is manipulated by malicious individuals to forward your credit card information to criminals.
Criminals can be quite creative when stealing from you. They may do things like adding code to the merchant website, or to one of the script sites used by the merchant.
The merchant website either directly receives your credit card information or makes the payment form that collects your credit card info.Your credit card info is then forwarded to either (1) the merchant bank (also called the acquirer), or (2) a payment gateway.
This method is vulnerable to attack because there is a much higher chance of the merchant’s systems or its payment form codes being compromised by criminals.
Effort required by the merchant to secure this type of web page is high.
This relies on a concept called IFRAME (inline frame) provided by the acquirer or payment gateway.The IFRAME provides a ‘sandbox’ isolating environment between the merchant website and the ‘frame’ where the credit card info is entered.In this method, the credit card info is not easily accessed or exploited by malicious individuals.
The acquirer or payment gateway is required to be PCI DSS compliant.
Note: All URLs should start with “https://“.
How would you check the security of a website’s payment card input?
This process allows you to look through the website’s code to see how and where they are using IFRAMEs to process payment card data. The procedure is simple and will take you directly to the code we want to look at.
Firstly, once you land on the payment page, press [F12] on your keyboard to display the web code for the page. The code will be in either the Elements tab (Google Chrome and Microsoft Edge) or the Inspector tab (Mozilla Firefox).
Click on each image below to enlarge them and view in greater detail.
1. Right click on the credit card number box and select Inspect Element
2. Your browser will display something like this
3. Search up and down the code in the Inspector field, until you locate the IFRAME
Ensure when you hover your mouse over the piece of IFRAME code, it reflects the credit card number box. Then your IFRAME should have the following:
- An IFRAME tag with a source to another encrypted website, such as <iframe src = ”https://…” . And
- The source web site name is coming from any of the acquirer or payment gateway domains listed below.
4. If you cannot find the IFRAME treat the site as less secure
At this point, if you haven’t located the payment IFRAME or you are uncertain you should treat the site as less secure.
While a detailed deep dive into the technicalities is beyond the scope of this article, if you are a merchant compliance officer, project manager, or system owner and have reached this point you should get a more in-depth analysis from someone skilled in e-commerce security.
List of Canadian Acquirers & Payment Gateways
The following is a partial list of acquirers and processors that provide IFRAME payment page support in Canada.
- Caisse Populaire Desjardins (bambora.com or beanstream.com)
- Own (Eigev.com)
- Global Payments (gtpaysecure.net)
- Moneris (moneris.com)
- PayPal (paypal.com)
- Paysafe (paysafe.com )
- TD Merchant Solutions (bambora.com or beanstream.com)
Note this is not a complete list and there may be other compliant IFRAME payment page providers.
Based on what you find you should be able to answer the following:
Sample Merchant Web Pages
Payment IFRAME example 1
This web site uses an IFRAME to redirect to Paysafe’s payment gateway.
Payment IFRAME example 2 – IFRAME URL to acquirer Moneris
This web site uses an IFRAME to redirect to Moneris’ payment gateway.
Other (non-IFRAME) payment example
This web site uses a web form to collect and process payments.
Non-payment IFRAME example
This web page is using an IFRAME to support web tracking and advertising.
Learn More About E-Commerce Insecurity
The following articles illustrate the security problems faced by many e-commerce websites:
- Magecart and recent examples of evil scripts implicated in e-commerce breaches:
- Newegg https://techcrunch.com/2018/09/19/newegg-credit-card-data-breach/
- British Airways https://www.theregister.co.uk/2018/09/11/british_airways_website_scripts/ and https://www.wired.com/story/british-airways-hack-detaeils
- Ticketmaster https://www.theregister.co.uk/2018/06/27/ticketmaster_support_bot_hack/ and https://www.zdnet.com/article/ticketmaster-breach-was-part-of-a-larger-credit-card-skimming-effort-analysis-shows/
- Magecart infiltrates U.K. online retailer Kitronik payment system https://www.scmagazine.com/home/security-news/uk-online-retailer-kitronik/
- Over 100K e-commerce sites hit by 7 criminal groups using Magecart web-skimming malware https://www.databreachtoday.com/magecart-cybercrime-groups-mass-harvest-payment-card-data-a-11700
- Over 7,000 e-commerce stores compromised https://www.bleepingcomputer.com/news/security/magentocore-malware-found-on-7-339-magento-stores/
- Magecart gangs are exploiting zero-days in e-commerce plug-ins https://threatpost.com/magecart-cybergang-targets-0days-in-third-party-magento-extensions/138547/
- Legitimate tracking/replay software can easily be misconfigured to record your every keystroke on a merchant’s site. This is often shared with unauthorized third-parties