30 Days to Master XSS with cyberXsociety

What is XSS (Cross-Site Scripting)?

XSS (Cross-Site Scripting) is a most dangerous & common security vulnerability(bug) found in websites where 'attackers can run their own code (usually JavaScript) inside someone else’s website'.

This happens when a website shows user input (like a comment or a search query) on a page without checking or cleaning it. An attacker can trick the site into running harmful scripts - for example, to steal someone’s login info or control their account.

Simple Example:

Imagine a website shows our name like this:

Hello, <our name>!

If the site doesn't validate or clean our input, and we type:

<script>alert('Hacked!')</script>

The site will show:

Hello, <script>alert('Hacked!')</script>!

This runs the attacker’s JavaScript, which could do anything - not just show a popup.

Remember in real attacks, hackers do much worse (like stealing our session, account hijacking etc.).

Real-Life Analogy

Imagine there’s a notice board in our college or apartment building. People can write messages like “Lost phone, please contact...” or “Tuition classes at 5 PM”.

Now imagine someone writes a fake message saying: “Free movie tickets, visit link or scan QR code” and secretly includes a QR code or link that steals our WhatsApp data or login info.

That’s like XSS. The board (website) trusted the message (user input) without checking it. And innocent people got tricked.

Now, don't think how a Notice board can check that message ( it's just to understand )

Key Point:

XSS happens when a website shows user input without checking or cleaning it. Always validate and sanitize input before showing it on the page!

XSS is not just about running alert(1). It’s about understanding how data flows in a web app, where input is not cleaned properly, and how browsers interpret that input.

Why is XSS Dangerous?

Cross-Site Scripting (XSS) is dangerous because it lets attackers run malicious scripts inside someone else's browser without permission.

Here's what attackers can do using XSS:

• Steal login cookies (to hijack accounts)
• Redirect users to fake (phishing) sites
• Change how a website looks or behaves
• Capture sensitive data entered into forms
• Spread malware through links or fake downloads

There are 3 main type of XSS

1. Reflected XSS

This happens when user input is immediately reflected back in the page, like in a search result or error message without being stored on the server.

Example:

https://example.com/search?q=<script>alert(1)</script>

If the website shows back the q (query) parameter in the page without cleaning it, the script will run.

2. Stored XSS (Persistent XSS)

This is more dangerous. The attacker’s script gets stored in the website's database (e.g., in a comment or profile). Anyone who visits the affected page sees the malicious script run.

Example: An attacker posts a comment like:

Nice post! <script>stealCookies()</script>

Now every time someone reads the comments, the script runs in their browser.

3. DOM-Based XSS

This kind of XSS happens entirely in the browser using JavaScript. The malicious input changes the page content using client-side scripts (like document.write or innerHTML).

Example:

https://example.com/#name=<script>alert(1)</script>

If the website uses JavaScript to read location.hash and writes it to the page without sanitizing, the script will execute.

Simple Example (Try This on a Test Site Only):

https://example.com/search?q=<script>alert('XSS')</script>

We can try this on:

Learn More about it at Portswigger.net

That's it for Day 1.

Before we go deeper into XSS attacks, we need to understand one important thing:

 Cross-Site Scripting is not possible without JavaScript.

Attackers use JavaScript to steal cookies, redirect users, fake login forms, or take control of a session. So today, we will focus on the core JavaScript functions that are most commonly used in XSS payloads.

We do not need to learn JavaScript like a developer.
Just need to understand how to use it as a hacker.

Here are a few functions to try:

1. alert()
   

   Used to test if our payload is working.

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

2. prompt()
   

   Sometimes works when alert() is blocked.

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

3. console.log()
   

   Useful for testing silently without alert boxes.

   <script>console.log('XSS')</script>

4. document.cookie
   

   This is how attackers steal session data.

   <script>alert(document.cookie)</script>

5. <img> tag
   

   useful when script tag is filtered.

   <img src=x onerror="alert('XSS')">

6. <svg> tag
   

   another useful when script tag is filtered.

   <svg onload="alert('XSS')">

Our Today's Task:

Try above functions at XSS LAB 01

and See how different websites respond to the payloads.

TryHackME JavaScript Basics Room

TryHackME How Website works Room

