The Purple Team Journey by Ozz961

 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...

Understanding the Vulnerability This vulnerability demonstrates a serious flaw in session state management and workflow enforcement , where the application incorrectly assigns privileges when an expected intermediate step is skipped. Instead of securely requiring completion of the role-selection process, the backend mishandles incomplete session states and grants elevated access by default. This type of vulnerability can lead to privilege escalation , allowing a normal authenticated user to gain unauthorized administrator access without exploiting traditional issues such as SQL injection or broken passwords. Step 1: User Logs In Normally The attack starts with a legitimate login attempt using valid credentials. The user submits a request like: POST /login At this stage, the application verifies the username and password successfully. However, instead of immediately taking the user to the dashboard, the application triggers an additional step before finalizing the session. Step 2: Ba...

This vulnerability demonstrates insufficient workflow validation , where the application fails to enforce the correct sequence of actions during the purchasing process. Instead of verifying that each critical step in the workflow has been legitimately completed, the application trusts that users will follow the intended process and allows direct access to later stages without confirming earlier requirements. The issue becomes visible when observing the checkout process through Burp Suite. After logging in and purchasing an item that can be afforded with the available store credit, the request flow reveals multiple steps involved in completing an order. When the user places the order, the application sends a POST /cart/checkout request, which processes the payment and then redirects the user to an order confirmation page. The confirmation page is accessed through a request such as: GET /cart/order-confirmation?order-confirmation=true Under normal conditions, this page should only be ac...

 This vulnerability demonstrates weak isolation on a dual-use endpoint , where a single backend function is used for multiple operations without properly separating privilege levels or enforcing appropriate validation. In this case, the password change functionality is intended for normal users to update their own credentials, but due to poor access control and missing validation, it can be abused to reset another user’s password—including an administrator’s. The issue begins by analyzing the password change feature available on the user account page. Under normal circumstances, changing a password should require the user to provide their current password as proof of identity before setting a new one. This ensures that only the legitimate account owner can perform the operation, even if their session is compromised. By intercepting the POST /my-account/change-password request in Burp Suite and sending it to Repeater, the request structure can be examined. It contains parameters su...