What is e-commerce?

When we hear mention of e-commerce, we tend to most readily think of online shopping in the form of retail sales direct to consumers via web sites and mobile apps, known as “B2C” or “Business To Consumer” sales. And online retail stores are certainly becoming more prevalent, with it becoming more and more accessible for even sole traders to establish an online retail footing – last year (2019) over $600 billion dollars were spent online in the US alone – that’s greater than the  total GDP of countries such as Sweden and Austria.

However, modern e-commerce encompasses a broader network of activities and services relating to electronically buying or selling of products on online services or over the Internet, including “B2B” (Business To Business) and “C2C” (Consumer To Consumer”) transactions and platforms. E-commerce has grown swiftly to become a pivotal element for the successful development of many businesses in the 21st Century. It allows even small businesses to offer 24-hour services to their customers, broadens their access and customer basis, and offers a relatively low cost infrastructure and a faster way of doing business compared to physical premises.

For the e-commerce industry, website security is a particularly important topic. E-commerce websites face all the same dangers as any other websites, but the stakes are often higher, because online customers must have access to and transmit payment details – such as a credit card – in some form in order to complete a transaction. This creates both a tempting target for hackers, drawing greater scrutiny of e-commerce sites, as well as introducing additional potential vulnerability types within e-commerce sites. This makes for a heady mix.

Specific e-commerce dangers

So what specific dangers do e-commerce sites face? Primarily, e-commerce sites of all sizes are susceptible to attack because they process credit card information, email addresses, and passwords for user accounts. If not properly secured, credit card numbers and other data can be stolen by attackers, leaving financial impact and loss of reputation for the e-commerce provider. Markets on the so-called “dark web” that sell stolen information can wreak havoc by enabling third parties to charge money to someone’s account using their stolen details, or even to steal their identity, opening loans, mortgages and other borrowings in their name, piling them in debt and destroying their credit rating.

When performing a transaction, it is therefore vital for users to feel confident that the website is a legitimate business and will deliver as promised – and for that confidence to be well placed – and to be able to gain assurance that their privacy is guaranteed, with all their payment information, contact details and other personal or sensitive information securely stored and transmitted.

Attack Vectors

The Payment Card Industry (PCI) is so concerned about the security of online e-commerce following repeated exploits over time that they have established a set of standards governing how e-commerce sites should be secured, known as collectively as their Digital Security Standard (DSS). The PCI DSS is designed to be able to apply to any company which processes and stores customer payment card data, by obligating the company to follow 12 criteria across six security areas. Key security measures including vulnerability scanning mandated and assessed annually.

The possible target areas where an attacker can attempt to attack a payment transaction or stored sensitive and credit card data are:

• The client (shopper) – the attacker is able to use methods such as social engineering to gain access to the customer credit card details. One such example is to host a domain that is superficially similar to a reputable supplier, but with a typo or similar Unicode character replacement in the domain name and which masquerades as the trusted domain (e.g. “www. Eb4y.com”). If the attacker can get a customer to visit this site via a link, and to submit their credit card details or password believing it is the real site, information theft is possible.
• The client (shopper)’s computer – the attacker can also target shoppers’ computers using attacks including malware, installed as a result of phishing or social engineering attacks. The malware can include malicious functions such as keyloggers that record passwords the user types and sends them over the web to an attacker’s system for capture.
• The Network connection between shopper and website’s server – the attacker can sometimes perform a Man In The Middle (MITM) attack where they sniff traffic on the connection between client and server and record data such as credit card information in transit. Secure Sockets Layer (SSL) encryption has generally solved the problem of credit card numbers being intercepted in transit between the consumer and the merchant but  weaknesses in session negotiation and SSL transport protocols are documented and do exist and can be exploited by a sufficiently motivated and resourced attacker.
• The website’s server – The majority of vulnerabilities in the e-commerce process relate to the website that hosts the e-commerce site. This is because if compromised the attacker doesn’t just get access to a single user’s details (as they would targeting a single user or sniffing their network traffic) but potentially the entire data set of the store, including up to hundreds of thousands of identities and credit card numbers for the largest vendors.
• Third party software vendors – attackers area also able to occasionally exploit security weaknesses in software vendors, such as shopping cart providers. One specific example might be to insert malware such as malicious JavaScript in shopping card code that ships to hundreds of vendors. An unwitting vendor then serves this JavaScript to customers believing it to be legitimate functional code, and all their client’s find their credit card details sent without their knowledge to an attacker’s server when they enter them on the online store to perform payment.

