Today we decided to discuss the topic of information security. We publish the translation of the Kunal pandey article , detect vulnerabilities and work ahead of the curve!
Introduction
Theft of personal data (PII) of the user has become commonplace for us. Attackers find many ways to obtain personal data, for example, using XSS and IDOR vulnerabilities, API endpoint disclosure, and more.
The scenario described in this article can be tested by simply observing the behavior of the API endpoint. In the example below, by calling the API, any user's personal information can be stored in other API endpoints.
Explanation
In one of the private programs on the HackerOne Bug Bounty platform , where I was invited, it was proposed to test the store's portal, namely the section for the seller's work. Here, store employees can send any customer a "Place order" invitation. To get the information they need, the seller sends this request to customers by email or using a QR code.
After receiving a link with an invitation to make a payment, the buyer goes to: payment-na.examle.com/0811ebf4-d7d0-ba31-9ce68648a5a9 and fills in the required data.
When intercepting a request, Burp Suite detects a POST API endpoint that contains the entered data.
Request
POST /na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 HTTP/1.1
Host: payments-na.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json;charset=utf-8
X-Cdc-Client: 2.15.45
Content-Length: 125
Origin: https://payments-na.example.com
DNT: 1
Connection: close
Referer: https://payments-na.example.com
{"browser_prefilled":[],"customer_details":{"country":"US"..............},"skipped_fields":[],"user_submitted":true,"action":"continueAddressUnverified"}
Answer
After filling out the form, the operation is completed. Done!
During the POST method to payments-na.example.com/na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 all information is saved, payment has been made.
Operation stage
Users or attackers may find another section of the portal where they can use the Place Order function, just like in the method described above, and receive the following payment link: payment-na.examle.com/fa5daba4-5d50-8f80 –9eb1-ebia3ea6d665 .
In this case, just fill out the form, intercept the request in Burp Suite, receive a POST request to payment-na.example.com/na/customer/client/v1/session/xxxx , download the generated API endpoint and discard other requests to we didn't send them.
Received API endpoint: payment-na.example.com/na/customer/client/v1/session/96afd42f-4281-4529-9b8c-3ba70b0f000b .
For further testing, this endpoint can also be used using the GET method in the browser. Below is a screenshot of the resulting API endpoint:
As we can see, no information has been added yet and no parameters have been specified.
Now we will get this API link and send it to other users who have filled out their order details. As soon as the victim clicks on this API link, all personal data from the previous submission that was stored here ( / na / customer / client / v1 / session / 002420e4-e031-47aa-8d94-6f7c40c248c7 ) will be copied to the specified endpoint API: / na / customer / client / v1 / session / 96afd42f-4281-4529-9b8c-3ba70b0f000b .
After the victim clicks on the API link we sent you, all of the user's personal data will be copied to this endpoint.
From the victim's side: It is
enough for an attacker to simply visit this API endpoint in incognito mode, and there will be copied victim's data (email, address, etc.).
Victim's personal data:
This way, attackers could obtain the personal data of any client simply by creating a new session API endpoint and sending it to other users.
Working on bugs
The portal development team removed the GET method, tied it to the POST method, and added the Authorization Token header to the above POST method request, where it will authenticate from the server every time.
This eliminated the possibility of repeating the scenario described above - an attack with copying user's personal data via the API.
Key points
1. The scenarios for such attacks can be different, my example is just one of them. Pay attention to these vulnerabilities and try to dig deeper to create a similar scenario: how else could an attacker attack you.
2. In the example described, the attacker's API was authenticated to the victim's API endpoint because there was no validation of the authorization token header. This allowed the server to copy clients' personal data to another API endpoint.
Course of events:
July 22: I reported the vulnerability to the portal team.
July 23: The report was reviewed by the team and the severity was set to Medium.
July 23: Received a reward of $ 500.
July 27: Problem resolved, report compiled.