Hey Guys, I am Samrat Gupta aka Sm4rty, a Security Researcher and a Bug Bounty Hunter. In this blog, I will be explaining how can you find bugs in Shopping Feature of the web application.
Shopping and Billing feature is commonly present in most of the web-application. Testing this features can be quite simple and can infact it can create greater business impact. Below are some ways of testing and finding bugs in the shopping functionality of an web-application.
1. Parameter Tampering/ 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.
How to test for Price Manipulation:
For example, we can imagine a link being clicked on that contains parameters relating to the order, such as:
https://www.store.com/cart?Id=1&qty=2&price=29.99
If the server takes the “price” argument as authoritative for the purchase, and attacker can change the price to say $1 and if the website accepts it, Its vulnerable to Price Manipulation.
Now lets at some Scenarios of Parameter Tampering:
- Changing price of Expensive Product to Cheap one.
- Increasing the quantity of the product at the price of one.
- Changing price of Product to Negative.
- If the Application is using hash, try capturing the hash of cheap price product and replace it when purchasing expensive product.
- If there is any addition cost like tax/something, Change it to negative amount which can reduce the total product price.
Further Read
https://hackerone.com/reports/364843
https://beaglesecurity.com/blog/vulnerability/parameter-tampering.htm
https://cobalt.io/blog/parameter-tampering-vulnerability-using-3-different-approaches
2. Race Conditions:
A race condition is a flaw that produces an unexpected result when the timing of actions impact other actions. An example may be seen on a multi-threaded application where actions are being performed on the same data. Race conditions, by their very nature, are difficult to test for.
How to test for Race Conditions
Usually, race conditions can affect applications that apply mathematical functions like add and subtract, for example money transfers, modifying a product price by applying a gift card or discount voucher, and so on.
User must tamper with the sequence of the events in order to find a race condition vulnerability, like applying the same discount code twice at the same moment, which will result in subtracting the same amount multiplied by two, but this depends very much on the back-end environment.Tip: You can use Burp Turbo Intruder for it.
Lets look at some scenarios of Race Conditions:
- Race Condition while adding product to cart, which can lead to buying multiple items at same price.
- Race Condition while redeeming Gift card or coupon, which can lead to getting multiple discounts with the same coupon/gift card.
Further Read
https://www.veracode.com/security/race-condition
https://hackerone.com/reports/759247
https://hackerone.com/reports/157996
3. Cross Site Request Forgery:
Cross-site request forgery (also known as CSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform. It allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other.
How to test for CSRF
A good methodology to identify CSRF vulnerabilities would be to discover all the endpoints through which the application initiates and executes actions, and apply tests by creating html form for post-based request or url for get-based request. Tip: You can use BurpSuite CSRF POC generator for your ease.
Now lets at some Scenarios of Cross-site request forgery:
- CSRF on Adding Product to Cart.
- CSRF on Deleting Product from Cart.
- CSRF on Changing the address of the Victim.
- CSRF on removing Applied Gift card/Coupon.
Further Read
https://portswigger.net/web-security/csrf
https://hackerone.com/reports/177472
https://hackerone.com/reports/123339
https://hackerone.com/reports/205953
4. Insecure Direct Object Reference:
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.
How to test for IDOR:
For example,Have a look at the url below. If the attacker changes the value of userId from 12 to say 13, and the application displays the cart for the user 13 then its a IDOR vulnerability.
https://www.store.com/cart?userId=200
Now lets at some Scenarios of Cross-site request forgery:
- IDOR to view User Order Information.
- IDOR to delete users Cart items.
- IDOR to view sensitive data such as address, credit card details etc.
Further Read
https://portswigger.net/web-security/access-control/idor
https://hackerone.com/reports/287789
https://zaidmessi.medium.com/idor-allows-to-see-edit-delete-the-cart-of-other-users-f619eb5f2504
5. Click-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. In a nutshell, It can be described as tricking a user into clicking on something different from what the user perceives, potentially revealing confidential information.
How to test for Clickjacking:
You can simply visit the website below to check whether the website is vulnerable to click-jacking. Apart from this you can even use BurpSuite Clickbandit for testing.
Now lets at some Scenarios of Clickjacking Attack:
- Clickjacking on updating name/address page, An attacker can induce victim to update the shipping address to attacker’s address.
- Clickjacking on checkout page, An attacker can make user buy items without their knowledge.
- Clickjacking on adding or deleting products, An attacker can induce victim to add or delete products on shopping cart.
Further Read
https://portswigger.net/web-security/clickjacking
https://hackerone.com/reports/471967
https://hackerone.com/reports/305128
6. Payment Bypass using Response Manipulation:
Response Manipulation means manipulating the response from the server to our browser. In many cases this can be very useful for testing as it can lead to bypasses like authentication bypass, Payment bypass OTP bypass and many other.This can be easily tested by looking into the responses from the web application while performing some validation.
How to test for Response Manipulation:
We can use some proxy like Burpsuite/ZAP to intercept the response from the server. We can then edit the response from false value to true value. For example if the server responds the Validation of Payment with “paid”:”false”, then we can simply try to change the value to “paid”:”true”.
In many cases, there might be some other key pair value like “failed”, “error” or even status code like 4XX. Try to replace it with 200 status code or some other true key pairs.
Further Read
https://infosecwriteups.com/bug-bounty-response-manipulation-leading-to-payment-bypass-cb5fde360b1a
https://hackerone.com/reports/1070510
7. Cleartext Transmission of Sensitive Data:
Some applications transmit passwords and other sensitive data over unencrypted connections, making them vulnerable to interception. To exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim’s network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer.
How to test for Cleartext Transmission of Sensitive Data:
You can use wiershark or similar traffic analysis tool to capture the network traffic of your entire shopping process. If you see any sensitive data such as your Credit card details or address is transmitted in unencrypted http protocol, and is visible in cleartext.
There is a good chance that your data may be leaked as the data will get logged in many places like ISP’s Server, Logs of application server, any third party VPN service, etc.
Further Read
https://cwe.mitre.org/data/definitions/319.html
https://portswigger.net/kb/issues/00300100_cleartext-submission-of-password
https://shahjerry33.medium.com/clear-text-transmission-of-sensitive-data-everything-is-visible-4f2e8bc6673f
Thanks for Reading. Any Suggestions are always welcomed!!
If you haven’t Subscribed yet, Please Do Subscribe. You can Buy me a coffee and Follow me on Twitter.
