In-Depth Analysis of HTB ‘Full Stack Conf’ CTF Challenge.

The “Full Stack Conf” challenge is a Capture The Flag (CTF) exercise designed to demonstrate web applications' Cross-Site Scripting (XSS) vulnerabilities. The objective is to craft and inject malicious JavaScript code that, when executed, reveals the FLAG. This walkthrough outlines how I analyzed the application, exploited the vulnerability, and understood the automated backend process facilitating the FLAG triggering.

Step 1: Reconnaissance

When I visited the Full Stack Conf website, it introduced itself as a promotional platform for a JavaScript conference. While exploring the site, I identified a potential entry point for the challenge:

HTB

1. The Email Input Form:

At the bottom of the page, there was a simple email sign-up form with the following text:

“Stay up-to-date on Full Stack Conf or pop an alert() to get the flag 😅.”

The mention of alert() strongly hinted at JavaScript functionality, indicating a possible XSS vulnerability in the email field.

2. Behavior After Submission:

Submitting a test email displayed a green success message:

“Thank you for signing up to our newsletter.”

While the input wasn’t visibly reflected on the page, the dynamic response suggested that the server processed the input and potentially handled it in additional ways.

3. Technology Stack:

Using WhatWeb, I determined the site was built using Flask, Werkzeug 1.0.1, and Python 3.8.6. Knowing this was helpful since Flask often uses Jinja2 for templating, which can be vulnerable to XSS if not configured securely.

➜  ~ whatweb 94.237.50.242:32715
http://94.237.50.242:32715 [200 OK] Bootstrap, Country[FINLAND][FI], HTTPServer[Werkzeug/1.0.1 Python/3.8.6], IP[94.237.50.242], Meta-Author[makelarisjr, makelaris], Python[3.8.6], Script, Title[xss], Werkzeug[1.0.1]
➜  ~ whatweb -a3 -v 94.237.50.242:32715
WhatWeb report for http://94.237.50.242:32715
Status    : 200 OK
Title     : xss
IP        : 94.237.50.242
Country   : FINLAND, FI

Summary   : Bootstrap, HTTPServer[Werkzeug/1.0.1 Python/3.8.6], Meta-Author[makelarisjr, makelaris], Python[3.8.6], Script, Werkzeug[1.0.1]

These clues made me suspect that the email input might be a potential attack vector.

Step 2: Understanding the Target

To analyze how the form processed inputs, I used BurpSuite to inspect the network activity. Submitting a test email triggered the following POST request to the /api/register endpoint:

POST /api/register HTTP/1.1
Host: 94.237.50.242:32715
Content-Type: application/json

{
  "email": "meni@meni.com"
}

The server responded with:

{ "success": true }

From the observed behavior and server response, I confirmed the following:

1. The server accepted and processed the input.
2. The input wasn’t directly reflected in the visible DOM but was likely being processed dynamically.

Additionally, reviewing the page’s source code revealed the following JavaScript snippet:

// Immediately Invoked Function Expression (IIFE) to create a private scope
(() => {
    // Initialize a WebSocket connection using socket.io
    const socket = io();

    // Listen for a specific event called 'flag' from the server
    socket.on('flag', data => {
        // Log the received data (the FLAG) to the browser's console
        console.log(data.flag);

        // Display the FLAG in an alert box
        alert(data.flag);
    });
})();

This code revealed that a WebSocket connection was being used to emit the FLAG. It suggested that the backend would send the FLAG once specific conditions — like the successful execution of JavaScript — were met.

Step 3: Identifying and Exploiting the Vulnerability

To test if the email input field was vulnerable to Cross-Site Scripting (XSS), I injected the following payload directly into the form:

<script>alert('XSS')</script>

After submitting this payload, the following occurred:

1. An alert box appeared on the page, confirming the input was executed successfully.
2. The FLAG was revealed in the alert box:

HTB{pop...pop...****...*****}

Inspecting the browser’s developer tools confirmed that the alert() function execution triggered a WebSocket connection, which logged the FLAG in the console.

To ensure the exploit worked reliably, I crafted a more targeted payload:

<img src=x onerror=alert('FLAG')>

This payload uses the onerror Attribute of an image element to execute JavaScript when the image fails to load, a standard method for exploiting XSS vulnerabilities.

Using Burp Suite, I intercepted the POST request to /api/register and replaced the email value with the crafted payload:

POST /api/register HTTP/1.1
Host: 94.237.50.242:32715
Content-Type: application/json

{
  "email": "<img src=x onerror=alert('FLAG')>"
}

After submitting this modified request, the same results occurred:

1. The alert box displayed the FLAG, confirming the success of the payload.
2. The FLAG was also logged in to the console through the WebSocket connection.

These results confirmed that the email input field was vulnerable to XSS and that the backend was designed to process and react to JavaScript execution dynamically. The crafted payload ensured the exploit was executed cleanly and reliably.

What Happens in the Backend?

Based on the observed behavior, here’s what likely happens in the backend:

1. Input Processing:

• When the email is submitted via the /api/register endpoint, the server stores the input and dynamically renders it into an HTML template.

2. Execution Environment:

• The backend includes a process that mimics a browser environment, executing JavaScript embedded in user inputs.
• This process acts as a security misconfiguration simulation. It evaluates whether the submitted input contains a malicious script that triggers specific conditions, such as a alert() function.

3. WebSocket Event Emission:

• Once the backend detects the successful execution of the payload, a WebSocket event containing the FLAG is emitted.
• The WebSocket logic is tied to the JavaScript snippet in the page’s source code:

socket.on('flag', data => { 
console.log(data.flag);
alert(data.flag); });

• This ensures the FLAG is displayed to the user in an alert box and the developer console.

This setup allows the challenge to simulate a real-world vulnerability where unsafe inputs are processed and executed in administrative or automated environments.

Conclusion

The Full Stack Conf challenge was a fun and insightful experience for diving into XSS vulnerabilities! I enjoyed analyzing how the application behaved, figuring out how the backend interacted with user inputs, and crafting some clever payloads to capture the FLAG. This challenge not only showed me the importance of secure coding practices and thorough input validation, but it also provided some great lessons for both attackers and defenders in the world of web security. What a great way to learn!