This serves as a documentation of my assignment. These six challenges cover core web security vulnerabilities and demonstrate how attackers exploit misconfigurations, weak authentication, and flawed security mechanisms. Below is a brief summary of each flag, including what the challenge required and how it was solved.

Flag 1: Web Intro

Challenge Goal:

• Load the Contact Us page dynamically using JavaScript.
• Extract certain values (organization input, session storage, cookies).

Solution:

• Used JavaScript to fetch the Contact Us page dynamically.
• Extracted session storage and cookies using document.cookie and sessionStorage.getItem().
• Ensured data was properly set in the form fields before submission.

Flag 2: XSS Part I

Challenge Goal:

• Exploit a Cross-Site Scripting (XSS) vulnerability to steal cookies.
• Inject JavaScript into a book review so that the script runs when the page loads.
• Replace existing text on the page with site cookies.

Key Web Security Concepts: Cross-Site Scripting (XSS), Cookie Theft, JavaScript Injection

Solution:

• Injected an XSS payload into a review field:

<img src onerror="document.getElementById('headerText').innerText = document.cookie">

When any user loaded the book review, the script printed their cookies. This proved that JavaScript execution was possible inside user reviews.

Flag 3: XSS Part II

Challenge Goal:

• Perform a Reflected XSS attack instead of a Stored XSS attack.
• Inject a script into the search bar that executes immediately and pops up an alert.

Key Web Security Concepts: Reflected XSS, JavaScript Execution via URL Parameters

Solution:

Injected this script into the search query parameter:

http://localhost:7149/search?search=<script>alert("CS6035")</script>

Since the server did not sanitize input, the script was executed.

Flag 4: CSRF

Challenge Goal:

• Perform a Cross-Site Request Forgery (CSRF) attack to reset a user’s password without their knowledge.
• The password should be changed to "HanSolo77".

Key Web Security Concepts :CSRF, Hidden Form Submission, Session Cookies

Solution:

<form id="csrfForm" method="POST" action="http://localhost:7149/reset-password">
    <input type="hidden" name="newPassword" value="HanSolo77">
    <input type="hidden" name="confirmPassword" value="HanSolo77">
</form>
<script> document.getElementById('csrfForm').submit(); </script>

• Created a hidden form that automatically submitted a password reset request
• When a logged-in user opened the page, their browser automatically sent the password reset request.
• If the server did not validate CSRF tokens, the attack worked.

Flag 5: Bypass Permissions

Challenge Goal:

• Gain access to a restricted Admin page (/admin/).
• Bypass the Role-Based Access Control (RBAC) system.
• Do this using JavaScript inside an HTML file.

Key Web Security Concepts: Cookie Manipulation, XSS Injection, RBAC Bypass

Solution:

document.cookie = 'Permissions-Roles=Administrator; path=/; domain=localhost;';
window.location.href = 'http://localhost:7149/admin/';

Injected JavaScript via an XSS payload.

This modified authentication cookies to give Admin privileges.

The browser automatically sent the fake Admin cookie, granting access.

Flag 6: CORS

Challenge Goal:

• Modify the title of Book 6 using a PUT request.
• Bypass Cross-Origin Resource Sharing (CORS) restrictions.
• Redirect to the Book Detail Page after modification.

Key Web Security Concepts: CORS Misconfiguration, API Exploitation, Unauthorized API Access

Solution:

First, modified the server’s CORS settings to allow PUT requests:

fetch("http://localhost:7149/api/cors/controller/add/method", {
    method: "POST",
    body: "\"PUT\""
})

Then, sent a PUT request to update the book title:

fetch("http://localhost:7149/api/book/6", {
    method: "PUT",
    body: JSON.stringify({ newTitle: "Let the fun begin!" })
});

Finally, redirected the user:

window.location.href = "http://localhost:7149/book/6";

Summary of Web Security Challenges

The following challenges demonstrate critical web security vulnerabilities that arise due to misconfigurations, weak authentication mechanisms, and improper input validation. Each exercise highlights a specific security flaw and the method by which it can be exploited.

Flag 1: Web Intro

Objective:

• Load the “Contact Us” page dynamically using JavaScript.
• Extract session storage values, cookies, and form input data.
• Modify and display extracted data on the page.

Key Takeaways:

• Web applications must properly restrict access to sensitive information stored in cookies and session storage.
• JavaScript functions such as document.cookie and sessionStorage.getItem() can be used to extract and manipulate client-side data.
• Developers should implement secure access controls and input validation to prevent unauthorized data retrieval.

Flag 2: Stored Cross-Site Scripting (XSS)

Objective:

• Inject a malicious JavaScript payload into a book review.
• Ensure that the script executes whenever the review is displayed, extracting and displaying stored cookies.

Key Takeaways:

• Stored XSS attacks occur when user input is improperly sanitized and later executed as JavaScript.
• User-generated content must be escaped and validated before being stored in a database or rendered on a webpage.
• Security measures such as Content Security Policy (CSP) and input filtering can mitigate the risk of XSS attacks.

Flag 3: Reflected Cross-Site Scripting (XSS)

Objective:

• Inject a JavaScript payload through a search query parameter.
• Trigger the execution of the script upon loading the search results page.

Key Takeaways:

