Cross-site scripting (XSS) in Cybersecurity - Step-by-Step Execution

Concept Flow - Cross-site scripting (XSS)

User inputs data

↓

Data sent to web server

↓

Server stores or reflects data

↓

Web page displays data

↓

Browser executes page content

↓

Malicious script runs if input not sanitized

↓

Attacker steals info or manipulates page

This flow shows how user input can travel from input to execution in a browser, leading to XSS if not properly handled.

Execution Sample

Cybersecurity

<script>alert('XSS')</script>
User input -> Web page output
Browser runs script if unsafe

This example shows a malicious script entered as user input that runs in the browser if the site does not block it.

Analysis Table

Step	Action	Data Content	Result	Security Check
1	User inputs data	<script>alert('XSS')</script>	Data sent to server	No check yet
2	Server receives data	<script>alert('XSS')</script>	Stores or reflects data	No sanitization
3	Web page renders data	<script>alert('XSS')</script>	Script included in page	No escaping
4	Browser loads page	Page with script tag	Executes alert popup	Malicious script runs
5	Attacker impact	Alert popup shown	User info can be stolen or page altered	Security breached

💡 Execution stops after malicious script runs in browser causing security breach

State Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
User Input	empty	<script>alert('XSS')</script>	<script>alert('XSS')</script>	<script>alert('XSS')</script>	<script>alert('XSS')</script>	Executed script
Server Data	empty	empty	<script>alert('XSS')</script>	<script>alert('XSS')</script>	<script>alert('XSS')</script>	Stored unsafe data
Web Page Content	empty	empty	empty	<script>alert('XSS')</script>	<script>alert('XSS')</script>	Page includes script
Browser Execution	none	none	none	alert popup	alert popup	Script runs

Key Insights - 3 Insights

Why does the malicious script run in the browser?

Because the server did not sanitize or escape the user input before including it in the web page, the browser treats it as code and executes it (see execution_table step 4).

What is the difference between storing data and executing script?

Storing data means saving user input as-is (step 2), but executing script happens only when the browser renders the page and runs the embedded code (step 4).

How can this attack be prevented?

By sanitizing or escaping user input on the server before displaying it, so the browser treats it as text, not code (missing in execution_table steps).

Visual Quiz - 3 Questions

Look at the execution_table at step 3. What happens to the user input?

A It is safely removed from the page

B It is encrypted before display

C It is included in the web page without changes

D It is blocked by the server

💡 Hint

Check the 'Data Content' and 'Result' columns at step 3 in execution_table

At which step does the browser execute the malicious script?

A Step 4

B Step 3

C Step 2

D Step 5

💡 Hint

Look at the 'Browser Execution' and 'Result' columns in execution_table

If the server sanitized input before storing, how would the 'Server Data' variable change after step 2?

A It would contain the raw script tags

B It would contain escaped text, not executable code

C It would be empty

D It would cause the server to crash

💡 Hint

Refer to variable_tracker 'Server Data' row and think about sanitization effects

Concept Snapshot

Cross-site scripting (XSS) happens when malicious scripts enter web pages via user input.
If input is not sanitized, browsers run this code, risking user data.
Prevent by validating and escaping input before display.
Always treat user input as unsafe until cleaned.
XSS can steal info or change page behavior.

Full Transcript

Cross-site scripting, or XSS, is a security problem where attackers put harmful code into websites through user input. The flow starts when a user enters data, which the server then stores or reflects without cleaning. When the web page shows this data, the browser runs the harmful script. This can steal information or change the page. The key to stopping XSS is to sanitize or escape user input before showing it on the page. The execution table shows each step from input to script running, helping visualize how XSS happens and why security checks are needed.

Practice

1. What is the main risk of a Cross-site Scripting (XSS) attack?

easy

A. Attackers physically damage the website server

B. Attackers change the website's design without permission

C. Attackers block access to the website by flooding it with traffic

D. Attackers run harmful scripts on a website to steal user data

Solution

1. Step 1: Understand what XSS does

   XSS allows attackers to inject harmful scripts into websites that run on users' browsers.

2. Step 2: Identify the main risk

   These harmful scripts can steal sensitive user data like passwords or cookies.