TryHackME HTTP Room

Tip:

Start building own XSS cheat sheet with working payloads.
Name it something like: my-xss-payloads.txt

This will help us later in bug bounty programs when we need quick payloads for different contexts.

That’s it for Day 2.

Today we’ll explore the most beginner friendly type of XSS:
Reflected Cross-Site Scripting.

This type happens when a website takes input (from the URL or form) and reflects it back into the page without filtering. If your script is shown directly in the HTML, it can run in the victim’s browser.

It is not stored anywhere it works instantly and only in that session.

Topics to explore for today 👇

What is Reflected Input ?

Reflected input means:

The value you type into the browser (like in the URL or a search box) is immediately shown back (reflected) on the page.

This is common in:

• Search results
• Error messages
• Forms that show what we typed

If this reflection happens unsafely, it can lead to Reflected XSS (Cross-Site Scripting).

Example:

1. We visit a URL like:

https://example.com/search?query=Hello

2. The page says:

You Searched for: Hello

3. That Hello is reflected input — it came from the URL and was shown back on the page.

Reflected XSS Happens When:

We enter <script>alert('XSS')</script> in a search or query parameter. like this 👇

https://example.com/search?q=<script>alert('XSS')</script>

And the page reflects it like this 👇 (unsafely):

You Searched for: <script>alert('XSS')</script>

If The JavaScript runs and If we see a popup (like 👇) or something weird happens. That means the site is vulnerable to Reflected XSS.

How to Recognize Reflected Input

We can test if a page is reflecting input back by entering a unique string in a URL parameter or search box or form and seeing if that exact string shows up on the page.

Important:

Just because we see our input reflected doesn’t always mean it's vulnerable — modern sites may reflect input safely (by escaping or sanitizing it). But if script runs, it's a clear sign of XSS.

How to find parameters in the URL that take our input (like ?q= or ?search=)

1. Look at the URL:

Parameters are usually after a ? (question mark) in the URL and look like this:

https://example.com/search?query=hello

Here, the parameter is query, and the value is hello.

2. Change the value to something we can easily recognize: (like 👇)

?query=HelloTest123

Then check the page content — if you see "HelloTest123" somewhere, that parameter is reflected.

3. Try Multiple Common Parameters

Try changing the parameter name — use these common ones:

?q=HelloTest123
?search=HelloTest123
?input=HelloTest123
?keyword=HelloTest123
?term=HelloTest123
?message=HelloTest123

💡 Keep changing and refreshing to see if our input appears somewhere on the page.

and Try injecting this one 👇 or other payloads:

<script>alert(1)</script>

If the page breaks or shows an error, that’s also useful it means our input is being processed somewhere and == Reflected XSS

Our Today's Task:

Practice on XSS LAB 02

Try these basic payloads in test environments or labs like:

• PortSwigger Reflected XSS Lab
• TryHackMe’s XSS Room
• TryHackMe’s “Intro to XSS” Room ( if Have Memebrship)

See how different websites respond to the payloads.

Tools We Can Try:

Burp Suite (for capturing and repeating requests)

HackBar extension (to inject payloads quickly)

Try changing the payload if the basic one is blocked,
like this one 👇 & other functions practiced yesterday

<img src=x onerror=alert(1)>

That’s it for Day 3.

If a site reflects our input without escaping it, and we can inject HTML like <b>, <h1>, or <img>, that’s HTML Injection.

If our input can actually run JavaScript, like <script>alert(1)</script> or other js payloads, that’s XSS.

Why This Matters ??

Not every HTML Injection is exploitable as XSS.

Some bug bounty reports are rejected because they only show HTML Injection not a real JavaScript execution.

Always check: Can I run JavaScript?

Try These:

<b>BoldText</b>
<h1>Header</h1>
<img src=x onerror=alert(1)>
<script>alert('XSS')</script>
// or more 

What to Focus On Today:

Test both harmless (htmli) and script based payloads at XSS LAB 02

Understand that many filters block <script>, but we can still try with html tags like img, svg or other's

NOTE:

Sometimes HTML Injection can still be dangerous like injecting fake login forms, phishing content, or redirecting users. But for bug bounty reports, always try to prove JavaScript execution.

That’s it for Day 4.

Coming soon