• Reflected XSS attacks involve the immediate execution of malicious scripts embedded in URL parameters.
• Servers must properly validate and encode user inputs to prevent the execution of untrusted scripts.
• Web applications should implement CSP headers and input sanitization to mitigate reflected XSS risks.

Flag 4: Cross-Site Request Forgery (CSRF)

Objective:

• Exploit CSRF vulnerabilities to reset a victim’s password without their knowledge.
• Automate the attack by embedding a hidden form that submits the request upon page load.

Key Takeaways:

• CSRF attacks exploit the trust a web application has in an authenticated user’s browser.
• Implementing CSRF tokens ensures that form submissions originate from legitimate user sessions.
• HTTP referer validation and the SameSite attribute for cookies provide additional protection against CSRF attacks.

Flag 5: Bypassing Permissions

Objective:

• Gain unauthorized access to an admin panel by modifying authentication cookies.
• Identify and exploit a hidden debug endpoint (/admin/debug-test).

Key Takeaways:

• Role-Based Access Control (RBAC) should be enforced server-side rather than relying on client-side cookies.
• Debug endpoints should not be accessible in production environments, as they may allow unauthorized access or code execution.
• Secure authentication mechanisms must be implemented to prevent privilege escalation via cookie manipulation.

Flag 6: Exploiting Cross-Origin Resource Sharing (CORS)

Objective:

• Modify the title of a book by sending a PUT request.
• Bypass CORS restrictions to execute the request from an unauthorized origin.

Key Takeaways:

• Improper CORS configurations can allow unauthorized cross-origin requests, leading to data manipulation.
• The server should restrict allowed origins, HTTP methods, and headers to trusted domains only.
• Dynamic modification of CORS policies should require authentication to prevent unauthorized API access.

Conclusion

The challenges presented in these exercises illustrate key web security vulnerabilities that, if left unaddressed, can lead to serious security breaches. Developers should follow best practices such as input validation, access control enforcement, proper authentication mechanisms, and secure cookie handling to mitigate these risks. Implementing security-focused development strategies is essential to maintaining the integrity and confidentiality of web applications.

Aside from the flags, I do want to record the process of finding the debug point, /admin/debug-test

Flag 5: Bypass Permissions — Finding the Debug Endpoint

In Flag 5, the goal was to bypass role-based access control (RBAC) and access the Admin panel (/admin/). The exploit involved modifying authentication cookies to trick the system into granting admin privileges.

One key step was finding the /admin/debug-test endpoint, which allowed us to inject an XSS payload and escalate privileges. Below is a structured approach to how we could discover this hidden debug endpoint.
Which is located at top of the account page “admin.js”:

Step 1: Searching for Debug Endpoints

Many applications have debug routes or testing endpoints that developers forget to remove. To locate them, attackers use the following methods:

1. Check JavaScript Files for API Endpoints

• Open the browser’s Developer Tools (F12 or Ctrl+Shift+I).
• Navigate to the Sources tab and review JavaScript files (.js).
• Look for references to /admin/ or debug keywords.

Example:

var debugUrl = "http://localhost:7149/admin/debug-test";

If such a reference exists, it confirms the presence of /admin/debug-test.

2. View the Page Source for Hidden Links

• Right-click anywhere on the page and select “View Page Source” (Ctrl+U).
• Search for keywords like admin, debug, test, or developerMode.
• Look for hidden links or unused form actions that might expose admin functionality.

Example:

<a href="/admin/debug-test" style="display:none;">Debug Console</a>

This suggests that the debug endpoint exists but may be hidden from regular users.

3. Use Chrome DevTools (Network Tab)

1. Open Developer Tools (F12 or Ctrl+Shift+I).
2. Navigate to the Network tab and filter by XHR (AJAX requests).
3. Perform an action (e.g., logging in or navigating to /admin/).
4. Look at the API requests being made — there might be a request to /admin/debug-test.

Example request seen in Network > Fetch/XHR:

GET http://localhost:7149/admin/debug-test

This confirms that the debug route exists and is actively used by the website.

4. Try Common Debug URLs (Manual Testing)

Many developers name debug endpoints using predictable patterns. Try appending common debug-related terms to the base URL:

http://localhost:7149/admin/debug-test
http://localhost:7149/debug
http://localhost:7149/api/debug
http://localhost:7149/admin/logs
http://localhost:7149/admin/config

If any of these return a valid response (HTTP 200 OK or an error message), then the endpoint exists.

5. Use Brute-Force Scanning (Automated Enumeration)

If manual methods don’t reveal the endpoint, automated tools like ffuf or gobuster can help find hidden admin/debug URLs.

Run the following command in a terminal:

ffuf -u http://localhost:7149/FUZZ -w wordlist.txt

This tries different common debug-related words from a wordlist (wordlist.txt), potentially revealing hidden admin endpoints.

Example output:

/admin                 [200 OK]
/admin/debug-test      [200 OK]
/admin/logs            [403 Forbidden]

This confirms that /admin/debug-test exists and is accessible.

Step 2: Exploiting /admin/debug-test

Once /admin/debug-test is discovered, we can inject a malicious XSS payload into the DebugTest parameter:

http://localhost:7149/admin/debug-test?DebugTest=<script>document.cookie='Permissions-Roles=Administrator'</script>

If the server does not sanitize input, this modifies authentication cookies, granting admin access.