API Security Under the Microscope: Unmasking Mass Assignment and Broken User Authentication

8 min read

February 4, 2024

Exploring API Security: A Practical Guide to Uncovering Vulnerabilities
API Security Under the Microscope: Unmasking Mass Assignment and Broken User Authentication

Table of contents


Welcome to the latest chapter in our API hacking series, where we dive deep into Mass Assignment and Broken User Authentication vulnerabilities. Having explored the essentials of API security, this installment takes a closer look at these specific threats, offering insights into their detection and mitigation. We'll break down Mass Assignment's potential for unauthorized data manipulation and tackle the challenges of securing user authentication processes. Through practical examples and strategic advice, this chapter aims to arm you with the necessary tools and knowledge to enhance the security of your APIs, ensuring a robust defense against these common but critical vulnerabilities. Let's embark on this journey to fortify our digital fortresses.

Mass Assignment: The Hidden Pitfall in API Security

Beginning with Mass Assignment, we delve into a subtle yet perilous vulnerability in API security. This risk arises when applications blindly trust user input, linking it directly to object properties and creating a potential backdoor for attackers. Such a flaw can lead to unauthorized modifications and system access, underlining the need for vigilant input handling and validation protocols.

Unveiling the Threat: A Closer Look at the Impact

The consequences of Mass Assignment can be severe, ranging from data breaches to privilege escalations. It’s not just about changing a user's role or accessing sensitive data; it's about the potential havoc an attacker could wreak through a single overlooked vulnerability.

Detection and Prevention: Safeguarding Your API

The detection of this vulnerability typically involves examining parameters within the responses of legitimate requests or making educated guesses about potential parameters a request might contain. For instance, in a login portal that collects a username and password, a parameter such as 'isAdmin' could be manipulated and set to 'true' to elevate privileges. As penetration testers, we might intentionally guess or identify such parameters either through our own exploration or by noticing them in requests or responses generated by the application.

Exploring Mass Assignment: crAPI Examples

First Example: The Simple Case

As we advance in our exploration, building on the insights from the previous chapter, our investigation takes a significant turn when we experiment with changing the name of a video uploaded by a user. This process unveils a critical aspect of server interaction—how it responds with various parameters upon receiving our request.

Change name
Parameters of the request

A pivotal point in our analysis is the examination of the Mass Assignment vulnerability. Our methodical testing aims to uncover if parameters, when included in the request, are echoed back in the server's response, potentially altered. Among the parameters tested, including the 'id' in hopes of altering access to other videos, it was the 'conversion_params' parameter that stood out. This parameter, responsible for setting the video's conversion settings, proved to be susceptible to Mass Assignment. By modifying 'conversion_params' in our request, we observed a direct alteration in the response. This finding not only demonstrates the vulnerability to Mass Assignment but also underscores the importance of scrutinizing how server responses reflect the changes made to request parameters, thereby influencing the video conversion process.

Change of vidio conversion by Mass Asignment

This initial example, though appearing simple at first glance, serves as a potent illustration of the ease with which Mass Assignment vulnerabilities can be exploited. This is true even in settings that might initially seem harmless or secure.

Second Example: The intricate Case

Now, let's shift our focus to a more complex scenario in an online store setting. Imagine selecting and purchasing an item, which then generates a unique identifier for the transaction. This process, while common, can reveal a lot about the underlying API structure and potential vulnerabilities:

Product Purchase
Product purchase request

Upon reviewing the order, we uncover not just details about the item, but also various methods that the API permits. This is where our exploration takes an interesting turn:

Permitted methods

An initial experiment might involve switching the method to POST to investigate whether we can modify parameters within the previously received response, such as the 'status' or the purchase ID. In this scenario, I introduced the 'status' parameter, only to find that the system also requires the 'Product_id' and 'quantity' to be specified. However, despite including these additional details, it appears that the backend does not interpret this test. Consequently, it seems that with the POST method, our ability to make changes is limited.

Method change to POST

Conversely, should we make the adjustment to the request method by switching to PUT and incorporating the 'status' parameter, we may encounter a novel error within the server's response. Specifically, this error will shed light on the potential statuses a product can assume: 'Delivered,' 'Return Pending,' or 'Returned.' At this juncture, the most intriguing choice would be to explore the 'Returned' option. By doing so, not only would we receive a refund for the product's cost, but since the product is already in the shipping process, we would also obtain the item itself for free.

Request using Put method

This unexpected turn of events, where altering the status to 'returned' results in an unforeseen refund, serves as a remarkable illustration of Mass Assignment in action. It underscores how even a seemingly minor status modification can carry significant financial consequences:

