Overview
Penetration testing is a crucial security measure for all e-commerce websites, particularly those developed on the Magento platform. In this case study, we will delve into the process of conducting a pen test on a Magento-based e-commerce website to detect and resolve any potential vulnerabilities. We will discuss the various tools and techniques used during the testing process, as well as the outcomes of the test, and highlight the business risks that we were able to mitigate.
Scenario
To ascertain whether their web application harboured any security flaws or vulnerabilities, we were tasked with conducting a web application penetration test on their Magento-based web application.
Major Magento-based e-commerce website risk
Major e-commerce websites based on Magento are exposed to numerous risks associated with potential cyber-attacks. One of the primary issues is that many Magento sites can be unpatched and susceptible to vulnerabilities, resulting in hackers taking control of systems and stealing customer data. Additionally, weak administrator passwords or easy-to-guess ones give malicious actors an entry point; thus, businesses should ensure that strong passphrases are used. Another major risk is poor website performance due to extensive traffic or malicious bot activity, as this can easily affect the user experience, result in lost sales, and tarnish a company’s reputation with customers. To mitigate these risks, it is paramount for companies utilizing Magento to ensure their systems are secure and properly maintained. Furthermore, best practices should be implemented such as two-factor authentication which strengthens security against threats while also providing IT professionals with the agency they need in safeguarding customer data.
Attack Narrative
Gathering information was the first step in the process. Both passive and active methods were employed to collect data. Afterwards, a comprehensive understanding of the directory structure and mapping of the application was acquired. Additionally, related external sites were identified, HTTP headers were inspected, and information was collected through errors and error pages. The source code was also examined and the documentation was reviewed during this phase. With the information gathered, analysis of the application and its dependencies began, exploring any application vulnerabilities and verifying the security controls in place. Once all the information was gathered and mapped, test cases were prepared according to the flow of the target application. Tools such as Burp Suite Professional, DirSearch, and Nikto were used to identify and exploit vulnerabilities. The suggested test cases were implemented and the report was created.
What we found
We classified the risks we found into three categories I.e., High, Medium, and Low:
- The High-level risks comprise Insecure Direct Object References (IDOR) on Abandoned Carts, Insecure Direct Object References (IDOR) on Product Catalogue Delete, and Privilege Escalation Vulnerability in Email Log Delete.
- The Medium-level risks include Privilege Escalation Vulnerability in Product Transfer Catalogue, Privilege Escalation Vulnerability in Manage Order, Privilege Escalation Vulnerability on Abandoned Carts Log Download, Privilege Escalation Vulnerability using Abandoned Cart, and Privilege Escalation Vulnerability on Staff and Admin Configuration.
- The Low-level risks contain HTTP Strict Transport Header Missing.
Brief about what we found
First, we logged in as both administrators and customer viewers in their respective browsers. We discovered an abandoned cart module when going to the “Sales” tab on the administrator side, which cannot be found on the customer viewer side. When clicking on the “View” option in the “Action” section of the table, all the details regarding the abandoned carts are displayed. We then copied the URL and pasted it on the customer viewer side, finding that the customer user could access the details without permission (Insecure Direct Object References (IDOR) on Abandoned Carts). We also discovered that the customer could delete a product from the catalogue (IDOR on Product Catalogue Delete) by conducting a similar process.
We helped them to mitigate the following risks.
Insecure Direct Object References (IDOR) on Abandoned Carts:
The OWASP guide gives the following description for Insecure Direct Object Reference:
Applications frequently use the actual name or key of an object when generating web pages. Applications do not always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws and code analysis quickly shows whether authorization is properly verified.
Privilege Escalation Vulnerability in Email Log Delete:
Privilege escalation vulnerabilities allow attackers to impersonate other users, or gain permissions they should not have. These vulnerabilities occur when code makes access decisions on the back of untrusted inputs.
HTTP Strict Transport Header Missing:
HTTP Strict Transport Security (also named HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click-through prompts on browsers.
Business Risk we prevented
- Data Exposure.
- Unauthorized alteration of data.
- Price Manipulation.
- A decline in customer acquisition and retention.
- Loss of reputation.
- Financial loss.
