Today we decided to discuss the topic of information security. We publish the translation articles Kunal pandey, detecting vulnerabilities and staying ahead of the curve!
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.
In one of the private programs on the Bug Bounty platform HackerOne, where I was invited, it was proposed to test the store 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, in Burp Suite the POST method API endpoint is discovered that contains the input.
POST /na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 HTTP/1.1
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-Encoding: gzip, deflate
After filling out the form, the operation is completed. Done!
During the POST method on payments-na.example.com/na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 all information is saved, payment has been made.
Users or attackers may find another section of the portal where they can use the “Place an order” function, just like in the method described above, and receive the following link to pay: 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 for payment-na.example.com/na/customer/client/v1/session/xxxx, download the generated API endpoint and discard other requests so that we don’t send them.
The resulting 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, the information has not been added yet, and the parameters have not been specified.
Now we will retrieve this API link and send it to other users who have filled in their order details. As soon as the victim clicks on the given API link, all personal data from the previous submission that was saved here (/ na / customer / client / v1 / session / 002420e4-e031-47aa-8d94-6f7c40c248c7) will be copied to the specified API endpoint: / na / customer / client / v1 / session / 96afd42f-4281–4529–9b8c-3ba70b0f000b…
After the victim clicks on the API link we sent you, all 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 the copied victim’s data (email, address, etc.).
Victim’s personal data:
Thus, attackers could obtain the personal information of any client simply by creating a new session API endpoint and sending it to other users.
Work on bugs
The portal development team removed the GET method, bound it to the POST method, and added the authorization token header to the above POST method request, where every time it will authenticate from the server.
This eliminated the possibility of repeating the scenario described above – an attack with copying user’s personal data via the API.
1. The scenarios for such attacks can be different, my example is just one of them. Pay attention to such 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 solved, report compiled.