Introduction

This post will be a quick one since I don’t like droning on about cross-site scripting (XSS) all that much and I’m sure you’re all getting tired of reading about it. Anyway, this week’s spotlight is on a kiwi-owned and operated retail store that traditionally specialised in books and stationery. However, these days they also resell toys, games, and other goods. And of course they have an online store that we can try and find some problems with.

Exploring for Issues

The general approach I take when finding issues in websites looks roughly like this:

1. Get a list of all known subdomains for the site.
2. Attempt XSS and SQL injection in the search bar.
3. Attempt SQL injection by changing query parameters of various pages.
4. Attempt to get directory listings.
5. Look at the robots.txt file for anything juicy.
6. Create two accounts, one for hacking from and one for hacking into.
7. Attempt to read/modify the details of one account from the other.
8. Attempt XSS and SQL injection on the account details.
9. Cry about my skill issues Smile because they have good security and move on to another website.

During all of this, I am making notes on the technology used behind the scenes and am thinking about other ways I could break it.

In this case, I didn’t have to get to the final stage of this process!

User Profile

Much like almost every other post in the XSS category, this website has a problem when it comes to displaying the user’s first name. If the user changes their name to Mallor<b>y</b> (which makes the letter ‘y’ bold), then they are greeted with this:

Having the webpage render the name as HTML is like gold for a would-be attacker since they can now begin to experiment with what is possible with this vulnerability.

What’s in a Name? (Spoiler Alert: It’s JavaScript)

Now that we know we can use XSS in the first name, we can check to see if we can put a script tag in there. Often websites will employ a Web Application Firewall (WAF) to block malicious requests to the website. A WAF will almost always block requests that have any kind of JavaScript (or SQL injection) in them. In some cases, the WAF can be bypassed; in other cases, it can’t. In this case there doesn’t appear to be a WAF at all which makes our job easier.

Let’s try and get a popup to appear by putting a script tag in the first name field. We’ll try Mallory<script>alert('oof')</script> to achieve this. This is what it looks like when we save the page:

And now let’s try navigating to another page on the site. We can see that the alert pops up just as we intended. This means that we can now execute arbitrary JavaScript code through our name!

Why Does This Work?

The are various reasons why XSS can occur. Sometimes it’s because the frontend has added some user-supplied value to the DOM with innerHTML instead if innerText. Sometimes it’s because the backend hasn’t run any escaping or sanitisation function on the user-supplied code.

In this particular case, the fault lies with the backend code not escaping the value properly when building out the webpage. We know this because we can view the source of the webpage before any JavaScript is executed and we can clearly see the script tag just sitting there, waiting to be executed.

Impact

As a recap, we have found that this website has a stored XSS vulnerability that would allow a threat actor to execute arbitrary code on this website. By itself that is a pretty serious security issue. However, the users on this site are completely isolated and the only person who is going to be affected by this vulnerability is the user themselves. Therefore, the impact of this is pretty low and honestly not too much of an issue.

If this user’s name was rendered as HTML to other users on the website (as was the case in this previous post) then this would be a critical issue since User A could make changes to User B’s account when User B views User A’s name.

Disclosure

I reported this issue to the website on the 5th of May. At the time of publishing I hadn’t heard back from a human and the issue has not been fixed.

I’m not worried about publishing this post since the impact of this bug is small and not exploitable in a meaningful way. I will update this post if they get back to me or fix the issue.