While researching daycare software online we identified multiple providers / companies that offered daycare software. In this instance we looked at an application that was configured worse than the first one we assessed.
In this application we discovered improper authorization / authentication and an insecure direct object reference vulnerability. Insecure direct object reference is when an application utilizes a variable that can be used in the URL, HTTP headers, or within the request body, that can be changed in order to access or perform actions outside of the scope of the current user account. This used to be its own line item in the OWASP Top 10 (2013 A4) but was merged in 2017 A5 Broken Access Control.
Let’s walk through an example:
Within the application – editing the child
After clicking the Edit button, we captured the HTTP Request and noticed the child identifier being passed in the URL
HTTP Response – the child’s name and other information here
Without changing our session identifier, we modified the child identifier variable in HTTP Request, decreasing it by one (1)
Here is the HTTP Response showing the details of a different child: (Name, DoB, Gender)
This issue is even more critical since the application allows for a self-registration (free 30-day trial account) to be able to query the Personally Identifiable Information (PII) of minors.
The application is riddled with areas in which a simple change in the parameter allows the user to view information for other accounts.
Prevention & Remediation:
Ideally, security should be baked in at the beginning of the design and development phases to help avoid these types of issues. A code review should help to identify these issues early on.
Consider the following questions:
1. For direct references to restricted resources (such as the child identifier here), does your application verify the user is authorized to view that specific resource?
2. For indirect references to restricted resources, does the mapping to the direct reference fail to limit the values to those authorized for the current user?
Unfortunately, most Dynamic Application Security Tools (DAST) are not very effective for identifying this type of issue. Instead, a web application penetration test may have helped identify these issues.
Steps to the right direction for remediating the issue would include:
- Use per user or session indirect object references
- Check access for each direct object reference from an untrusted source
- Verify the user account has access to viewing the information being requested
A great reference point for any company in this situation would be – https://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference
Disclosure Timeline:
Discovered: July 26th, 2019
Disclosed to vendor: July 29th, 2019
Follow up email (no response): August 1st, 2019
Follow up email (no response): September 18th, 2019
Follow up email (no response): October 31st, 2019
Past 90 days since first contact with vendorTalk with a White Oak expert