Change of status
We earn 10 dollars

Broken User Authentication: Unveiling the Chink in Our Digital Armor

After unveiling the intricacies of Mass Assignment vulnerabilities, our journey through the API security landscape propels us towards another formidable challenge: Broken User Authentication. This peril emerges when authentication mechanisms are misconfigured or poorly implemented, leaving a crack in our digital armor through which attackers can slip, assuming identities not their own.

The Crux of Broken User Authentication

Imagine a fortress where the gates occasionally recognize the enemy as a friend, allowing them access to the most guarded secrets. This is the reality of Broken User Authentication - a scenario where attackers exploit weak spots in authentication processes to gain unauthorized access to user accounts, personal data, and privileged information. The repercussions can range from data breaches to complete account takeover, casting a long shadow over the integrity of digital services.

Detecting and Diagnosing the Breach

Start by thoroughly analyzing the authentication process, paying close attention to any potential weaknesses in password management, session handling, or security questions. Delve into the application's responses to legitimate requests, as well as any hints or anomalies that could hint at vulnerabilities. Additionally, attempt educated guesses by manipulating parameters or credentials to uncover potential access issues. Remember, while automated tools are valuable, your human intuition and ability to spot subtle irregularities can be the key to exposing this critical security weakness.

Fortifying the Ramparts: Mitigation Strategies

The key to mitigating Broken User Authentication lies in embracing best practices for secure authentication. Implementing multi-factor authentication (MFA), ensuring robust password policies, and securing session management are the cornerstones of a fortified defense. Regularly updating and auditing authentication mechanisms also ensure that the security measures evolve in tandem with emerging threats.

Venturing into the realm of user authentication, let's dissect the password change process. Initially, upon submitting an email, we're informed that a verification code, a guardian of our digital identity, is dispatched to our inbox.

Password change functionality
Password change request
OTP generated

Upon retrieving the code, a successful entry acts as the key to altering our password, a crucial step in securing our digital persona.

Successful change

However, a closer inspection of the password change mechanism reveals a critical vulnerability. Repeated trials expose the code as a mere 4-digit barricade. This simplicity beckons the question of its susceptibility to brute force attacks, threatening the sanctity of user accounts.

OTP verification request

Imagine targeting a known user, 'beruinsect'. Knowing their email allows us to embark on a quest to reset their password.

Change of password to Beru

Employing tools like Burp Intruder, we simulate a brute force siege, attempting all combinations from 0000 to 9999, a testament to perseverance and cunning.

Data entered
Request on Burp Intruder
Intruder configuration

Our efforts bear fruit, revealing a glaring absence of defenses against such brute force invasions. The response size betrays the correct OTP, allowing us to usurp control over the account.

Successful brute force attack

For those without the luxury of Burp Pro, alternative tools like FFUF offer a swifter path to victory, showcasing the adaptability of a modern hacker.

seq -w 0000 9999 > numbers.txt
ffuf -request brute.txt -w numbers.txt -request-proto http -replay-proxy -ms 200
  • -w specifies the wordlist for fuzzing, targeting various inputs.
  • -request allows for custom request templates, giving flexibility in crafting test cases.
  • -request-proto sets the request protocol, crucial for distinguishing between HTTP and HTTPS.
  • -replay-proxy directs traffic through a proxy, integrating seamlessly with tools like Burp Suite for in-depth analysis.
  • -ms filters responses by size, pinpointing anomalies that could indicate vulnerabilities.

A final word of caution: this vulnerability also opens the door to user enumeration, as the application's response to non-existent emails unveils potential targets. Moreover, through a brute-force attack using a wordlist of commonly known usernames, malicious actors could potentially identify users of the application, creating an opportunity to change their passwords indiscriminately.

User Enumeration


As we close this chapter on Mass Assignment and Broken User Authentication, it's clear that the path to securing APIs is both challenging and crucial. Through exploring these vulnerabilities, we've uncovered not just the risks they pose, but also the strategies to mitigate them. Remember, the key to enhancing API security lies in understanding the threats, vigilance in monitoring, and continuous improvement of defenses. Armed with the knowledge shared in this series, you're better equipped to protect your digital assets against these pervasive security challenges. Let's continue to fortify our APIs, one vulnerability at a time.


Botón Anterior
Securing the Gates: Mastering BOLA and BFLA in API Security

Previous chapter

Unveiling Shadows: Navigating the Risks of Unauthenticated API Access and Excessive Information Exposure

Next chapter