Cross-Site Scripting (XSS) is one of the most common vulnerabilities found in web applications. In an XSS attack, an attacker can inject malicious code into a website that can steal sensitive information or perform unauthorized actions on behalf of the victim. One particular type of XSS attack is known as DOM-based XSS, where the malicious code is executed on the client-side, rather than on the server-side.
To better understand and test for DOM-based XSS, it’s useful to create a lab environment that can simulate a vulnerable web application. In this article, we’ll walk you through how to create a fully working lab HTML file for DOM-based XSS that you can test against locally in a browser.
Step 1: Create the HTML file
To create the lab HTML file, we’ll start with a basic HTML template that includes a form for the user to input their name:
<!DOCTYPE html>
<html>
<head>
<title>DOM-based XSS Lab</title>
</head>
<body>
<h1>Welcome to the DOM-based XSS lab!</h1>
<form>
<label for="name">Enter your name:</label>
<input type="text" id="name" name="name" />
<button type="submit">Submit</button>
</form>
</body>
</html>
Step 2: Reflected output
Next, we’ll add JavaScript code that reflects the user’s input back to the page. This is a common way that DOM-based XSS vulnerabilities can occur. The code reads the “name” parameter from the URL and injects it into the HTML using the innerHTML
property:
<!DOCTYPE html>
<html>
<head>
<title>DOM-based XSS Lab</title>
<script>
var urlParams = new URLSearchParams(window.location.search);
var name = urlParams.get('name');
var nameElem = document.getElementById('name');
nameElem.innerHTML = name;
</script>
</head>
<body>
<h1>Welcome to the DOM-based XSS lab!</h1>
<form>
<label for="name">Enter your name:</label>
<input type="text" id="name" name="name" />
<button type="submit">Submit</button>
</form>
<p>Your name is: <span id="output"></span></p>
</body>
</html>
Step 3: Updating the URL
Now, we’ll add more JavaScript code that updates the URL with the user’s input when the form is submitted. This is necessary because the reflected output relies on reading the “name” parameter from the URL. The code uses the URLSearchParams
API to update the “name” parameter with the user’s input:
<!DOCTYPE html> <html> <head> <title>DOM-based XSS Lab</title> <script> var urlParams = new URLSearchParams(window.location.search); var name = urlParams.get('name'); var nameElem = document.getElementById('output'); nameElem.innerHTML = name; function updateUrl(name) { urlParams.set('name', name); window.history.replaceState({}, '', '?' + urlParams.toString()); } var form = document.querySelector('form'); form.addEventListener('submit', function(event) { event.preventDefault(); var name = document.getElementById('name').value; updateUrl(name); nameElem.innerHTML = name; }); </script> </head> <body> <h1>Welcome to the DOM-based XSS lab!</h1> <form> <label for
="name">Enter your name:</label> <input type="text" id="name" name="name" /> <button type="submit">Submit</button> </form> <p>Your name is: <span id="output"></span></p> </body> </html>
Step 4: Testing for XSS
Now that we have our lab HTML file set up, we can test for XSS by trying to inject malicious code into the “name” parameter. For example, let’s try injecting a script tag that alerts the user’s cookie:
http://localhost/dom-based-xss-lab.html?name=<script>alert(document.cookie)</script>
When we submit the form with this URL, the JavaScript code in the HTML file will read the “name” parameter from the URL and inject it into the page using the innerHTML
property. Since our injected code is a script tag, it will be executed on the client-side and trigger an alert dialog that displays the user’s cookie.
Step 5: Preventing XSS
To prevent DOM-based XSS vulnerabilities, it’s important to properly sanitize and validate user input. In our lab HTML file, we could prevent XSS by escaping any HTML special characters in the “name” parameter before injecting it into the page. We could also use content security policies (CSP) to restrict the types of JavaScript code that can be executed on the page.
In conclusion, testing for DOM-based XSS vulnerabilities is an essential step in securing web applications. By creating a fully working lab HTML file, developers can better understand how this type of vulnerability works and test their applications for potential attacks. With the simple steps outlined in this article, anyone can create their own lab HTML file and test it against locally in a browser. Remember to always properly sanitize and validate user input to prevent XSS vulnerabilities in your web applications. With proper security measures in place, web applications can be protected against malicious attacks and users can have a safe and enjoyable experience.