Exploiting Cross-Site Scripting to Capture Passwords - PortSwigger Lab Write-Up

Lab:_ Exploiting cross-site scripting to capture passwords Platform: PortSwigger Web Security Academy Vulnerability: Stored Cross-Site Scripting (XSS) Impact: Credential capture through malicious JavaScript_

Introduction

Cross-Site Scripting (XSS) is a web vulnerability that allows an attacker to inject JavaScript into a web page viewed by another user.

In this PortSwigger Web Security Academy lab, the goal is to exploit a stored XSS vulnerability to inject JavaScript into a blog comment. When a victim interacts with the vulnerable page, the injected JavaScript captures the password entered into a login form and sends it to an attacker-controlled server.

This lab demonstrates why stored XSS can be particularly dangerous: the payload is saved by the application and executed when another user views the affected content.

Lab Objective

The objective is to:

Find a stored XSS injection point.
Inject JavaScript through a blog comment.
Make the payload capture credentials entered by the victim.
Receive the captured data through an attacker-controlled endpoint.
Use the obtained credentials to access the victim's account.
Complete the lab.

1. Exploring the Application

The lab provides a blog application with posts and a comment section.

I first inspected the available functionality and found that users can submit comments containing:

Comment
Name
Email
Website

The comment field was particularly interesting because user-supplied content is displayed back on the page.

2. Identifying the XSS Injection Point

The next step was to determine whether the comment field properly sanitizes HTML and JavaScript.

A test payload was submitted through the comment functionality.

The important observation was that the application accepted HTML/JavaScript content instead of safely treating it as plain text.

This indicates that the comment functionality is vulnerable to stored XSS.

Unlike reflected XSS, the payload is stored by the application and can execute whenever another user visits the affected page.

Figure 2: Malicious JavaScript submitted through the comment field.

3. Understanding the Attack

The important part of this lab is not simply triggering an alert.

The objective is to demonstrate a more realistic impact of XSS: capturing information entered into a login form.

The attack flow is:

Attacker
   |
   v
Malicious Comment
   |
   v
Stored by Web Application
   |
   v
Victim Opens Blog
   |
   v
JavaScript Executes
   |
   v
Login Form Data Captured
   |
   v
Attacker-Controlled Server

Attacker
   |
   v
Malicious Comment
   |
   v
Stored by Web Application
   |
   v
Victim Opens Blog
   |
   v
JavaScript Executes
   |
   v
Login Form Data Captured
   |
   v
Attacker-Controlled Server

The injected JavaScript monitors the password field and sends the entered information to an external endpoint.

4. Using Burp Collaborator

To observe whether the injected JavaScript makes an outbound request, Burp Collaborator was used.

Burp Collaborator provides an attacker-controlled endpoint that can receive interactions generated by the browser.

After preparing the payload, it was submitted through the vulnerable comment functionality.

4. Receiving the Captured Data

The request generated by the victim's browser appeared in Burp Collaborator.

The request contained the information sent by the injected JavaScript.

In the lab environment, this confirmed that the payload successfully captured the victim's login information.

5. Logging Into the Victim Account

The captured credentials were then used to authenticate to the victim's account within the lab environment.

The login was successful, confirming that the XSS payload had achieved its intended impact.

6. Lab Completion

After successfully accessing the victim's account, the PortSwigger lab was marked as solved.

Why This Vulnerability Is Dangerous

Stored XSS can have a much larger impact than simply displaying an alert box.

Depending on the application's functionality and browser protections, an attacker may potentially use XSS to:

Capture information entered into forms
Perform actions as the victim
Modify page content
Access sensitive information available to JavaScript
Redirect users to malicious pages
Perform actions using the victim's authenticated session

The actual impact depends heavily on the application's design and security controls.

Root Cause

The fundamental problem is that the application accepts attacker-controlled input and later renders it as executable HTML/JavaScript without appropriate output encoding or sanitization.

Conceptually:

User Input
    ↓
Stored by Application
    ↓
Rendered in Web Page
    ↓
Browser Interprets It as HTML/JavaScript
    ↓
XSS

User Input
    ↓
Stored by Application
    ↓
Rendered in Web Page
    ↓
Browser Interprets It as HTML/JavaScript
    ↓
XSS

The application should instead ensure that untrusted input is safely encoded before it reaches an HTML context.

How to Prevent It

Developers should use multiple defensive controls:

1. Output Encoding

User-controlled data should be properly encoded according to the context in which it is displayed.

For example:

<    →    &lt;
>    →    &gt;
"    →    &quot;
'    →    &#x27;

<    →    &lt;
>    →    &gt;
"    →    &quot;
'    →    &#x27;

2. Input Validation

Applications should validate input where appropriate.

However, input validation alone should not be treated as the primary XSS defense.

3. Safe HTML Sanitization

If users genuinely need to submit HTML, a well-tested HTML sanitization library should be used instead of attempting to build a custom blacklist.

4. Content Security Policy

A properly configured Content Security Policy (CSP) can reduce the impact of some XSS attacks.

5. Secure Authentication Design

Sensitive authentication workflows should use additional protections such as:

Secure session handling
Appropriate cookie attributes
CSRF protection where applicable
Strong authentication controls
Avoiding unnecessary exposure of credentials to client-side JavaScript

Key Takeaways

This lab demonstrates an important point:

XSS is not just about executing alert(1).

The real security impact comes from what an attacker can accomplish after JavaScript execution is obtained.

In this lab, the chain was:

Stored XSS
     ↓
Malicious JavaScript
     ↓
Victim Visits Page
     ↓
Login Information Captured
     ↓
Data Sent to Attacker Endpoint
     ↓
Victim Account Access

Stored XSS
     ↓
Malicious JavaScript
     ↓
Victim Visits Page
     ↓
Login Information Captured
     ↓
Data Sent to Attacker Endpoint
     ↓
Victim Account Access

The vulnerability therefore goes beyond a simple JavaScript popup and demonstrates how client-side code execution can become a serious account-security issue.

Conclusion

The PortSwigger "Exploiting cross-site scripting to capture passwords" lab demonstrates the practical impact of stored XSS.

The key lesson is to think beyond "Can I execute JavaScript?" and instead ask:

Where does the JavaScript execute?
Who will execute it?
What data can it access?
What actions can it perform?
Can the data leave the browser?

Understanding these questions is what turns an XSS finding into a meaningful security assessment.

Contents