Blog: How Tos
Information disclosure through insecure design
Introduction
Insecure design can lead to many issues. The Software Development Life Cycle (SDLC) should contain steps to evaluate and consider security throughout the process.
Several recent web application and API tests have revealed a common issue of responses containing too much data, and leaking sensitive and valuable information. This has varied from one company returning detailed address information, allowing the enumeration of account numbers to physical locations, and another company revealing the JSON Web Token of the user that had just logged in.
In these cases, and many more, the common problem has been caused by the responses containing too much information, that simply did not need to be there. This could have been identified from threat modelling as part of the SDLC design review.
Threat modelling such as that described in https://owasp.org/www-community/Threat_Modeling_Process, details several mitigating techniques to deal with information disclosure:
- Authorization
- Privacy-enhanced protocols
- Encryption
- Protect secrets
- Don’t store secrets
As suggested, these steps complement code reviews to identify security weaknesses early in the SDLC.
Minimising responses
Where detailed address information was provided, a simple identifier would have sufficed. Reviewing the design should not just consider if the functionality will work, but also if all the information contained within messages are required.
The original response was found to disclose address information that allowed an account number to be linked to a physical address. The client implemented the change to reduce the data in their responses, providing only what was required for the API and consuming web application to function.
Below shows the original response on the left, and the modified response on the right:
This example shows part of the response from a web application in JSON. The field auth token was populated with the JWT once a user logged in. This was always the last user that logged in and was accessible with or without authentication.
Meaning that a user could log into the application, another user could browse to the application, and simply obtain their JWT for accessing the application.
Figure 1: Auth token in large JSON response
Figure 2: Auth token populated
An attacker can exploit these issues with ease. Simply viewing the messages in the debugging tools of a browser such as Chrome or Firefox, would allow access to personal identifiable information or a valid session token of a different user. These findings were found during assessments and have all been fixed.
Conclusion
All responses from web applications should be reviewed during development to ensure their content is only applicable to meet the requirements. This should be done as part of the design phase, to ensure the issues are caught early. Once in production, these issues present significant risk of account take over, information leakage, reputational damage, and potentially breaching GDPR legislation which could lead to a fine from the Information Commissioner’s Office.
The inclusion of threat modelling in the SDLC would be ideal, complementing the code review process. For the issue of excessive information disclosure within the responses from a web application or API, the following questions could aid in identifying similar weaknesses to those identified above:
- Are the functional requirements of the system met ?
- Is authentication required to invoke a successful response ?
- Is any excess data included in the response ?
- Can the contents of the response be used outside of the intended requirements ?
