The Purple Team Journey: My Cybersecurity Chronicles.

Introduction In this lab, the objective was to gain access to an administrative interface protected by authentication controls. Through systematic enumeration and analysis of application behavior, I identified a trust issue involving client-controlled headers combined with information disclosure through an unexpected HTTP method. This write-up explains the methodology, findings, exploitation process, and root cause behind the vulnerability. Initial Enumeration The first step involved enumerating application endpoints and observing how the server responded to different requests. During testing, I discovered the following endpoint: GET /admin The server returned: HTTP/1.1 401 Unauthorized A 401 Unauthorized response indicated that the endpoint existed but required additional authorization rather than being inaccessible or nonexistent. HTTP Method Testing To understand whether the endpoint handled different HTTP methods differently, I tested multiple request methods against /admin . Most...

This exercise was completed as part of a PortSwigger Web Security Academy lab focused on information disclosure through exposed debug endpoints . The goal of the lab was to identify hidden resources on the target application and retrieve a secret value exposed through a debug interface. The scenario simulates a real-world misconfiguration where development or debugging features are accidentally left enabled in a production environment. Such features often expose sensitive system information, including environment variables, configuration data, and internal application details that should never be publicly accessible. Reconnaissance and Hidden Directory Discovery The first step involved performing directory enumeration against the target application to identify hidden or unlinked paths. Since the vulnerable endpoint was not visible through normal navigation, content discovery techniques were required. During brute-force enumeration, the directory /cgi-bin was discovered. This direct...

This exercise was completed as part of a PortSwigger Web Security Academy lab focused on information disclosure vulnerabilities caused by exposed backup files . The purpose of the lab is to demonstrate how sensitive information can be unintentionally leaked through misconfigured web servers that expose development artifacts such as backup files and source code. The scenario simulates a real-world web application where hidden directories are accessible over the internet and contain files that were never intended to be publicly available. These types of issues are common in misconfigured deployments where backup files are left inside web roots or where directory listing protections are not properly enforced. The objective of the lab was to locate a backup file containing application source code, analyze it, and retrieve a hard-coded database password embedded within the code. This password would then be submitted to complete the lab. Reconnaissance and Content Discovery The first step in...

In this lab, the objective was to identify sensitive information exposed through unhandled application errors. Using Burp Suite, HTTP requests were intercepted while browsing product pages. Each request contained a productId parameter, which was observed in the intercepted traffic within the proxy history. The request GET /product?productId=1 was selected for further testing and sent to Burp Repeater to allow controlled modification and analysis of the parameter behavior. In Burp Repeater, the productId parameter was modified from its expected integer value to a non-numeric format ( 1/2 ). This alteration was used to test how the backend handles unexpected input types. The application failed to process the request correctly and triggered an unhandled exception. Instead of returning a controlled error response, the server generated and returned a detailed stack trace in the HTTP response. The stack trace contained internal application information that is typically restricted in pro...

 In this lab, the vulnerability is demonstrated through a live chat feature that relies on a WebSocket connection for real-time communication. When the user clicks “Live chat” and sends a message, the browser establishes a persistent WebSocket session with the server. Using Burp Suite, this traffic can be observed in the WebSockets history tab, where each chat message appears as a WebSocket frame being transmitted through the connection. To begin exploring the application’s security controls, the WebSocket message is right-clicked and sent to Repeater. From there, the payload is modified to include a basic cross-site scripting attempt such as an image tag with an error handler, for example <img src=1 onerror='alert(1)'> . When this modified message is resent through the WebSocket channel, the application responds by blocking the payload. More importantly, the WebSocket connection is immediately terminated, indicating that some server-side filtering or intrusion detection...

Cross-site WebSocket hijacking is a vulnerability that arises when a WebSocket endpoint accepts connections without properly validating the origin of the request or protecting the handshake with anti-CSRF mechanisms. In this lab scenario, a live chat feature is implemented using WebSockets to support real-time communication between users and a support agent. When a user opens the chat and sends a message, the application establishes a persistent WebSocket connection. This connection is then reused not only for live messaging but also for retrieving historical chat data from the server, which introduces a sensitive data exposure surface. The initial interaction begins by clicking “Live chat” and sending a chat message. This establishes the WebSocket connection and allows normal communication. When the page is reloaded, the application automatically reconnects to the WebSocket endpoint. At this point, Burp Suite’s WebSockets history tab reveals an important behavior: the client sends a R...

In this lab, the vulnerability is explored through a live chat feature that uses WebSockets for real-time communication between the user and a support agent. The interesting part is not just that messages are sent in real time, but how they can be intercepted and modified in transit, which ultimately exposes a stored XSS issue. The attack begins by opening the Live chat interface and sending a normal chat message. At this stage, the application behaves as expected: the message is transmitted instantly and appears in the chat window. However, under the surface, this message is not using a standard HTTP request. Instead, it is being sent over a persistent WebSocket connection. To confirm this, Burp Suite is used as an intercepting proxy. Inside Burp, the WebSockets history tab shows that the chat message is indeed being transmitted through a WebSocket frame. This is an important observation because it confirms that the communication bypasses traditional HTTP request logs and instead fl...

 The Bypassing Access Controls Using Email Address Parsing Discrepancies vulnerability is a sophisticated example of how inconsistencies between different parsing mechanisms can undermine otherwise well-intentioned access control restrictions. In this lab, the application attempts to restrict account registration to users with email addresses belonging to a trusted internal domain. The intention is to ensure that only legitimate users associated with the organization can create accounts and access privileged features. However, the application validates email addresses using one interpretation method while the underlying email delivery system parses them differently. This discrepancy creates an opportunity for attackers to craft specially encoded email addresses that pass validation but deliver confirmation emails to attacker-controlled inboxes. The attack begins by identifying the registration restriction enforced by the application. When opening the registration page and attempti...

 The Authentication Bypass via Encryption Oracle vulnerability demonstrates how cryptographic functionality can be abused when an application exposes both encryption and decryption behavior to the client. In this lab, the application uses encrypted cookies to store authentication and notification data. Although the encryption itself may be technically strong, the application leaks enough information through different endpoints to act as an encryption oracle and a decryption oracle , allowing an attacker to forge valid authentication tokens and impersonate another user. The attack begins by logging in as a normal user with the “Stay logged in” option enabled. After authentication, the server issues a stay-logged-in cookie. By inspecting the request and response in Burp Suite, it becomes clear that this cookie is encrypted rather than plain text. This suggests that the application uses the cookie to persist authentication state securely. At this point, the attacker does not know ...

 The Infinite Money Logic Flaw is a business logic vulnerability that allows an attacker to generate unlimited store credit by abusing the interaction between the application’s discount system and gift card functionality. Unlike common technical vulnerabilities such as SQL injection or broken authentication, this issue arises because individually legitimate features interact in an unintended way. The application allows users to purchase gift cards, apply discount coupons to reduce the purchase price, and later redeem those gift cards at full value. Because the redemption value is greater than the discounted purchase cost, the attacker can generate profit from each cycle and repeat the process indefinitely. The attack begins when the user logs into the application and signs up for the newsletter. As part of the signup process, the application provides a promotional coupon code: SIGNUP30 This coupon grants a 30% discount on purchases. Normally, such coupons are meant to encourage p...