Introduction

This particular website belongs to a New Zealand homewares retailer. Like most retailers, they maintain an internet presence in the form of an online store. Unfortunately, the search function on this website has a cross-site scripting (XSS) vulnerability.

The ABCs of XSS

XSS is a general term that refers to the ability for website users to publish unauthorised HTML content to a website. For example, if I search for ex4242mple on the website, I get this normal result:

But, if I search for some HTML like <h1>ex4242mple</h1> (which encodes my text as a large header), I get this result:

This HTML header gets rendered right there in the page. And like most search pages, this search term is included in the URL. This means that the URL can be shared with other people and then they can also see the same HTML being rendered.

Limitations

Through a bit of trial and error I was able to find a couple of limitations for this particular bug as it pertains to this website:

1. We are limited to 128 characters of input; anything more than that will be truncated by the web application.
2. The website is protected by Cloudflare’s WAF; this means that we can’t execute any JavaScript. Although this WAF can sometimes be bypassed, it isn’t possible here since the payload is sent via the query parameters in the URL.

With these limitations it is difficult to do anything malicious and with those in mind, I’ll showcase a couple of examples of what one can do with this issue.

Having Some Fun

Searching for <img src="https://imgs.xkcd.com/comics/eclipse_clouds.png"/>, we can add an image to the page:

With <style>img{transform:filter(blur(5px))}</style>, we can blur all the images on the page:

With <style>body{transform:scaleX(-1)}</style>, we can flip the page backwards:

Potential Uses

Adding Forms

We can use a technique named cross-site request forgery (CSRF) in conjunction with our XSS vulnerability. CSRF is when we trick the user into making a change that they didn’t intend. Because we don’t have JavaScript at our disposal, we can use plain old HTML forms to make requests to endpoints within the website’s account management API. Of course, the user will have to initiate the request by clicking the submit button first.

For example, it may be possible to change the user details of a logged in user using this method. Fortunately, due to the way this website handles updates to the user’s sign-in information, it wouldn’t be possible to change the user’s email or password using this method.

Here’s an example of a form that could be modified to make changes to a logged in users profile:

1

<form method=POST action="/some-url"><button>Do bad thing.</button></form>

Note: this could be extended to placing a form that looks similar to the sign in form, except it exfiltrates the user’s credentials to some 3rd party site. However, this would probably count as phishing.

Phishing

This is probably the most viable use of this particular vulnerability. We can embed a link to another website and then use that website to get information from the user. Because this retail website hosts the link to our malicious website, the user may choose to trust it.

By using the search term <h1>Congratulations</h1>You have won! Click <a href="#">here</a> to claim your prize.</style><!-- (in reality a proper URL would replace the #), we get this:

This could be spread to a victim by sending them a link via email or social media:

1

https://www.website-name.co.nz/search2/?q=%3Ch1%3ECongratulations%3C%2Fh1%3EYou%20have%20won!%20Click%20%3Ca%20href%3D%22%23%22%3Ehere%3C%2Fa%3E%20to%20claim%20your%20prize.%3C%2Fstyle%3E%3C!--

To most people, this link doesn’t look suspicious; users are used to long URLs with multitudes of tracking information in them. This link wouldn’t look out of place. We could also percent-encode the remaining characters to further obfuscate it if we wanted to.

Buy One, Get One Free!

The parent company of this website also owns a sports-oriented sister company. And sure enough, because both websites are built on the exact same technology, the same XSS issue exists there too.

Disclosure

I reported this issue to the website administrators via their contact form on the 5th of April. They got back to me later that day informing me that they had notified their web development team. I suspect that this company doesn’t have their own internal development team and instead relies on a 3rd-party for this.

At the time of publishing this post — 3 weeks after reporting the issue — the issue has not been fixed. However, since the potential for abuse is low and it’s in the process of being fixed, there shouldn’t be too much of a problem with publishing this information.