XSS or Cross Site Scripting is a common form of attack a hacker might perform on a website.

Now pretty much every shopping website, or even most websites, have a search facility.
If there are no search results I tend to get the message “xxxxxx not found” or “Sorry, no results found for yyyyyy”

One thing I like to do when I am bored is try and innocent html tags on search pages such as lorem<em>ipsum to see what happens. I was on Boots anyway, searching for facemasks because of the virus (when I first found this vulnerability), however I finished finding what I needed, and did some other searches…

Now, If a website is handling searches properly I would get “lorem<em>ipsum” returned to me or just “loremipsum” (with the tags stripped).

If the website is interpreting the tags, I will see “loremipsum”, this is bad.

This is what happened on the Boots website, naughty..

Now let’s take B&M Retail, their website just spits my search query out – they pass the test.

Now back to Boots…

My next go to is to inject a simple ‘alert’ box by searching for <script>alert(1)</script>.
Again, totally innocent, but if I can inject a script here, I’m likely to be able to do more malicious things.
When trying this, my request was blocked.. So it allowed some elements, but not others. Interesting, but there are other ways to craft dodgy things…

SVG is another method of attack which can be used by hackers.
I tried drawing a simple square using <svg width="100" height="100"><rect x="50" y="20" rx="20" ry="20" width="50" height="50" style="fill:red;stroke:black;" /></svg>

BOOM!

While this is a very simple SVG XSS attack, given the true power of SVGs – a real hacker may inject some convincing message/ad which appears to be Boots, when in fact its not.
The attacker may then redirect the user to a malicious site to steal credentials for instance.

Why is this a problem? Well the SVG element’s code can be passed in via a simple GET request as part of the search string, e.g.
https://www.boots.com/sitesearch?searchTerm=%3Csvg%20width%3D%22100%22%20height%3D%22100%22%3E%3Crect%20x%3D%2250%22%20y%3D%2220%22%20rx%3D%2220%22%20ry%3D%2220%22%20width%3D%2250%22%20height%3D%2250%22%20style%3D%22fill%3Ared%3Bstroke%3Ablack%3B%22%20%2F%3E%3C%2Fsvg%3E

Now, if that link was sent in email which was a spoofed as Boots, no doubt someone could fall for it – provided it was well executed… The link goes to Boots, so why would someone question it?

Now, a red circle wont do any damage. But what if I had an “invisible” link which went to an attacker’s website or something? Like how this innocent hyperlink went to Google

Or a link to a prize that I’ve won?

So this is the point I give Boots a heads up.

While I received no further updates from Boots, when I tried the exploit again in August I instead got a “Generic Error” page back. So it looks like it has been resolved.

Timeline:
08/03/2021 – Initial email sent to customer services requesting details of who to contact
11/03/2021 – Generic customer service reply with generic email to procurement about “my product idea”
20/06/2022 – Forgot about this until I decided to migrate my blog across to a new host
25/06/2022 – Confirmed vulnerability still active
25/06/2022 – Reached out via email (could only find customer services) asking for a suitable contact
04/07/2022 – Response asking for further details and assurance it will be passed to Digital-Ops.
06/07/2022 – Stonewalled from getting direct contact to someone on their web team. Full details handed reluctantly over to customer services manager – who will be playing piggy-in-the-middle. Asked about a their VDP
04/10/2022 – Disclosure automatically made public after 90 days of no further contact, or a prohibition of disclosing, despite asking.