Categories
In today’s world, where virtual lives are taking over the real ones, the only way for a business to thrive is by establishing an online presence. With more and more retail stores adopting digitization every day, the e-commerce industry has never been more successful and popular than it is in the current times.
According to the data provided by Statista, e-commerce revenue is projected to grow to a whopping $5.4 trillion by 2022.
These days, there are hundreds and thousands of e-commerce applications catering to a diverse customer base. While the use of these applications has significantly contributed to the success of several businesses and companies, they have also provided cyber criminals with a lucrative target. Most e-commerce applications are often riddled with various vulnerabilities that could lead to critical security and privacy issues.
After conducting web application security assessments for numerous e-commerce applications, Kratikal’s VAPT team has come across an array of unique and interesting vulnerabilities with the potential of disrupting a company’s business operations. So, here is a specially curated list of the top 5 high-risk vulnerabilities we found in various e-commerce applications.
Table of Content
#1 Parameter Tampering
Parameter tampering is a critical vulnerability, which can lead to price manipulation and is often found in an e-commerce application’s online payment gateways and shopping carts. An application is vulnerable to price manipulation or parameter tampering if its server places undue trust in client-side validation or does not validate user input on the server-side while processing an order.
Usually, the total payable amount for the order placed is stored in a hidden HTML field of a dynamically generated web page. For instance, an order is placed on an e-commerce application by clicking on the link that contains certain parameters related to the order like:
https://www.e-commerce-store.com/order/addTocart?productId=12345&qty=2&price=3200
Malicious actors can use direct request manipulation or a web application proxy like Achilles or CLI tool to modify the total payable amount when the order is processed. By exploiting this vulnerability, attackers can:
- purchase any item for ₹1 or any other value of yours
- get a refund of the full amount even if the item is purchased for just ₹1
#2 Insecure Direct Object Reference (IDOR)
Counted amongst the most serious vulnerabilities in e-commerce applications, IDOR takes place when an application accepts input from a user and uses that input to retrieve a database key or a file without sufficient authorization. When this happens, a malicious actor can make certain changes in the references and gain access to unauthorized data.
For example, while browsing an e-commerce application, an attacker notices that when they click on a link to place an order, there is a link in the form like:
https://www.e-commerce-store.com/order/addTocart?pmode=cod&qty=2&price=3200
Here, the mode of payment (pmode=cod) has been included as a parameter. In this case, the attacker can modify the mode of payment to prepaid (pmode=prepaid) like:
https://www.e-commerce-store.com/order/addTocart?pmode=prepaid&qty=2&price=3200
By doing this, anyone can place a COD order and pass it off as a prepaid order, essentially purchasing the goods for free.
Additionally, malicious actors can also misuse this vulnerability to cancel the order of other users and perform various other malicious activities.
#3 Unvalidated Redirects and Forwards
The possibility of unvalidated redirects and forwards arises when an e-commerce application accepts untrusted inputs that can cause the application to redirect a request to a URL included in the untrusted inputs. By modifying the untrusted URL input in a way where it takes users to a malicious site and attackers can launch sophisticated phishing attacks and successfully steal user credentials.
As the server link contained in the modified URL stays identical to the original site, these phishing attempts look legitimate and are more likely to succeed. This vulnerability can also be exploited to craft a malicious URL capable of passing the application’s access control check, which can enable attackers to access privileged functions.
#4 Local File Inclusion
Local File Inclusion (LFI) is the process of including files locally present on the server by exploiting the vulnerable inclusion procedures implemented in an e-commerce application. This vulnerability enables the attackers to trick an e-commerce application into either exposing or running files on a web server. LFI occurs due to the improper sanitization of the paths passed to “include” statements.
Attackers can exploit this vulnerability to pull any file from the server including password files, database files and sensitive user data. An LFI attack can result in information disclosure, cross-site scripting (XSS) or remote code execution.
For example, if an e-commerce application uses a code that includes a file’s name in the URL such as:
https://www.e-commerce-store.com/?module=contact.php
A malicious actor can change the URL to something like this:
https://www.e-commerce-store.com/?module=/etc/passwd
In the absence of proper filtering processes, the web server will expose the sensitive content of the /etc/passwd file.
#5 Cross-site Request Forgery
Using Cross-site Request Forgery (CSRF), malicious actors can send maliciously crafted requests to get users to unknowingly perform any action by getting them to simply click on the requests. Through CSRF attacks, malicious actors make a target system carry out a function via the target user’s browser without the user’s knowledge. The impact of successful CSRF attacks can vary based on the privileges held by victim users.
Also known as Session Riding, XSRF or Sea Surf, CSRF exploits the fact that an e-commerce application completely trusts a user once the identity of that user has been confirmed. These attacks can have devastating consequences such as unauthorized fund transfers, data theft and changed passwords.
In the case of e-commerce applications, attackers can also use CSRF attacks to cancel the delivery of another user. For example, a typical ‘cancel order’ request might look like:
https://www.e-commerce-store.com/myorder/cancel?orderid=3245&userid=1234
An attacker can disguise this URL in an email like:
<img src = “https://www.e-commerce-store.com/myorder/cancel?orderid=3245&userid=1234” width=“0” height= “0”>
Once a target user clicks on this disguised request, the order cancellation is carried out without the knowledge of the user.
Now that we have discussed the top 5 high-risk vulnerabilities found in e-commerce applications, you must understand how severely your business can be disrupted if an attacker decides to target your application.
To avoid some devastating consequences, it is highly advisable to make sure you detect any vulnerabilities in your e-commerce application before malicious actors have a chance to exploit them. You can do that by conducting periodic web application security testing and fixing all the vulnerabilities detected immediately.
Being proactive is the only way to keep your application secure!
WAIT!
It’s not over yet…
Here’s a chance to become a BUG BUSTER!
Leave the best recommendations for one or more of these vulnerabilities in the comments section below and win your BUG BUSTER certificate!
About The Author
Unvalidated Redirects and Forwards
Safe use of redirects and forwards can be done in a number of ways: Simply avoid using redirects and forwards.
If used, do not allow the URL as user input for the destination. This can usually be done. In this case, you should have a method to validate the URL.
If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
IDOR
– Use per user or per session indirect object references: This prevents attackers from directly targeting unauthorized resources. The application has to map the per-user indirect reference back to the actual database key on the server.
CSRF
Anti-CSRF tokens must be implemented and the same site flag in a cookie should be set.
1- Parameter Tampering attack – Developer have to implement input validation mechanism at both client and Server side and also implement access control check.
2- Insecure Direct Object Reference ( IDOR ) –
Use secure hashing mechanism/ process instead sending the ID Value in plain text.
3- Unvalidated Redirects and Forwards – Do not allowed url as Input as destination.
Sanitization and validation on input and Validation of the url in destination.
4- Local File Inclusion – Save the file paths in a secure database and give an ID for every single one.
Use validated and secure files only.
Don’t include files on a web server that can be compromised, use a database instead.
5- Cross-site Request Forgery – Send unique csrf token in request header.
Double submission of cookies in request header.
Set cookie same-site attribute as lax of strict.
Parameter Tempering Attack Mitigation :
1)Use a whitelist format for the application’s inputs.
2)Use web application firewalls for utmost protection.
3)Encrypt the session cookies to prevent tampering.
3)If the cookie originated from the client-side, such as a referrer it should not be used to make any security decisions.
4)Avoid including parameters into the query string.
IDOR Mitigation:
1)Developers should avoid displaying private object references such as keys or file names.
2)Validation of Parameters should be properly implemented.
3)Verification of all the Referenced objects should be done.
4)Tokens should be generated in such a way that it should only be mapped to the user and should not be public.
Unvalidated Redirects and Forwards Mitigation:
1)Simply avoid using redirects and forwards.
2)If used, do not allow the url as user input for the destination. This can usually be done. In this case, you should have a method to validate a URL.
3)If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
4)It is recommended that any such destination input be mapped to a value, rather than the actual URL or portion of the URL, and that server side code translate this value to the target URL.
5)Sanitize input by creating a list of trusted URLs (lists of hosts or a regex).
6)Force all redirects to first go through a page notifying users that they are leaving your site, and have them click a link to confirm.
Local File Inclusion Mitigation:
1)Developer should implement whitelist and ignore others filename and path. You can see the same example in the image below where the web application strictly detects and locate only those specific files that given by the developer.
2)The input entered by the user must come into the server after it is encoded.
3)Other users should not have read, write and execute permissions.
4)allow_url_fopen and allow_url_include should be disable.
Cross Site Request Forgery Mitigation:
1) Implement CSRF Token.
2) Use the SameSite Flag in Cookies.