As we can see, there’s a broad range of attack vectors that can be targeted by an attacker with malicious intent. However in this article we will focus on vulnerabilities relating to web attack vectors and the web server because this is the area that the online vendor is most directly responsible for, as well as where the majority of attacks are currently targeted. We’ll also look at how vulnerability scanning can help in providing assurance in the security of an e-commerce site, but its worth bearing in mind that there are other attack vectors, as above.

E-Commerce Website Attack Vectors

One of the most prevalent type of vulnerabilities in e-commerce sites is vulnerabilities within the third-party software used for the provision of e-commerce services shopping carts etc. Software and platforms such as Woocommerce, Shopify, Magento, and Drupal Commerce all provide website operators with packages that offer virtual “point of sale” functionality needed for running an online store, including “basket” functionality, stock management, tax calculation, order placement and payment processing or integration. Unfortunately these platforms and software packages are prone to software errors and vulnerabilities, just as all code is.

However, generally patching these systems is relatively simple and can act as a relatively robust measure so long as it is performed regularly. But criminals aren’t just attacking vulnerabilities that have been discovered, published as CVEs, and patched in the latest versions – they are also targeting vulnerabilities known as “zero days” – bugs in the shopping carts that are not yet reported or published (and hence not patched) as well as vulnerabilities in the specific integration with that store-front that a vendor’s website offers, as well as other vulnerabilities in a vendor’s website that can be exploited to target the store-front. These are the same vulnerabilities in general that can be found in any other web application (SQL injection, cross-site scripting etc.), although some are specific to e-commerce stores. Below we’ll look at some of the primary vulnerability types and the risks they present:

SQL Injection

SQL injection refers to the insertion of SQL language meta-characters by a malicious user into a web request – if a system is vulnerable these meta-characters are passed to and executed by the back-end database, changing application behaviour from that which is intended by the developer. One example is sending in the single-quote (‘) character in order to mark the start of a code block, after which a user can paste in arbitrary SQL commands to execute on the server, such as “show me all users’ passwords”. The results from an SQL injection attack on a vulnerable site may range from a detailed error message, which discloses the back-end technology being used, or allowing the attacker to access restricted areas of the site or it may even allow the execution of operating system commands directly, allowing partial total  compromise of the server system.

Click-Jacking and Frame-jacking

Click-jacking is a malicious technique of tricking a user into clicking on something different from what the user perceives – the user believes that they are interacting with a trusted website but are actually interacting with an attacker-controlled resource. A page is “click-jacked” when an attacker is able to cause a user’s browser to load another page over it in a transparent layer, something that is made possible due to the complexity of functionality in modern dynamic web technologies. The unsuspecting users think that they are entering text on the lower layer – the visible, trusted site – while they are actually entering text and performing actions on the invisible page. On an e-commerce site this can mean a user types in their password or credit card number and inadvertently delivers it directly to an attacker.

While technical implementation of these attacks may be challenging due to cross-browser incompatibilities, a number of tools exist that offer fully automated exploitation of clients on vulnerable websites.

Client-Side Validation of Parameters (Price Manipulation)

Parameter tampering is a vulnerability that may affect any website, however the exploit (“price manipulation”) is largely unique to online shopping carts and payment gateways. A website is vulnerable if it places undue reliance on or trust in client-side validation, or fails to validate user input on the server side.

For example, we can imagine a link being clicked on that contains parameters relating to the order, such as:

https://www.e-commerce-store.com/store/addToBasket?productId=111122&qty=4&price=29.99

If the server takes the “price” argument as authoritative for the purchase, and fails to validate or compare this to expected price when processing the order, it lays the site open to malicious action. An attacker can use a web application proxy, CLI tool (e.g. curl) or direct request manipulation to simply modify the amount that is payable in the URL and purchase the item for 0.01 instead of the intended 29.99. Examples of this seen “in the wild” include CVE-2019-14978.

Insecure Direct Object Reference (IDOR)

Insecure Direct Object References or IDOR occur when an application takes input from the user and uses it to retrieve an internal object such as a file or database key without performing sufficient authorization. In these cases, the attacker can then make changes in the references to get access to unauthorized data.

For example, imagine that an attacker is browsing an e-commerce site and notices that when they click on a link to display the contents of their shopping basket there is a link in the form:

https://www.e-commerce-store.com/store/showBasket?userId=333344

