Critical IDOR Flaws in Online Banking Application

Disclaimer: Please be aware that even though some content in screenshots, such as endpoints, parameters, and values, may appear unblurred, it has been altered to comply with my NDA contract and protect client confidentiality while ensuring that the meaning and context remain intact.

Introduction

Recently, during a web assessment of an online banking system, I identified a critical vulnerability that could lead to unauthorized access or manipulation of sensitive information. This flaw presents a significant risk, as it can expose confidential data or permit actions that should be restricted. In the field of cybersecurity, this type of vulnerability is known as IDOR, which I will now briefly define.

Definition of IDOR (Insecure Direct Object Reference)

IDOR is a type of access control vulnerability that occurs when an application allows direct access to objects based on user-supplied input without properly validating whether the user is authorized to access those objects. In simpler terms, it means that one user can potentially access data or perform actions intended for another user by manipulating parameters in the application’s URL or request.

Overview of IDOR Vulnerability Types

This incident highlights the significant risks posed by an IDOR vulnerability and demonstrates how it can be exploited in different forms, such as viewing, generating, and downloading other people's data. Below are the various types of this vulnerability identified:

Unauthorized Access to Customer Details

• Affected Area: Customer Personal Information
• Issue: By altering INFO_CODE parameter, I was able to access sensitive customer details from other user accounts beyond authorized access. This included personal contact information such as international phone numbers, home addresses, email addresses, and other sensitive data that should have been restricted.

Indicative screenshot of request:

Unauthorized Access to Payment Details

• Affected Area: Pending Transactions Details
• Issue: By altering the INFO_CODE_1 parameter, which is related to transaction statuses, I was able to gain unauthorized access to payment details of transactions labeled as pending from other user accounts. This exposure revealed transaction information not meant to be visible to the current user.

Indicative screenshot of request:

Unauthorized Report Generation

• Affected Area: Account Details Report Generation
• Issue: Through manipulation of the INFO_CODE_3 parameter, I was able to generate reports containing account details for other user accounts. After sending the request to generate the report, a link from the /fetchdata/retrievefile.aspx endpoint was included in the response. Visiting this link allowed for the downloading of reports containing restricted data from other users.

Indicative screenshots of request and corresponding response:

File Download Exposure

• Affected Area: File Download
• Issue: I discovered that an endpoint used for file downloads was vulnerable to parameter manipulation. By interacting with the /fetchdata/FileRetriever.ashx?DocID=XT12398765 endpoint and editing the DocID parameter, I was able to download a ZIP file containing sensitive information from other user accounts. This indicates that the FileID parameter, which should have been protected, allowed access to restricted data.

Indicative screenshot of request:

Recommendations

To address the risks associated with IDOR vulnerabilities identified in the recent incidents, the following actions are recommended:

1. Strict Access Controls: Ensure that access to sensitive data, such as customer reports and account details, is controlled through robust authentication and authorization mechanisms. Validate every user request to ensure they have the correct permissions for accessing or manipulating data. For example, ensure that users can only access their own transaction statuses and account details.

2. Parameter Validation: Implement comprehensive server-side validation for all user-supplied input, particularly for parameters like INFO_CODE and DocID. This includes ensuring that manipulated parameters do not grant access to data or reports from other users. Validate that object references correspond to resources that the user is authorized to access, preventing unauthorized report generation and data downloads.

3. Indirect References: Avoid exposing direct object references, such as database IDs or sensitive file identifiers, in URLs or request parameters. Use indirect references such as secure tokens or hashed values that map to actual resources on the server side. For instance, replace direct DocID parameters with tokens that are validated server-side to restrict access to authorized users only.

4. Regular Security Audits: Conduct frequent security audits and code reviews focusing on identifying and addressing potential IDOR vulnerabilities. Incorporate automated security testing tools that specifically check for access control issues and parameter manipulation vulnerabilities. Ensure that these audits include checks for unauthorized data access and improper report generation.

5. Least Privilege Principle: Apply the principle of least privilege by restricting user access to only the data and actions necessary for their role. For instance, ensure that users can only view and download their own reports and transaction details, and not those belonging to other users. Regularly review and adjust permissions to ensure they align with users' actual needs and roles.

Conclusion

The IDOR vulnerability I identified during the web assessment is a critical reminder of the potential impact such issues can have on an online banking application. The ability for unauthorized users to access sensitive customer details, payment information, and even download files belonging to other users can lead to severe data breaches, financial losses, and a significant loss of trust in the banking institution.

Online banking web applications operate in a highly sensitive environment where the protection of customer data is paramount. Ensuring robust security controls are in place is crucial to safeguard the integrity of the application, protect customer data, and maintain the trust that users place in their financial institutions.