3. Final Answer:

   Attackers run harmful scripts on a website to steal user data -> Option D

4. Quick Check:

   XSS risk = harmful scripts stealing data [OK]

Hint: XSS = bad scripts stealing user info on websites [OK]

Common Mistakes:

• Confusing XSS with server damage
• Thinking XSS blocks website access
• Believing XSS changes website design only

2. Which of the following is a correct way to prevent XSS in web code?

easy

A. Allow all user input without filtering

B. Use only images and no text on the website

C. Escape special characters like < and > before displaying user input

D. Disable the website's login page

Solution

1. Step 1: Identify safe coding practice

   Escaping special characters like < and > stops harmful scripts from running as code.

2. Step 2: Check other options

   Allowing all input is unsafe, disabling login or using only images does not prevent XSS.

3. Final Answer:

   Escape special characters like < and > before displaying user input -> Option C

4. Quick Check:

   Escape input = prevent XSS [OK]

Hint: Escape < and > in input to stop scripts [OK]

Common Mistakes:

• Allowing all input without checks
• Thinking disabling login stops XSS
• Believing images-only stops script attacks

3. Consider this HTML snippet showing user input:

<div>User comment: <script>alert('XSS')</script></div>

What will happen if the website does NOT sanitize this input?

medium

A. The alert box with message 'XSS' will appear to the user

B. The script tags will be shown as plain text

C. The website will crash immediately

D. Nothing will happen; input is safe

Solution

1. Step 1: Understand unsanitized script tags

   If input is not cleaned, the <script> tag runs as code in the browser.

2. Step 2: Predict the effect

   The alert('XSS') script runs, showing a popup alert with 'XSS'.

3. Final Answer:

   The alert box with message 'XSS' will appear to the user -> Option A

4. Quick Check:

   Unsanitized script runs alert [OK]

Hint: Unsanitized <script> runs code, shows alert [OK]

Common Mistakes:

• Thinking script tags show as text without sanitizing
• Assuming website crashes from script
• Believing nothing happens without sanitizing

4. A developer wrote this code to display user input safely:

output = user_input.replace("<", "<").replace(">", ">")

But users still report XSS attacks. What is the likely problem?

medium

A. The code only replaces < and > but misses other dangerous characters

B. The code should remove all user input instead of replacing

C. The code runs on the server, but XSS happens on the client

D. The code is perfect; users are mistaken

Solution

1. Step 1: Analyze the replacement method

   Replacing only < and > misses other characters like quotes or script event handlers that can cause XSS.

2. Step 2: Understand XSS complexity

   Effective XSS prevention requires comprehensive escaping or using security libraries, not just partial replacements.

3. Final Answer:

   The code only replaces < and > but misses other dangerous characters -> Option A

4. Quick Check:

   Partial escaping misses XSS vectors [OK]

Hint: Partial escaping misses XSS; escape all special chars [OK]

Common Mistakes:

• Thinking removing input is only solution
• Confusing server vs client execution
• Believing partial replacement is enough

5. A website allows users to post comments that include HTML. To prevent XSS, which combined approach is best?

hard

A. Allow all HTML tags but filter out <script> tags only

B. Use a whitelist to allow only safe HTML tags and escape the rest

C. Escape all user input so no HTML tags run as code

D. Disable comments feature entirely to avoid XSS

Solution

1. Step 1: Understand risks of allowing HTML

   Allowing all HTML except script tags is risky because other tags or attributes can cause XSS.

2. Step 2: Identify best practice

   Using a whitelist to allow only safe tags and escaping others balances usability and security.

3. Step 3: Evaluate other options

   Escaping all input removes HTML functionality; disabling comments reduces user engagement.

4. Final Answer:

   Use a whitelist to allow only safe HTML tags and escape the rest -> Option B

5. Quick Check:

   Whitelist safe tags + escape others = best XSS defense [OK]

Hint: Whitelist safe HTML tags, escape others to stop XSS [OK]

Common Mistakes:

• Allowing all HTML except scripts
• Escaping all input losing HTML features
• Disabling comments instead of fixing XSS