The Purple Team Journey by Ozz961

 This vulnerability highlights a critical security design flaw known as inconsistent security controls , where different parts of an application apply different rules for authentication and authorization, allowing an attacker to chain weak logic together to gain elevated privileges. The attack begins by discovering a hidden administrative endpoint using a content discovery feature in Burp Suite. The /admin path is not exposed through normal navigation but is still accessible on the server. When directly browsing to /admin , access is denied. However, the response reveals an important detail: only users with a specific corporate email domain (e.g., @dontwannacry.com ) are permitted to access the admin panel. This immediately suggests that access control is being partially based on a user-controlled attribute (email domain), which is a weak and unsafe design choice. The next step involves analyzing the registration process. The application instructs that employees should register us...

 This lab demonstrates a high-level business logic vulnerability , where the application fails to properly validate how quantities affect the final price during a purchase. Instead of enforcing strict rules around order calculations, the system allows the user to manipulate the quantity field in a way that produces an unintended and exploitable outcome. In this case, the vulnerability arises because the backend logic does not properly handle negative values for quantity, which should never be valid in a real-world shopping scenario. During the lab, two items were added to the cart: one expensive item priced at 1337$, and another item priced at 95.37$. Under normal circumstances, the total cost should always be the sum of all positive quantities multiplied by their respective prices. However, the application does not properly validate the quantity input, allowing it to be set to a negative number. By manipulating the quantity of one of the items to -14, the pricing logic becomes co...

 The “Excessive trust in client-side controls” lab demonstrates a common and important security mistake in web applications: relying on data controlled by the user’s browser to enforce critical business logic. In this case, the application allows a user to make a purchase, but it incorrectly trusts values sent within the POST request, specifically the price of an item. Instead of enforcing the correct price on the server side, the application accepts the price provided by the client and processes the transaction using it. This creates a vulnerability where an attacker can manipulate the cost of products simply by modifying the request before it reaches the server. During the purchase process, the application sends a POST request that includes parameters such as product ID, quantity, and price. Normally, sensitive values like price should never be controlled by the client because they are part of the core business logic. However, in this vulnerable lab, the price parameter is editab...

 File upload functionality is a common feature in modern web applications, but when implemented incorrectly, it can introduce subtle yet critical security vulnerabilities. One of the most interesting and less intuitive issues is a race condition in file upload handling. Understanding the Vulnerability: Race Conditions A race condition occurs when the outcome of a system depends on the timing of multiple operations occurring concurrently. In web applications, this often manifests as a Time-of-Check to Time-of-Use (TOCTOU) issue. In file upload flows, the application typically performs steps like: Receive uploaded file Validate file type or contents Store file temporarily Move file to final destination Make file available via web server or processing logic The vulnerability appears when there is a small time window between these steps where the file exists in an intermediate, inconsistent state . If an attacker can send carefully timed concurrent requests, they may ...

This lab demonstrates a more advanced file upload bypass where the attacker creates a polyglot file —a file that is simultaneously valid as an image and as executable PHP. Instead of relying on filename tricks or server configuration, the exploit abuses how applications validate file content versus how the server later executes it. By embedding PHP code inside image metadata (specifically the EXIF comment field ) using tools like exiftool , the attacker produces a file that passes content validation checks while still containing executable code. This approach is particularly effective against applications that verify file signatures (magic bytes) but fail to sanitize or strip metadata. The attack begins by taking a legitimate image file (for example, a .jpg ) and injecting PHP code into its metadata. Using a tool like exiftool , the attacker writes malicious code into the comment field, such as a payload that leverages file_get_contents to retrieve commands or external input. The re...

 The “Web shell upload via obfuscated file extension” lab demonstrates how fragile file upload protections can be when they rely on naive string-based validation. In this scenario, the application attempts to block malicious uploads by filtering out dangerous extensions such as .php , assuming that preventing these filenames will stop server-side code execution. However, this defense fails because it does not consider how filenames are actually interpreted by the underlying operating system and web server. Instead of uploading a file with a clearly malicious extension, the attacker obfuscates the filename in a way that bypasses the filter while still being executed as PHP on the backend. This highlights a critical gap between input validation and runtime interpretation , where the application enforces one set of rules but the server follows another. The result is that a file which appears harmless during validation can still become executable once it reaches the server, enabling ...

This lab demonstrates how weak file upload defenses—specifically extension blacklisting —can be bypassed by manipulating how the server interprets file types. The core idea is simple but powerful: the application checks what the file is called , while the server decides how the file is executed . By exploiting that gap, you achieved code execution. Objective of the Lab The goal is to upload a web shell despite restrictions that block dangerous extensions like .php . The application attempts to prevent remote code execution by rejecting files with known executable extensions, but it does not enforce how uploaded files are ultimately handled by the server. Initial Defense Mechanism The application uses a blacklist to block uploads containing extensions such as: .php .phtml .php5 This creates a superficial barrier. If a user tries to upload shell.php , the request is denied. However, if the file uses an unrecognized extension, such as .shell , it passes validation. The flaw here...

Overview of the Lab This lab demonstrates a file upload vulnerability combined with path traversal , allowing an attacker to control where an uploaded file is stored on the server. By abusing this behavior, it becomes possible to place a malicious PHP file into an executable location and achieve remote code execution (RCE) . The objective is not only to upload a web shell, but to bypass directory restrictions enforced by the application and force the server to store the file in a location where it can be directly accessed and executed. Vulnerability Context and Entry Point The application provides a file upload feature intended to store user files in a restricted directory, typically something like: /files/avatars/ However, the vulnerability lies in how the application handles the filename parameter. Instead of sanitizing or enforcing strict constraints, the server accepts user-supplied filenames and directly uses them when writing files to disk. This creates an opportunity for pat...

Overview of the Lab This lab demonstrates a classic file upload vulnerability where Content-Type validation is improperly implemented , allowing an attacker to bypass restrictions and upload a malicious web shell. The application attempts to enforce security by only allowing files with a specific MIME type ( image/jpeg ), but fails to properly validate the actual file content. The objective of the lab is to exploit this weakness and achieve remote command execution by uploading a PHP web shell disguised as an image. Information Disclosure and Initial Clue During testing, the application revealed an important piece of information through an error message. When attempting to upload a PHP file, the server responded with an error indicating that the file type application/x-php was not allowed, and that only image/jpeg files were accepted. This behavior is a form of information disclosure , as it exposes the exact validation mechanism used by the server. Instead of performing deep i...