Cross-Site Scripting (XSS) is a security problem where a website accidentally allows someone to insert malicious JavaScript code into pages that other users will open.

When another user visits that page, the harmful script runs in their browser, as if it came from the trusted website.

Think of it like this:

A website lets users post comments. Instead of a normal comment, an attacker posts hidden JavaScript code. When other people view the comment, their browser runs that code.

Why is XSS Dangerous?

Because the script runs inside the victim's browser, it can:

• Steal login cookies (session hijacking)
• Pretend to be the user
• Change website content
• Redirect users to fake websites
• Perform actions on behalf of the user

If the victim is an admin, the attacker could gain full control of the system.

Simple Analogy

Imagine a school bulletin board where anyone can post messages. If someone secretly posts a message with hidden instructions that steal students' ID cards when they read it.

that's similar to XSS.

Lab 1: Reflected XSS into HTML context with nothing encoded

So here we have a lab where the website reflects XSS into HTML context with nothing encoded. The website function provided is a web blog where there are many blogs about anything, and the website has a "search the blog…" function.

and when we inspect the search function, the code looks like this

<form action="/" method="GET"> <input type="text" placeholder="Search the blog…" name="search"> <button type="submit" class="button">Search</button> </form>

There are no direct vulnerabilities on the frontend. However, forms like this have the potential to cause several vulnerabilities depending on how the server processes the search parameters.

If the search value is displayed back on the page without sanitization, there is a potential for Reflected XSS (Cross-Site Scripting) to occur.

and the output was:

This section displays user input (search) back into HTML. This means that the main potential vulnerability here is:

🚨 Reflected XSS (Cross-Site Scripting)

Because the search value is displayed back in <h1>.

EXPLOIT

Now we will try the common practice of using the alert() function for this purpose because it is short, harmless, and difficult to miss when successfully called.

and for the output of the script is:

If the search value is displayed without HTML escaping, then this page is not 100% vulnerable, but it is potentially vulnerable to Reflected XSS.

Lab: Stored XSS into HTML context with nothing encoded

So, this lab also provides a web blog, just like before, with the context Stored XSS into HTML context with nothing encoded. This website provides a blog, but there is no search button like before. However, each post provides a place for comments.

in this section:

<textarea name="comment"></textarea> <input type="text" name="name"> <input type="text" name="website">

If the server stores comments and displays them again without sanitization, the following may occur:

🚨 Stored XSS

This is more dangerous than reflected XSS because:

• It persists in the database.
• It attacks all users.
• It can be used for admin session hijacking.

EXPLOIT

now we try to exploit it with this kind of input:

and the output will be like this:

but if we try to go back to the blog we commented, the preview will look like this:

This happened because the application was vulnerable to Stored XSS.

payload <script>alert(…)</script> that I entered into the comment field was stored in the database without sanitization or output encoding, and then every time the blog page was opened, the server retrieved the comment and rendered it again as raw HTML in the browser. the JavaScript code in it is automatically executed every time the page is loaded, so the alert always appears for anyone who opens the page, including yourself and all other visitors.

CONCLUSION

From your testing, it is evident that the application stores comment inputs without sanitization or output encoding, so that any JavaScript payload entered will be stored in the database and executed every time the page is opened. This indicates an XSS vulnerability that allows attackers to execute scripts in the victim's browser. The impact can be very serious.

After we finish the two labs, we can conclude the deference between:

• Reflected XSS Terjadi ketika input user langsung dipantulkan kembali ke halaman tanpa disanitasi.
• Stored XSS Terjadi ketika input berbahaya disimpan di server, lalu dijalankan setiap kali halaman yang memuat data tersebut dibuka.

What are your thoughts of this? Feel free to share your insights or questions! I'd love to hear from you!