News · Case study · 10 months ago
Detailed Technical Analysis of the Indian Income Tax e-Filing Portal Security Flaw
The recent security vulnerability discovered in the Indian Income Tax Department's e-Filing portal, identified as an Insecure Direct Object Reference (IDOR), represents a significant security lapse that placed the sensitive personal and financial data of over 135 million registered taxpayers at potential risk. This article provides a detailed technical breakdown of the vulnerability, its classification, prevention methods, and an analysis of the responsible entities and impact assessment.
The Insecure Direct Object Reference (IDOR) Vulnerability
The vulnerability allowed any logged-in user to access the data of other taxpayers by manipulating a network request parameter that referenced the target object directly—specifically, the Permanent Account Number (PAN).
How the Attack Works: Manipulation and Exfiltration
The IDOR attack exploits a fundamental flaw in Broken Access Control, consistently ranked as a top-tier security risk (e.g., in the OWASP Top 10).
1. Discovery (Reconnaissance):
● A legitimate, authenticated user (the attacker) initiates a network request to view their own data (e.g., a profile page or an old tax filing document).
● The attacker uses a web proxy tool (such as Burp Suite) to intercept and analyse the HTTP request sent from their browser to the e-Filing portal's server.
● They observe that the request contains a predictable identifier, the logged-in user's PAN, embedded in the URL (as a query parameter) or the request body (e.g., in a JSON payload). The PAN is a direct, guessable reference to a unique taxpayer object in the server's database.
2. Manipulation:
● The attacker modifies the intercepted request, changing the value of the PAN parameter to a different, target taxpayer's PAN.
● Example of URL Tampering (Hypothetical):
● Original Request (User A's PAN): GET /api/taxpayer/data?pan=ABCDE1234A
● Manipulated Request (Target B's PAN): GET /api/taxpayer/data?pan=FGHIJ5678B
● The server-side application, critically, fails to perform an authorisation check. It verifies only that the user is logged in (authenticated) but does not verify if the authenticated user (User A) is authorised to access the resource associated with the requested object identifier (Target B's PAN).
3. Data Exfiltration:
● Since the server lacks this crucial authorisation check, it processes the manipulated request as valid.
● The server retrieves and returns the sensitive data (names, addresses, contact information, Aadhaar, and bank account details) belonging to the target taxpayer (Target B) in the HTTP response.
● The attacker can then automate this process, iterating through a list of PANs (or guessing sequential identifiers if they were used in other parts of the application's logic) to systematically exfiltrate data for potentially all 135 million registered users. This is known as horizontal privilege escalation.
IDOR: Basic Sanitary Check or Advanced Vulnerability?
IDOR is fundamentally a failure in a Basic Sanitary Check.
While the consequences of an IDOR can be catastrophic and result in a severe data breach, the vulnerability class is generally considered a basic access control flaw that should be prevented by following secure coding and application design principles.
● Low Barrier to Entry: The exploitation technique is straightforward—it merely involves changing a parameter value. It does not typically require complex, multi-stage exploits or advanced tools beyond a standard web proxy.
● A "Day 1" Check: Implementing a proper server-side access control check (i.e., verifying Is_Current_User_Owner_Of_Object(Requested_Object_ID)) is a non-negotiable step in the software development lifecycle for any application handling user-specific data. Its absence indicates a serious oversight in the application's security architecture or code review process.
● OWASP Context: IDOR has historically been prominent in the OWASP Top 10, often listed under the broader category of "Broken Access Control" (A1:2021), underscoring its commonality and criticality as a foundational security issue.
Measures to Avoid Such Exploits
To prevent IDOR vulnerabilities, development teams must strictly implement robust, server-side authorization mechanisms:
1. Mandatory Server-Side Access Control Checks (The Primary Defense):
● For every function that accesses a resource using an object identifier, the server must explicitly verify that the currently authenticated user is authorized to perform the requested action on that specific object.
● Logic Check: Before retrieving data for pan=X, the system must confirm: If (Authenticated_User.PAN == X) { allow access } else { deny access with an appropriate error/log }.
2. Use of Indirect Object References:
● Avoid exposing the internal database keys or actual PAN/Aadhaar numbers directly in URLs or form fields.
● Use an unpredictable, session-specific identifier (e.g., an index in a session-based map or a random UUID) that maps to the true internal object ID. The client only sees the random token, making enumeration impossible.
● Example: Instead of /data?pan=..., use /data?reference_token=17XZQ. The server then looks up 17XZQ in the current user's active session map to find the allowed PAN.
3. Input and Output Validation:
● Ensure all user-supplied object references are strictly validated for format and content.
Development and Maintenance of the Income Tax Portal
The modern Indian Income Tax e-Filing portal, which was relaunched in 2021, was developed and is maintained by Infosys. The contract for the development and subsequent maintenance of the Centralised Processing Centre (CPC) and the e-Filing portal was awarded to the Bengaluru-based IT company. While the ultimate legal and governmental responsibility for the portal's security rests with the Income Tax Department (ITD), which functions under the Central Board of Direct Taxes (CBDT), the operational execution of development, deployment, and day-to-day technical maintenance is typically managed by the contracted vendor.
Data Exfiltration Assessment
Is it possible to gauge how much data was stolen?
It is generally impossible to accurately gauge how much data was stolen without a public, detailed forensic audit by the Income Tax Department or an independent authority.
● The vulnerability was reported and resolved promptly (September to early October 2025).
● The fact that the flaw was an IDOR means that an attacker who successfully exploited it could theoretically have automated the process to access data for a substantial portion of the 135 million registered users.
● Crucially, if the researchers were the first to discover and report it, and the flaw had not been exploited by a malicious actor beforehand, then the actual stolen data quantity might be near zero.
● However, if the flaw had existed in the production environment for an extended period, the lack of an authorisation check would have left the entire dataset of 135 million users vulnerable to automated scraping attacks.
Who and where from was the data exfiltrated?
As per the information provided, the vulnerability was discovered and ethically reported by security researchers. There is no publicly available evidence to suggest a malicious breach occurred or to identify the nationality or location of any potential malicious exfiltration.
In the context of the ethical disclosure, the data exfiltration attempt would have originated from the researchers' test environment for proof-of-concept, but this is a controlled action reported to CERT-In. The primary risk was to any subsequent malicious actor who may have been aware of the vulnerability. The prompt fix is intended to prevent any malicious exfiltration from having taken place.