HTML Injection/XSS

This is going to be a 2 part post. There is no way in hell I am writing these topics up as separate posts. Sure it would be more content but I would get tired of it, probably smash my keyboard and throw a couple tantrums in the process. I don’t have money for that and you don’t have time to wait that long.

HTML Injection

We will first start with HTML injection. HTML injection occurs when user input is captured without filtering and validation. Much like all security topics careful consideration must be ensured when creating and designing an application.

A user can simply add <h1>batmans</h1> and if there is no validation the injection point should be bigger.

In the picture above we can see how Injection works with the payload and repercussions on the page. Much of the time HTML injection is justification that cross-site scripting exists as well. To further drive the point home I am going to steal a screenshot from HTB Academy on other injections that can be utilized.

Here is our payload:

(I learned this one recently. I won’t lie. I was geeking the hell out that you could do this.)

<style> body { background-image: url('https://academy.hackthebox.com/images/logo.svg'); } </style>

So with the payload in hand we can inject it into the name change button. Without validation and parsing of user input once again we now load the image from the URL we pasted. If you do not find this to be badass, it’s cool. Everybody has wrong opinions sometimes.

XSS

The famous Cross site scripting attack. I think I have talked briefly about this before but I will go over it with some pictures here for reference. There are 3 types:

Reflected XSS: When a inputs their information and it is reflected back that is often reflected XSS. Just because you post your name and you see your name as an account does not mean it exists but it does mean there may be a possibility of it existing.

Stored XSS: When a user inputs information and it is stored in a database and loads for all users on that page. Say you are on a website like Crunchyroll (back when it had a comment section) if stored XSS worked everybody that visits the comment section could be in danger of losing their cookie.

DOM XSS: This is client side specific, meaning the input is shown in the browser and written to HTML DOM. Best way to understand is when you look at the dev tools in your browser your actions affect those resources.

In my opinion the best way to understand XSS is to do it. The simplest payload involving XSS is a simple alert(1) or prompt(1).

Payload 1: <script>alert(document.cookie)</script>

Payload 2: <script>prompt(document.cookie)</script>

Both of these payloads are simple but alert is extremely famous even for non technical individuals. The better option is to use the prompt() method instead.

Here you see the prompt() method break the page. However, because this a 2nd order XSS attack. (By the way 2nd order is a fancy term for attack happens later.) When we log out and log back in we will retrieve the users cookie.

As you can see the 2nd order injection payload worked. We were able to retrieve the users cookie and therefore should be able to log in as the user.

As always. Stay curious my friends.