Lab Overview

This lab demonstrates a stored cross-site scripting vulnerability where user input is stored on the server and later rendered inside the href attribute of an anchor tag.

The application encodes double quotes, which may give the impression that the attribute is protected. However, the value inside the href attribute is not properly validated. Because of this, it is possible to inject a malicious JavaScript URI.

The objective of the lab is to execute JavaScript when another user views the stored comment.

None

Step 1 — Exploring the Application

After opening the lab, I explored the website and found a "View Post" option. Inside the blog post page, there was a comment section with the following input fields:

  • Comment
  • Name
  • Email
  • Website

Since the lab title clearly mentions injection into an anchor href attribute, I focused on the "Website" field.

Before attempting any payload, I first submitted normal test data to understand how the application behaves. For example, I entered:

None

After submitting the comment, I inspected the page using Developer Tools.

I found that the value entered in the Website field appeared inside an anchor tag's href attribute.

The HTML looked similar to:

<a href="checking">mayhack</a>

This confirmed that user input from the Website field was directly inserted into the href attribute.

None

Step 2 — Identifying the Vulnerability

At this point, I knew:

  • The Website input is stored in the database.
  • It is later rendered inside an anchor tag.
  • It appears inside the href attribute.

Even though double quotes were HTML-encoded, the content of the href attribute itself was not validated to ensure it was a safe URL.

That means if I provide a malicious protocol instead of a normal URL, it might execute.

Step 3 — Injecting the Payload

Since href attributes can accept different URI schemes, I used the following payload in the Website field:

javascript:alert(1)

After submitting the comment and viewing the post again, the HTML became:

<a href="javascript:alert(1)">mayhack</a>

None

Lab Solved.

None

Why javascript: Works in href

Browsers support different URI schemes inside the href attribute.

For example:

  • https://
  • http://
  • mailto:
  • javascript:

When a link uses the javascript: scheme, the browser executes the JavaScript code instead of navigating to another page.

So when the victim clicks:

<a href="javascript:alert(1)">

The browser executes alert(1) directly.

Because the application does not restrict or sanitize the protocol used inside href, the attack succeeds.

Why This Is Stored XSS

This vulnerability is classified as stored XSS because:

  • The malicious payload is submitted and saved in the database.
  • It is not executed immediately.
  • When another user views the post and clicks the link, the payload executes.

Unlike reflected XSS, the attacker does not need to send a special link each time. The malicious script remains stored in the application.

Impact

If this vulnerability existed in a real-world application, an attacker could:

  • Steal session cookies
  • Perform actions as another user
  • Redirect victims to malicious websites
  • Deliver phishing attacks
  • Steal sensitive information

Since the payload is stored permanently, every user who views the affected post becomes a potential victim.

This makes stored XSS more dangerous than reflected XSS.

Mitigation

To prevent this vulnerability, the application should:

  1. Validate URLs before inserting them into href attributes. Only allow safe protocols like http and https.
  2. Implement proper output encoding based on context.
  3. Reject dangerous URI schemes such as javascript:, data:, or vbscript:.
  4. Use a strict Content Security Policy to reduce the impact of injected scripts.

Simply encoding double quotes is not enough. The application must also validate the content of the attribute itself.

Conclusion

This lab shows that encoding characters alone does not guarantee security. Even if double quotes are encoded, allowing user-controlled data inside an href attribute without validation can lead to stored XSS.

The key lesson is that input placed inside URL-based attributes must be strictly validated. Any protocol that allows script execution should be blocked.

If you want, I can also format this in a more professional bug bounty report style with severity assessment and remediation details.

📬 Stay Connected

If you found this helpful and want to learn more about web security, hands-on labs, feel free to follow me for upcoming posts.

✍️ Follow me for more cybersecurity write-ups 🔗 LinkedIn — codermayank 📸 Instagram — @mayhack_