Responsible Disclosure: XSS in Macmillan's Website
Another day, another unfiltered reflection of user-supplied content!
You know how this goes by now. You type into a search box <em>test
and the whole page suddenly turns italic. Luckily, the Macmillan Publishers' website filtered out any <script>
elements it encountered. But that still leaves the attacker with the ability to draw SVGs over the page or, more maliciously, start harvesting usernames, passwords, and credit card details from unwary visitors.
Here's a quick example of what an attacker could do:
It doesn't stop with being able to deface the page, of course. Being able to inject a <meta>
element allows an attacker to instantly redirect the user to a different page:
<meta http-equiv="refresh" content="0; url = https://example.com" />
Which, when encoded, looks like:
https://us.macmillan.com/?q=%3Cmeta%20http-equiv%3D%22refresh%22%20content%3D%222%3B%20url%20%3D%20https%3A%2F%2Fexample.com%22%20%2F%3E
We can go even further. An <iframe>
can be injected. And, to bypass any filtering on the server side, its src
can be Base64 encoded:
<iframe src="data:text/html;base64,PHNjcmlwdD5hbGVydCgiWFNTISIpOzwvc2NyaXB0Pg==">
Which results in:
Macmillan don't have a publicly available security.txt
contact - so I dropped them an email. Their website was built by Supadü who also don't provide a dedicated way for security researchers to contact them - so another email was sent off.
Timeline
- Discovered. Contact messages sent to Macmillan and Supadü.
- Reported via OpenBugBounty.
- Tried to make contact via Twitter.
- Emailed the web developer with details.
- Several more emails to Macmillan and and Supadü. No response.
- I noticed that the issue had been fixed. I asked Supadü if they offered a bug bounty. Their response was "No absolutely not". Well, that told me!
- Automatically published.