In the Internet world, there are five different categories for HTTP status codes, which are used to indicate the result of a client’s request to a server. They help both the client (like your web browser or application), and the server understand what happened during their communication.
Among these categories, the most common are:
- Category 2xx – Success, where the request was successfully received, understood, and accepted.
- Category 3xx – Redirects, that indicates the client must take additional action to complete the request. These codes are typically used to redirect users to a different URL or resource.
- Category 4xx – Client Error, that indicates something went wrong because of the client’s request (like a mistyped URL).
- Category 5xx – Server Error, that indicates something went wrong on the server side.
In this article we will focus on two specific HTTP status code, namely:
- “401 Unauthorized”, that signifies that the client is not authenticated and therefore, is not authorized to access the resource.
- “403 Forbidden”, which means that the client is authenticated but does not have permission to access the resource.
Exploring API Security in a Hypothetical Gym Application
Now, let’s imagine that you recently joined a gym in your neighbourhood, and they have a custom web application that you must use to gain access to the facility and enroll in group classes.
If you are a tech person, and you are curious like me, one of the first things that you will do is intercept the traffic and see what kind of requests are being made.
So, after logging in, and using a tool like Burp Suite, you are able to intercept the app requests and its corresponding responses. After analysing several requests, an interesting one pops-up: you can see the API request that lists the information about a specific user in the application.
For those who are not familiar with the concept of API, it stands for Application Programming Interface, and you can think of it as a messenger that takes a request from one program, tells another program what’s needed, and then brings the response back.
API Responses and Information Exposure
Now, let’s assume that in order to access the user’s information, the only piece of information that you need is the email address of the user. In this case, the API endpoint would look like https://mygymapp.com/api/users/[email protected].
Because you’re logged in, the information displayed in the API response is your personal data that is available in the application, namely your membership number, full name, phone number, and birthdate. In this scenario, you receive a 200 OK!
But what if you change the email to [email protected] and check if you can access other’s user information? Well, in this case, the API request would look like https://mygymapp.com/api/users/[email protected].
However, when you try to access this user’s information, you get a “404 Not Found”, which means that there is no user with that email registered in the gym application.
Because third time’s the charm, and luckily you have a friend that goes to the same gym as you, you decide to try using her email in the API request to see if you are able to see her information.
Yet, and to your astonishment, you get a “403 Forbidden”, a different one from the previous code you received.
What does this mean? It means that your friend’s email is valid in the application, but you don’t have enough permissions to access her information.
That’s interesting. What if you log off the gym application and make the very same requests again? In this scenario, you receive a “401 Unauthorized” error when attempting to access either your own or your friend’s information.
However, when you try to access [email protected] information, you get a “404 Not Found” again!
From a Hacker’s viewpoint, receiving both the “401 Unauthorized” or “403 Forbidden” and “404 Not Found” codes is extremely valuable when attempting to access multiple resources using the same API request.
This approach makes it simple to identify which accounts are valid within the gym application and which are not. This technique is known as user enumeration.
Maybe you are wondering why knowing which accounts are valid within the gym application and which are not is juicy information for a Hacker. The truth is, when you bring small things together, they can grow into something much bigger.
Hackers operate with a wide range of goals, from constructive actions aimed at enhancing security to malicious activities intended for personal gain or disruption.
Leveraging OSINT and Phishing Strategies
In this case, a possible avenue for the Hacker can start by creating a long list of email addresses using Open-Source Intelligence (OSINT) tools.
OSINT refers to the process of collecting and analysing publicly available information from various sources to produce actionable intelligence.
There are numerous OSINT tools available on the Internet that allow to retrieve a list of email addresses based on a domain name.
In order for this scenario to succeed, the Hacker needs to confirm which email addresses are valid in the gym application.
To achieve this, the Hacker replaces the email address in the API request with each entry from the newly created list. Performing this substitution repeatedly within a short timeframe, such as seconds, is known as a Brute Force attack.
Once the Hacker has verified the valid email addresses in the gym application, another plausible avenue can be crafting a phishing email.
Phishing is a type of social engineering attack that aims to trick individuals into revealing sensitive information, such as usernames, passwords, credit card numbers, or any other personal data.
Given that the only commonality so far among these email addresses is the gym application, a compelling subject line for the phishing email could be “Get a Free Month!” or “Get a Free Personal Training Session”.
The user only needs to click a button and enter the login credentials to participate in the mock-up raffle.
Now, if the Hacker intends to target a single user, they can utilize OSINT tools to locate the social media profiles associated with the user’s email address.
By leveraging information from these profiles, the Hacker can approach the user, establish a connection, and then send targeted phishing messages.
By utilizing OSINT tools, it’s also possible to uncover the phone number of a specific user.
In this case, where the Hacker has both the email address and phone number of the user, it’s possible to combine both phishing and vishing tactics to conduct the social engineering attack. Vishing is a form of phishing that uses voice calls.
Best Practices for Strengthening API Security
So, how can we prevent a “401 Unauthorized” and a “403 Forbidden” from turning into a bigger issue? While HTTP status codes are highly valuable for developers when creating and troubleshooting web applications, they can also provide useful clues to Hackers as we have seen so far.
One potential preventive measure can be following GitHub’s technique and return a “404 Not found” instead of a “401 Unauthorized” or a “403 Forbidden”. This technique helps enhance security by not revealing whether a resource exists or not when access is unauthorized or forbidden.
Nonetheless, this technique might confuse developers, so it is a good practice to include it in the API documentation to ensure that they are informed about it.
Another potential preventive measure, can be replacing the user’s email address in the API request by a random and non-sequential identifier, made up of letters and numbers. You can also choose to combine this measure with the previous one.
In addition, it’s also essential to educate users about the existence and dangers of phishing and vishing attacks, to ensure no sensitive information is disclosed. It is also important to always verify the identity of the caller, in case of a vishing call, or the sender, in case of a phishing email.
To confirm the caller’s identity, users can hang up and call the gym directly to determine if the call was legitimate. In case of a phishing email, users should not click any link or give any sensitive information without confirming the email was really sent by someone that works at the gym.
Real-World Breach: The Duolingo Example
In this article, we focused on a gym application; however, we could have chosen any other type of application as an example, ranging from a booking app to a language learning app.
In recent years, we have witnessed several data breaches in which hackers were able to access user’s information simply by having their email addresses.
One notable example is the Duolingo data breach, where a valid email sent to the Duolingo API returned generic account information for the user.
This vulnerable API led to the leak of data for 2.6 million Duolingo users on a hacking forum. If you are not familiar with Duolingo, it is a widely used language learning app with over 74 million monthly users.
The compromised data, which included real names, login names, email addresses and other internal service-related details, was initially offered for sale on a hacking forum in January 2023 for $1500.
In this case, Duolingo users could do nothing but remain vigilant in case of being targeted by phishing emails.
Balancing Functionality and Security
In conclusion, understanding HTTP status codes is essential for developers, as they communicate the outcomes of requests and aid in troubleshooting. However, developers must strike a balance between offering meaningful responses and ensuring application security.
By being mindful of the potential risks associated with detailed status messages, developers can protect the applications and their users while still delivering a positive user experience.
This article was authored by Teresa Pereira, Cyber Threat Hunter at Siemens Energy.