That is, the userID is passed in as a parameter to the web store. When an attacker sees this, they are instinctively going to wonder what happens if they increment the userID or change it to a different value – will they then have access to another user’s shopping basket, for example? A common flaw is for developers to perform a check that a user is logged in and a valid user before displaying the shopping basket, but failing to verify that the userID whose shopping basket is being requested matches or belongs to the user requesting it.

JavaScript card skimming (via DOM XSS)

DOM Based XSS is a Cross-Site Scripting attack wherein the attack payload is executed as a result of modifying the DOM (the addressable model of the webpage) in the victim’s browser, so that the client side code runs in an “unexpected” (and typically malicious) manner. Unlike regular XSS, the page itself (the HTTP response) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

To illustrate this, imagine an example of a page that is invoked with a URL such as:

http://www.e-commerce.site/page.html?default=123456

A DOM Based XSS attack against this page can be accomplished by sending the following URL to a victim:

http://www.e-commerce.site/page.html?default=<script>alert(document.cookie)</script>

When the victim clicks on this link, the browser sends a request for:

/page.html?default=<script>alert(document.cookie)</script>

to www.e-commerce.site (in this example, a legitimate and trusted e-commerce site). The server responds with the page containing the above JavaScript code included. The browser proceeds to create a DOM object for the page, in which the document.location object contains the string:

http://www.e-commerce.site/page.html?default=<script>alert(document.cookie)</script>

The original JavaScript code in the page does not expect the default parameter to contain HTML markup, and as such it simply echoes it into the page (DOM) at runtime. The browser then renders the resulting page and executes the attacker’s script:

alert(document.cookie)

In this example, the payload simply displays a cookie, but in a real exploit, the attacker may send the user’s session cookie to a server they control, or send details such as card numbers in the same way.

JavaScript card skimming (via included Third-Party Scripts)

In the above example, an attacker has targeted only an individual user, but this is relatively time-consuming. Even pasting DOM XSS links at so-called online “watering-holes” where they may be clicked on by multiple users, the effort is still significant for minimal reward. But what if the attacker could target all users of the site at once?

If an attacker is able to get malicious third-party JavaScript served to the customers of a trusted e-commerce site when they access it, then they can intercept and harvest user details such as credit card details from their browser. This is exactly what has happened on major e-commerce platforms including Magento. Typically, the malicious code may be two steps removed from the e-commerce site – that is the store operator uses the third-party “shopping cart” software (such as Magento) which in turn loads JavaScript code from a third party to deliver specific functionality.

If a hacker is able to insert malicious code into the third-party library, they infect all the shopping card provider software that uses it, and in turn all the e-commerce sites using that shopping card provider. JavaScript inclusion is widespread and often several “layers” of inheritance deep, so essentially the issue is “supplier management” and trust – ensuring that the code used by the code used by the code that you use, is secure.

Subdomain takeover

Subdomain takeover is a process of registering a non-existing domain name to gain control over another domain. The most common scenario of this process follows:

1. Domain name (e.g., sub.e-commerce.com) uses a CNAME record to another domain (e.g., sub.e-commerce.com CNAME anotherdomain.com)
2. At some point in time, anotherdomain.com expires and is available for registration by anyone
3. Since the CNAME record is not deleted from example.com DNS zone, anyone who registers anotherdomain.com has full control over sub.example.com

The implications of the subdomain takeover can be pretty significant. Using a subdomain takeover, an attacker can perform multiple attacks, including stealing user cookies via XSS and gaining login to their accounts on the e-commerce site affected.

Weak Authentication and Authorization

If an e-commerce website operates an authentication mechanism that fails to prohibit multiple failed logins for a given account, then it is possible for an attacker to perform a brute-force login attack. A website will be particularly vulnerable if it permits weak passwords. The “slow” way of doing this is to perform the attack completely blind and to simply try random usernames and passwords until one succeeds. However, many websites permit username enumeration – that is they allow an attacker to find out a list of valid usernames. One way in which they do this is to test registration endpoints for response discrepancy – for example if an attacker tries to register the username “dog” and the server replies that the username is already in use, they know that “dog” is a valid user. By repeatedly performing this check, they are able to build up a list of valid usernames, and reduce the problem space to guessing passwords, starting with those that are universally most common.

A variant of this weakness is the ability of an attacker to perform a variety of a Denial of Service attack – if a website is configured to lock accounts after more than three failed login attempts as a protection measure against the above attack, then an attacker can attempt multiple logins on all account names they have enumerated, and lock the real users out of their own accounts.

