Think Of The Children (part 2 – the Second Born)

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