OVERVIEW
A large volume of sensitive data is exchanged on e-commerce websites, making them a popular target for cybercriminals. Penetrating your e-commerce website is the only way you can keep on top of the ever-evolving tactics hackers use to breach your website. In addition to bringing new opportunities for retailers, advances in e-commerce have also led to a growing number of security threats. E-Commerce weaknesses are being exploited more creatively and boldly than ever before.
Scenario
We were asked by the client to perform Web application and Mobile application penetration testing on their e-commerce platform to ensure any vulnerability exists on their e-commerce platform.
Major E-Commerce digital risk
Bots, exploiting known vulnerabilities, Dos attack, spamming, data tempering, malware, brute force attack, MITM. We help them mitigate them all.
What we Found
We found many other risks that are Critical, High, and Medium level risks.
- The Critical Level Risks include Authentication Bypass by Response Manipulation, User Account Takeover, Contact Full Address Disclosure at Checkout Phase, Privilege Escalation Vulnerability, Laravel Telescope Dashboard Publicly Accessible, Admin Panel Authentication Bypass, Insecure Direct Object References (IDOR), Sensitive Data Exposure by Verbose Error Messages, Forced Browsing.
- The High-Level Risks include Laravel Horizon Dashboard Publicly Accessible, Cross-Site Request Forgery, Merchant can self verify their account instead of the Admin User leading to Privilege Escalation.
- The Medium Level Risks include SSL Not Enforced, Outdated Apache Version Used, Weak Password Policy, Sensitive Parameters are susceptible to Brute Force Attack, Email Denial of Service, Host Header Injection, Multiple Registration via Automation, Server Version Disclosure Vulnerability.
Brief about what we found
We discovered the Authentication Bypass by trying to log into the application with the correct mobile number and incorrect password. We manipulated the invalid response with a valid response by stripping off the session_token, token value. Here the main identifiers for an application are the user id and phone number that can be used for authentication bypass.
We also tried logging into the application using our credentials. We changed the user id to any existing user in the application and forwarded the request. It was possible to access another user account. Due to this, we can take over all the user’s accounts existing in the application. This risk is known as User Account Takeover.
We performed mobile application and network penetration testing. By this, we could find the risks which are at Critical, High, and Medium levels.
We helped them to mitigate the following risks.
Privilege Escalation Vulnerability: 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.
Recommendations we suggested
There are three possible approaches to prevent this to happen:
1. Keep critical information on the server side, and only send session IDs to the client.
2. Tamper-proof the data sent to the client, by using a digital signature.
3. Encrypt the data sent to the client, so it is opaque to the client.
Admin Panel Authentication Bypass: The application has an admin panel vulnerable to authentication bypass. The application allows users to access sensitive areas of the application and bypass authentication controls. A lack of proper authentication exposes sensitive data and operations within the application and prevents the logging and tracking of user activity.
Recommendations we suggested
We in-detail recommended they follow the below steps.
1. Proper authentication mechanisms should be put in place to ensure that users are required to authenticate before accessing sensitive data.
2. Multi-factor authentication should also be used to further enhance authentication strength.
Forced Browsing: Forced browsing is an attack where the aim is to enumerate and access resources that are not referenced by the application but are still accessible.
Recommendations we suggested
After testing this risk, we recommended a few steps which are to be followed.
1. Enforce an application URL space allow list and use proper access control.
2. Use proper access control and authorization policies, access is only given to users commensurate with their privileges.
Business Risk we prevented
- Financial loss
- Reputation loss
- Customers being victims of malware
- Application unavailability due to hacking attempts
- Supply chain attack