Pharming & Server-side masquerading

Masquerading makes a user believe that the entity they are communicating with is a different entity. One such example is to host a domain that is superficially similar to a reputable supplier, but with a typo or similar Unicode character replacement in the domain name and which masquerades as the trusted domain (e.g. “www. Eb4y.com”). If the attacker can get a customer to visit this site via a link, and to submit their credit card details or password believing it is the real site, information theft is possible.

Denial of Service (DoS) and Distributed Denial of Service (DDoS)

Unlike many of the attacks above, that threaten the confidentiality of integrity of customer data, denial of service attacks affect the availability of an e-commerce providers services. In a denial-of-service attack (DoS attack) an attacker seeks to make a target e-commerce site unavailable to its intended users by temporarily or indefinitely disrupting its services. This is typically accomplished by flooding the targeted website with superfluous requests in an attempt to overload systems and prevent some or all legitimate requests from being fulfilled.

One variant of this that may be seen with larger e-commerce providers is to use Denial of Service to take an e-commerce provider offline. In this state the website owner cannot take any revenue. The attacker then lifts the DoS attack and sends a ransom request to the site owner, threatening to resume the attack unless payment is made. The rise of botnets formed of compromised victim machines makes this threat more readily accessible to relatively lower skilled attackers than previously was the case.

How to Protect against e-commerce vulnerabilities

Patch & Update Software

The most common attack vectors can be addressed by ensuring that where third-party shopfront software is used, that it is patched and up to date regularly, and that staff subscribe to mailing lists for alerts relating to more urgent critical security patching in between these regular updates.

Offload Payment Risk

Rather than storing and processing payment information such as credit card data, one option is to offload the processing (and incumbent risk) to a third-party payment provider. Under this arrangement, the store integrates with a payment gateway operating as a merchant service provided by an off-site e-commerce application service provider. Payment data is sent directly from the client to the payment gateway and does not transit or get stored on the e-commerce site at all.

Review Third Party Libraries

Recent exploits have shown that it is critical that website operators review and are aware of which client-side libraries (e.g. JavaScript) they are serving to their customers, either directly from their own servers, or as referred resources. Website operators may find it surprising how many of these libraries have accumulated on their site over the years, delivering functionality such as marketing and tracking. Each library included increases the risk of compromise.

DDoS Mitigation

Larger e-commerce providers may want to consider options for DDoS mitigation such as the use of a screening/scrubbing service from a cloud provider, based on proxy/Content Delivery Network (CDN) structure to mitigate DDoS attacks at the network edge.

Brand Protection & Account Takeover Prevention

If your brand is well known and likely to be used in attacks involving masquerading and watering-hole attacks, it may worthwhile investigating newer services such as Digital Shadows that claim to offer Brand Protection, Identity Protection and Account Takeover Prevention services on a commercial basis.

WAF

A well configured and tuned Web Application Firewall or WAF sits at your network edge and is able to mitigate many common attack types including many forms of injection attack such as XSS and SQLi by filtering individual requests at the application level. They do not provide complete mitigation, but they typically form a useful component in a defence in depth framework.

Vulnerability scanning

Finally, vulnerability scanning is an essential measure recommended by PCI DSS and others for ensuring that your e-commerce site is free of vulnerabilities. PCI DSS require that an e-commerce site operator perform both internal and external vulnerability scans to detect both infrastructure-layer and web-application layer vulnerabilities.

How can AppCheck help?

AppCheck is a leading web application scanner that automates the discovery of security flaws within your websites, applications, network, and cloud infrastructure. Assessments can be conducted throughout the application life cycle from development to production. AppCheck integrates with common development tools such as JIRA and TeamCity and includes a JSON API to allow integration with other tools.

Specific checks performed by AppCheck that help detect issues with and protect your e-commerce sites include:

1. Pre-defined templates for e-commerce sites, including dedicated profiles for card skimming detection, subdomain takeover and Magento shopping card vulnerabilities;
2. Custom detection from first principles of many common vulnerability types, ensuring that “zero-day” vulnerabilities can be detected even where not previously known of or published;
3. All standard OWASP Top 10 checks including checks for common e-commerce risks including SQLi and Cross-Site Scripting (XSS)
4. Checks for weak passwords on interfaces; and
5. Checking that web applications implement appropriate HTTP headers to protect e-commerce sites against frame-jacking.

If you’re interested to see what vulnerabilities AppCheck can pick up in your website, take advantage of our free one-off vulnerability scan below.