It is, as far as I can tell, unregulated by any financial institution. Nevertheless, it performs a "Know Your Customer" (KYC) check on all new account in order to prevent fraud. To do this, it uses the Ukranian KYCaid platform.

So far, so standard. But there's a small problem with how they both integrate.

I installed Chimoney's Android app and attempted to go through KYCaid's verification process. For some reason it hit me with this error message.

Well, I'd better click that email and report the problem.

Oh, that's odd. What happens if I click the protected link?

Huh! I guess I've been taken to Cloudflare's website. What happens if I click on the links on their page?

Looks like I can now visit any site on the web. If Cloudflare has a link to it, I can go there. For example, GitHub.

Why is this a problem?

MASTG-KNOW-0018: WebViews

One of the most important things to do when testing WebViews is to make sure that only trusted content can be loaded in it. Any newly loaded page could be potentially malicious, try to exploit any WebView bindings or try to phish the user. Unless you're developing a browser app, usually you'd like to restrict the pages being loaded to the domain of your app. A good practice is to prevent the user from even having the chance to input any URLs inside WebViews (which is the default on Android) nor navigate outside the trusted domains. Even when navigating on trusted domains there's still the risk that the user might encounter and click on other links to untrustworthy content

Emphasis added

A company's app is its sacred space. It shouldn't let anyone penetrate its inner sanctum because it has no control over what that 3rd party shows its customers.

There's nothing stopping an external service displaying a message like "To continue, please transfer 0.1 Bitcon to …"

(Of course, if your KYC provider - or their CDN - decides to turn evil then you probably have bigger problems!)

There are some other problems. It has long been known that people can use in-app browsers to circumvent restrictions. Some in-app browsers have insecure configurations which can be used for exploits. These sorts of "accidentally open" browsers are often considered to be a security vulnerability.

The Fix

Ideally, an Android app like this wouldn't use a web view. It should use a KYC provider's API rather than giving them wholesale control of the user experience.

But, suppose you do need a webview. What's the recommendation?

Boring old URl validation using Android's shouldOverrideUrlLoading() method.

Essentially, your app restricts what can be seen in the webview and rejects anything else.

Risk

Look, this is pretty low risk. A user would have to take several deliberate steps to find themselves in a place of danger.

Ultimately, it is "Code Smell" - part of the app is giving off a noxious whiff. That's something you cannot afford to have on a money transfer app. If this simple security fix wasn't implemented, what other horrors are lurking in the source code?

Contacting the company

There was no security.txt contact - nor anything on their website about reporting security bugs. I reached out to the CEO by email, but didn't hear back.

In desperation, I went on to Discord and asked in their support channel for help.

Unfortunately, that email address didn't exist.

I also tried contacting KYCaid, but they seemed unable or unwilling to help - and redirected me back to Chimoney.

As it has been over two month since I sent them video of this bug, I'm performing a responsible disclosure to make people aware of the problem.

Mostly.

A few weeks ago, I received this email from GitHub.

On the surface, this is a sensible email. They want all their members to only have strong 2FA and I still had SMS configured as a fallback method. Except, of course, I should not be a member. I should have been kicked out when I handed back my laptop and lanyard. There was still a bit of pandemic pandemonium about - but surely in the last few years someone should have audited the organisation's membership?

The JML process is critical to cybersecurity. There's no point having fancy controls if you don't revoke the permissions of people who are no longer entitled to access. On a fully integrated system this is (usually) easy - untick a box on Active Directory or whatever and *poof* the user is banned.

But with external systems the problem is harder. You now need to keep track of external usernames, synchronise them with internal names, periodically check them for updates, integrate with an API, and - in some cases - take manual action. It's clear that this particular bit of the NHS had slipped up. Looking through the private list of collaborators, there were many old accounts.

I was able to see all private collaborators:

I could see all private repositories:

I even had access to create new repositories - including special ones:

To be abundantly clear, there was no medical data on GitHub. There was no patient data available for me to view. Absolutely nothing medically sensitive was stored there. This isn't a GDPR or medical privacy issue. If I had made any changes to the code stored on there, it would never have made it to production. There were no API keys or sensitive data or passwords for me to exfiltrate. The NHS BSA is a business unit - not a medical unit.

Nevertheless, it is important that all parts of a large organisation are able to quickly and competently remove users once they have left.

Timeline

• 2025-10-17
  • Received GitHub email.
  • Visited https://www.nhs.uk/.well-known/security.txt to get details of how to raise security issues.
  • Raised the issue on HackerOne
• 2025-10-21
  • After triage, the issue was assigned directly to the BSA.
• 2025-10-31
  • I was removed from the organisation.
  • 
  • Requested permission to publish this post. No objection received.
• 2025-12-02
  • Published

All I need to do is add something like this into my site's source code:

<link rel="monetization" href="https://wallet.example.com/edent">

A user who has a WebMonetization plugin can then easily pay me for my content.

But not every website is created by an individual or a single entity. Hence, the creation of the "Probabilistic Revenue Share Generator".

Probabilistic revenue sharing is a way to share a portion of a web monetized page's earnings between multiple wallet addresses. Each time a web monetized user visits the page, a recipient will be chosen at random. Payments will go to the chosen recipient until the page is closed or reloaded.

Nifty! But how does it work?

Let's say a website is created by Alice and Bob. Alice does most of the work and is to receive 70% of the revenue. Bob is to get the remaining 30%. Within the web page's head, the following meta element is inserted:

<link
   rel="monetization"
   href="https://webmonetization.org/api/revshare/pay/W1siaHR0cHM6Ly9leGFtcGxlLmNvbS8iLDcwLCJBbGljZSJdLFsiaHR0cHM6Ly93aGF0ZXZlci50ZXN0LyIsMzAsIkJvYiJdXQ"
/>

The visitor's WebMonetization plugin will visit that URl and be redirected to Alice's site 70% of time and Bob's 30%.

If we Base64 decode that weird looking URl, we get:

[
   [
      "https://example.com/",
       70,
      "Alice"
   ],
   [
      "https://whatever.test/",
       30,
      "Bob"
   ]
]

Rather than adding multiple URls in the head, the site points to one resource and lets that pick who receives the funds.

There are two small problems with this.

The first is that you have to trust the WebMonetization.org website. If it gets hijacked or goes rogue then all your visitors will be paying someone else. But let's assume they're secure and trustworthy. There's a slightly more insidious threat.

Effectively, this allows an untrusted 3rd party to use the WebMonetization.org domain as an open redirect. That's useful for phishing and other abuses.

For example, an attacker could send messages encouraging people to visit:

https://webmonetization.org/api/revshare/pay/W1siaHR0cHM6Ly9leGFtcGxlLmNvbS8iLDk5LCJpbWciXV0

Click that and you'll instantly be redirected to a domain under the attacker's control. This could be particularly bad if the domain encouraged users to share passwords or other sensitive information.

If the Base64 data cannot be decoded to valid JSON, the API will echo back any Base64 encoded text sent to it. This means an attacker could use it to send obfuscated messages. Consider, tor example:

https://webmonetization.org/api/revshare/pay/W1siUGxlYXNlIHZpc2l0IFJlYWxfZ29vZF9DYXNpbm9zLmJpeiBmb3IgbG90cyBvZiBDcnlwdG8gZnVuISEhIiwxMjM0NTYsImltZyJdXQ==

Visit that and you'll see a message. With a bit of effort, it could be crafted to say something to encourage a visitor to enter their credentials elsewhere.

When I originally reported this, the site could be used to to smuggle binary payloads. For example, this URl would display an image - however, it seems to have been fixed.

Nevertheless, it is important to recognise that the WebMonetization.org domain contains an unvalidated redirect and forwarding vulnerability.

I recommended that they ensured that the only URls which contain legitimate payment pointers should be returned. I also suggested setting a maximum limit for URl size.

Timeline

• 2025-03-27 - Discovered and disclosed.
• 2025-08-05 - Remembered I'd submitted it and sent a follow up.
• 2025-08-26 - Automatically published.
• 2025-08-27 - A day after this post was published, the issue was made public on their repo.
• 2025-09-10 - Confirmed fixed.

What do you think happens if you visit: https://mastodon.social/@PasswordReset/111285045683598517/admin?

If you aren't logged in to that instance, it will redirect you to a 3rd party site. Try opening it in a private browser window.

Here's another, less convincing, demo:

https://mastodon.social/@mastodonopenredirect.wordpress.com@mastodonopenredirect.wordpress.com (You will need to not be logged in to Mastodon.Social for this to work.

It is possible to craft a URl which will redirect any visitor who isn't logged in. Attackers can use this as an open redirect for phishing, spam, and other attacks.

Remediation

This will likely be fixed by #26917. But, in the meantime, administrators of Mastodon instances should be aware that their site could be used as an open redirect.

If you do spot any accounts which appear to be dodgy, admins can either block the account or the entire domain.

Background

Here's how it works - which involves some necessary background detail.

I am user @edent on Mastodon.social. I can send you a URl of https://Mastodon.Social/@edent and you will see my profile. Nice!

But there are lots of Fediverse servers out there. For example, I run a little bot called @colours on the BotsIn.Space instance. Its URl is https://BotsIn.Space/@colours - simple.

But what happens if I am viewing the Colours bot while on Mastodon.Social?

The interface shows https://Mastodon.Social/@colours@BotsIn.Space - if you are logged in to Mastodon.Social, you will see the colours account, you can follow it, reply to it, and interact with it as though it were a user on your home instance.

But what if you're not logged in?

If you visit https://Mastodon.Social/@colours@BotsIn.Space you will be immediately redirected to https://BotsIn.Space/@colours

In theory, this is a good thing! You get taken to their home server and you can see their latest updates etc.

Unfortunately, this can be abused.

Try and visit https://botsin.space/@blog@shkspr.mobi - if you are not logged in to BotsIn.Space, you will be automatically redirected to my blog.

In addition, Mastodon ignores the @username when it sees a local status ID which references an external status. For example, both of these URls will go to the same place:

• https://mastodon.social/@colours@botsin.space/111323978746693908
• https://mastodon.social/@RandomLettersAnd1234/111323978746693908

Impact

A malicious user could do a few things.

The first is spam evasion. Email out a link to mastodon.social/@user@buy_illegal_puppies.com and it might skip spam filters, or confuse the user about the true destination.

The second is phishing. Is a user going to notice that they've been silently redirected to nnast0d0n.social? Stick up a convincing "Please log in again" page and you can steal their credentials.

Why This Works

ActivityPub uses the Well-Known / WebFinger specification. Mastodon will use this to find data on anything which looks like a username.

For example, here's what my blog's account looks like in WebFinger: https://shkspr.mobi/blog/.well-known/webfinger?resource=acct:blog@shkspr.mobi:

{
  "subject": "acct:blog@shkspr.mobi",
  "aliases": [
    "https://shkspr.mobi/blog/@blog"
  ],
  "links": [
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://shkspr.mobi/blog/@blog"
    },
    {
      "rel": "http://webfinger.net/rel/profile-page",
      "type": "text/html",
      "href": "https://shkspr.mobi/blog/@blog"
    }
  ]
}

Mastodon will check that account exists, and then redirect a non-logged-in user to the "profile-page" of an account that it finds.

So a malicious user can create a WebFinger at evil.com, then send out links to mastodon.example/@SexyFunTimes@evil.com, and have users instantly redirected to their site.

Most ActivityPub instances won't do this unless they've already seen the user being referenced. This can be achieved by sending a private message to a user on that server which mentions the redirection account.

Remediation

Given that it is sensible to redirect users to an account's home instance, I think there's really only one way to solve this. An annoying interstitial.

You are leaving XYZ.social. We do not control the page Illegal_Ivory_Smuggling.com. If you are sure you want to proceed, click here. Do not share your username and password with 3rd party sites etc etc etc.

I reported this to Mastodon on 2023-09-20. Apparently a number of other people have also reported it. While they work on how to fix the problem, I thought it was sensible to let people know that this attack was possible.

Timeline

• 2023-09-20 Disclosed on GitHub
• 2023-10-22 Added more details and sought agreement to publish
• 2023-10-29 Checked with various independent Mastodon server admins to see if they were aware of this behaviour - most were not
• 2023-10-30 Published

But, before you can access it, you need to log in. So the website redirects you to:

https://example.com/login?on_success=/page/1234

If you get the password right, you go to the original page you requested. Nice!

But what happens if someone manipulates that query string? Suppose an adversary sends you a link like this:

https://example.com/login?on_success=https://evil.com

A sensible redirection system should say "Hang on a minute! Only internal redirections are allowed. I'd better stop this tomfoolery."

Sadly, that's not always the case. Take, for example, arXiv.org - a website for academics and researchers to share papers.

I discovered that a URl like this - https://arxiv.org/login?next_page=https://example.com/ - would redirect a logged in user to any external site.

A malicious user could redirect users to a phishing page https://arxiv.org/login?next_page=http://arxiv-login-info.xyz/ - and steal their credentials. Or send them to a site with malware etc.

The fix is pretty simple. Any redirection logic should ensure that users can only be redirected to an internal page not an external site.

Timeline

• 2023-04-18 - discovered. Opened a bug on GitHub asking for a way to privately disclose. Shortly afterwards, I received an email address and sent my findings.
• 2023-04-19 - Sent a screencast showing the open redirect. Issue confirmed by the developer.
• 2023-04-24 - a fix was proposed which solved some of the issues but not all of them.
• 2023-05-02 - final fix pushed
• 2023-05-19 - this post automatically published.

Viewing the source of the email showed that they were all coming from http:// mcsaatchi-email-preview.s3.amazonaws.com/o2/...

What happens if we visit that domain?

Ah, the dreaded "The specified bucket does not exist" error. At some point the images were served from that domain but someone deleted the bucket.

This is a problem. Amazon doesn't reserve bucket names after they're abandoned. Which means digital miscreants can claim them.

Imagine if, say, Vodafone¹ registered that bucket name. All of a sudden they could inject their logos or adverts into their rival's billing emails.

An attacker could go further. They could replace the images with ones saying "Please note our bank details have changed, send BitCoin to...."

It gets worse. The emails contain a link to an external font.

An attacker could craft a font with specific ligatures which would replace the text of the email!

I quickly defensively registered the bucket on AWS and sent an email telling O2's security team about the problem. I suggested they update their future emails. Of course, that doesn't help all the emails which have been already been sent and are lingering in their customers' inboxes. So I offered to transfer the bucket name back.

I received an automated response saying they'd look in to it.

Lessons you should learn

You should be very wary about hosting your critical infrastructure on a sub-domain outside of your control. And you should never point directly to an S3 bucket if you can help it.

Ideally, O2 would have spun up a domain like images.billing-emails.o2.com, pointed it to S3, and used that in their emails. That way, if they decided not to continue using Amazon's services, all their existing billing emails would be unaffected.

If an attacker gets control of a domain used to show images in emails, the can directly target your customers.

Timeline

• 2023-01-26 Issue detected. Defensively registered. Email sent.
• 2023-02-21 Reminder email sent informing them that I'd be publishing this post.
• 2023-02-22 O2 said they were investigating and asked me to delete the bucket, which I did. They swiftly reclaimed the bucket and repopulated its content.
• 2023-02-27 Blog post automatically published.

No bug bounty, but O2 did raise my bill by 17.3%…

Somehow I screwed up my configuration, and when I visited edent.codeberg.page/abc123 I got this error:

Now, whenever I see something from the request echoed into the page's source, my hacker-sense starts tingling. What happens if I shove an innocent HTML element into the URl?

edent.codeberg.page/abc<em>123

Aha! It lets through some HTML. I wonder which other elements it lets through? Let's try...

edent.codeberg.page/abc<img src="https://placecats.com/640/640">123

Ah nuts! Let's look in to the source code to see what went wrong:

It seems that the back end code has some protection. It strips all / characters. That makes it impossible to inject a working <script> element because there will never be a </script> to close it.

We can't even use my favourite little trick of Base64 encoding the contents of an <iframe>:

<iframe src="data:text/html;base64,PHNjcmlwdD5hbGVydCgiWFNTISIpOzwvc2NyaXB0Pg==">

Manually removing the / led to this:

No forward slashes makes things like <svg> injection difficult - if not impossible. Hmmm... what can we do...? I know!

The onerror event handler.

test.codeberg.page/abc<img src=1 onerror=alert("xss") ;

Boom!

Let this be a lesson to you - always sanitised user-supplied content, no matter how innocuous it seems.

Timeline

• 2022-12-02 Discovered. Emailed support, got a secure address to email, sent disclosure.
• 2022-12-05 Tested and discovered that it had been fixed.
• 2023-01-02 Blog post automatically published.

I recently found a popular website which echoed back user input. It correctly sanitised < to < to prevent any HTML injection.

Except…

It let through <h2> elements unaltered! Why? I suspect because the output was:

<h2>Your search for ... returned no results</h2>

And, somehow, the parser was getting confused. OK, what can we do with this little vector?

The first thought is to use Javascript event handlers like onclick() or onmouseover() - but they were (sensibly) blocked. The <h2> element only has access to the Global Attributes. So we could inject content which use Right-To-Left text, or add some metadata attributes - but that's not particularly useful.

The most useful Global Attribute is style="". Yup! Good old CSS!

The limitation of the style attribute is that it only applies to the specific element it is attached to. So you can't rewrite the entire page. You also can't use the content: property - as that only applies to ::before and ::after directives.

Using normal CSS, we can change the colour and size of our newly injected <h2>, faff around with the background colour, change the font, and move it about the page. Good for a bit of digital graffiti, but not much else.

Except…

What about using background-image? Using that, we can pull in an external resource.

<h2
  style="background-image:url('https://evil.site/whatever.png');
  width:512px;
  height:512px;"> ... </h2>

That will load an external picture on the site. It could be an animated GIF saying "You're a winner! Visit www.... to claim your prize!". It wouldn't be clickable, but might catch a few people out.

It is possible to load an SVG. And SVG can contain JS. But - alas and alack - the JS doesn't run in background mode - even if the JS is bundled as Base64.

Changing the content-disposition of the image won't force the browser to download it, either.

And that, I think, is about the limit of it. If Javascript is blocked, the worst you can do is inject a malicious image. Short of finding a zero-day in a browser's codec, all that can happen is a bit of temporary defacement.

But Wait! There's More!

While fuzzing around with the input, I made an interesting mistake. I mistyped <svg> as <sgv>. That invalid element was added to the page's HTML! That means there's a parser somewhere which is stripping out only the elements it knows about. Browsers typically ignore elements they don't understand - so there's no danger to users there. But it points to the idea that there may be some elements the sanitiser doesn't know about.

And, indeed, there were! For example, it happily took the obsolete <plaintext> element, and dumped it into the markup. Which caused the page to break.

It also, delightfully, took the <marquee> element!

Terence Eden is on Mastodon

@edent

Replying to @edentOMG…!
I legit did not expect that to work… pic.x.com/5q4ymmzjdg

---

I reported the issue immediately, and got an acknowledgement. But, sadly, after a few months the website was still not fixed.

Take a bow, ACM Digital Library!

Oh, cool, the OCR Exam Board is hosting answer sheets for all my classes!

What happens if I click it?

Yeach! It redirects users to a scammy ebook service hosted on an external website. Which, I assume, the exam board does not endorse.

Alongside exam books, textbooks, literary classics - there's a bunch of material which probably isn't suitable for school…

If you visit the root of the domain, it seems to have a dodgy Javascript trying to redirect you to what is probably a scam site.

It seems fairly clear to me that this is an abandoned website. Some scammer has hijacked it and is using OCR's good name to launder their reputation.

Time to contact the exam board and let them know the bad news.

Disclosure Timeline

• 2022-06-04 Discovered. No security contact, so sent a brief email to their support address
• 2022-06-07 Tried to make contact on Twitter - got redirected to email.
• 2022-07-13 Asked for an update - but noticed the website had been taken down.
• 2022-07-30 Blog post automatically published

See Chrome Bug #1242315 for details.

Demo

Here's a video of me on one site (Twistory.ml) opening a link to Twitter in a new tab. Twitter's mobile site contains a Web Manifest which should prompt the user to install an app. Rather than displaying this pop-up on Twitter's tab, Chrome displays it over the unrelated tab.

Why this is a problem

Here's a (somewhat unlikely) scenario.

You're on, for example, Reddit's website and see an interesting looking link to an external site. You open it in a new tab. All of a sudden, a pop-up appears saying "Reddit is better in the app! Click to download!!"

You download it. Unbeknownst to you, the pop-up was from the external site. They saw your referer header and automatically crafted a manifest file which sends you to a malicious copy-cat app. That app steals your password for Reddit, clones your identity, and kills your puppy.

Google's response

I was expecting Google to close this as WONTFIX. In my experience, Google's attitude to lots of bugs is the same as Steve Job's infamous "You're holding it wrong". Blame the user for not understanding how Google's poorly-tested and confusing products work.

But, to be fair, it was taken seriously. I didn't have to provide any extra detail and, while it was low severity, it was fixed promptly. Kudos!

Then came the agonising wait to see whether Google would pay out millions of dollars for this flaw...

Bounty

For UI bugs like this, Google tends to award $500 - see 1136714, 1133183, and 841622. Although if you can draw over the security UI, the rewards are much higher.

So I was pleasantly surprised to win a US$1,000 bounty!

Perhaps I could have sold it on the DarkWeb™ for digital Beanie Babies totally legitimate crypto-currency? Nah. Too much hassle! I'm going to plough the money into our OpenBenches project.

Timeline

• 2021-08-23 Discovered and disclosed. Within a few hours it was accepted, and triaged. With the (fair) comment that "This doesn't look very scary to me."
• 2021-08-26 Marked as fixed by this commit
• 2021-08-27 Further patches for related issue
• 2021-09-28 Given a gentle nudge, the Reward Panel offered $1k.
• 2021-10-08 After an annoying amount of back-and-forth, Google accepted my registration on their supplier platform. The cause of the delay? I used the W8 form from the IRS.gov site - and Google wanted me to use an older one 🙄
• 2021-11-01 After signing up on their supplier payment platform and jumping through yet more hoops, US$992.50 was deposited in my TransferWise account. Where's the missing $7.50? TransferWise fees? Plus, obviously, a fee to transfer it to GBP and then out to my normal bank account. After all the conversion and fees, it came to £722.64. Quite why the international behemoth Google can't pay in a local currency, I've no idea.
• 2021-12-03 Bug report set to public.
• 2021-12-04 Blog post published.

This XSS was slightly unusual. When a user submits HTML to a site search, it should be escaped before echoing it back on the screen. And that's exactly what Getty Images does:

Except!

It only does that if there were no results found.

If a malicious user can craft a search term that returns results, then HTML is passed unescaped:

So - take care if you're using the Getty Images websites. Be cautious if it asks you for your financial or personal data. It is possible that the information you're seeing has been manipulated by an adversary.

Timeline

• 2021-06-17 Discovered on the Getty Images Norway site, replicated on the UK site. Contacted via Twitter as they have no publicly listed security contact. Responsibly disclosed via OpenBugBounty
• 2021-06-23 Used HackerOne's Disclosure Assistance programme to see if that would prompt a response.
• 2021-07-12 Tried contacting via LinkedIn and the general contact form on their website. Made several attempts over the month.
• 2021-07-29 Direct email to security employees at Getty Images.
• 2021-08-17 Blog post automatically published.

The [REDACTED] website had a subdomain which was running KANA's IQ software which was last updated in 2010. At least, that's judging by the fact it ran jQuery 1.4.4. Most routes into the site redirected properly to their modern website. But a few pages remained accessible. And, sadly, one of those pages was vulnerable to a rather boring XSS flaw.

Posting 'onmouseover="alert('xss')" to a specific page was enough to rewrite its HTML, and produce this:

Now, POSTed XSS are harder to exploit, and relying on the user's mouse to interact with the page makes it less likely to trigger. But, with sufficient determination, an attacker could craft malicious content which could phish the user or otherwise display unwanted content.

Unfortunately, that's about all I can say. When I asked to publicly disclose, I got this in response.

Timeline

• 2021-07-06 Discovered. Asked for a VDP on Twitter and their public security centre.
• 2021-07-07 [REDACTED]'s CERT invited me to their private BugCrowd programme. Bug disclosed.

Terence Eden is on Mastodon

@edent

Why do I only every find XSS vulnerabilities in websites with no VDP or bug bounty?

*sigh*

(I mean, because obviously if they treated security seriously, they wouldn't have these trivial flaws.)

---

Terence Eden is on Mastodon

@edent

Replying to @edentWhat's the point of a *private* VDP?

I looked on HackerOne and BugCrowd, couldn't find anything, so emailed the company's CERT.

"Oh, you have to be invited to our TOP SECRET programme!"

Just... why? Why make it harder for people to report problems to you?

---

• 2021-07-09 Triaged as P4. US$100 bounty and 5 BugCrowd points
• 2021-07-13 Payment received. Request to disclose.
• 2021-07-20 I noticed the vulnerability had been fixed.
• 2021-07-29 Request to disclose again. Refused!
• 2021-08-07 Published on this blog

Let's talk about the humble <meta> element. As its name suggests, it contains metadata about the document. A typical element might look like this:

<meta name="description" content="Search our shop for great deals!">

What can the content tag contain? Text! Specifically, text where certain characters have to be encoded into their HTML entities. Now, to be fair, neither the W3C specification nor the WHAT-WG spec mention how text should be encoded. They both just say:

The value must be a free-form string that describes the page.

Obviously, you should encode a " character to " because otherwise the browser might think that's the end of the string. But the spec doesn't mention that when talking about meta elements.

Create a document which has this meta element:

<meta name="description" content="My name is "Terence <em>Eden</em>" what's yours?">

And you'll see this echoed into the page:

Eden" what's yours?">

Most browsers interpret rogue HTML in the <head> as <body> content.

"Search for the hero inside yourself (ukulele cover)"

The John Lewis shop website had this problem. If you searched for lorem<em>ipsum you saw this:

The server correctly encodes the text in:

<meta name="description" 
      content="Search results for &quot;lorem&amp;lt;em&amp;gt;ipsum&quot; on John Lewis & Partners. Free delivery on orders over £50" />

But it incorrectly encoded it in the OpenGraph meta element:

The server is smart enough to filter out <script> content - so an attacker can't get it to echo malicious JavaScript. But, it was possible to inject SVG content. This is similar to a disclosure I made last year to Three.co.uk.

Here's a basic circle injected into the page:

With a well enough crafted SVG, an attacker can perform a complete site takeover or other malicious activity. Because the content is sent in the GET request, an attacker can send malicious URl which looks like:

https://www.johnlewis.com/search?search-term=%22%3E%3Csvg%20xmlns...

Timeline

John Lewis doesn't have a security.txt available, and I couldn't find anything on their website about reporting security issues.

So I sent a Tweet. When that didn't get a response - presumably because it wasn't a complaint about a missing order - I asked my security buddies. They forwarded on a message. That's great for anyone well-connected, but not a long-term solution.

Eventually, Twitter customer service coughed up the security team's email, so I sent them a write up on the 9th of January. I got back a generic and slightly dispiriting response:

Terence Eden is on Mastodon

@edent

Where can I exchange all this Karma++ for biscuits? pic.x.com/YUZluHC47z

---

A few days later, it was fixed. That's a pretty good response time! I understand that John Lewis will be working on a responsible disclosure programme - but until then, reporting via Twitter seems to be the best way to go.

1. Google forgot to renew a domain used in their documentation.
2. It was mildly embarrassing for them.
3. And possibly a minor security concern for some new G-Suite domain administrators

Background

Choosing a good example domain, to use in documentation, is hard. You want something which is obviously an example, so that users understand they have to substitute it for their own details. But it also needs to be a validly formatted domain, and shouldn't be used for anything important, and - most importantly - should be under your control.

In most of Google's domain documentation, they used SpottedFig.org - why? Who knows!

They used it across their support platform:

Yet, for some reason, they didn't renew it when it expired a couple of months ago.

So I bought it for £10. Cheap!

Security

Google's documentation said "To view DNS results for a domain already configured to use G Suite, enter spottedfig.org."

As I now have control of the domain, I could have entered malicious DNS information and convinced people to use it. Perhaps redirecting their email to my servers.

Impact

Look, this isn't in the same league as the chap who bought Google.com for $12. This is a minor domain with probably zero traffic until I stumbled upon it. Looking in the Wayback Machine, it appears that the site never had any meaningful content.

Because Google specifically advised users to check the DNS entries of SpottedFig.org, I thought there was a minor security risk that Google users could be tricked into entering incorrect DNS information. So I responsibly disclosed it to them.

Eventually, Google replaced most references to SpottedFig in their documentation. They inexplicably left this .com one though:

Timeline

• 2019-11-29 Found the domain while reading the documentation close to midnight.
• 2019-11-30 Purchased the domain. Wrote a badly worded vulnerability report at 1am and sent to Google.
• 2019-12-02 Marked as "infeasible" by Google. So I wrote a better explanation. Essentially "Google tells G-Suite admins to use my domain as a template for configuration."
• 2019-12-03 Google reconsidered! Said it probably wasn't eligible for a bounty (drat!) but they'd evaluate it.
• 2019-12-11 I noticed that Google had rewritten its documentation. All references to SpottedFig.org were removed and replaced with a domain they control - solarmora.com
• 2019-12-18 "As a part of our Vulnerability Reward Program, we decided that it does not meet the bar for a financial reward, but we would like to acknowledge your contribution to Google security in our Hall of Fame"
• 2020-01-14 Published this blog post.

How to prevent this happening to you?

I recommend using Little Warden to monitor your domains.

The EU has announced that it is providing funding for bug bounties on critical open source projects. They've split the programme between HackerOne and Intigriti.

I signed up to Intigriti, and instantly received a confirmation email.

Can you guess where you go if you click the big "Activate Account" button?

I think that's the first time I've ever seen a .lu domain in the wild. Hardly surprising as there's fewer than 90,000 of them.

This looks like a phishing URl. It doesn't use https, it's a random string of gibberish characters, and an obscure domain.

It is happens, the site is legitimate. MailJet - an email marketing firm - use it as a redirector. I assume that Intigriti use them as a mailing service, and want to track every single click you make on their emails.

Why are their statistics more important than your privacy and security?

Why is this bad?

Links to http sites are not secure. That means your visit to that URl can be seen by your ISP and anyone else between you and your destination.

A user clicking on that insecure URl risks having their request intercepted. While an attacker can't log in using the data they've captured, they would be able to redirect the user and phish their details.

Why use a 3rd party?

Basically, if Mailjet gets hacked, or goes rogue, they can start phishing all of Intigriti's customers.

Thankfully, Intigriti had the good sense to not use this tracking on their password reset emails. Indeed, I must commend them on their general security, and their swift responsiveness to this minor security issue.

This isn't the hack of the century - this is low-hanging fruit. I've reported identical issues to CloudFlare, Udacity, and several others.

PLEASE STOP TRACKING EVERY LINK IN YOUR EMAILS!

Or, if you really have to - make sure your tracking server supports https, is controlled by you, and doesn't have a daft domain name.

Timeline

• 2018-12-31 - responsibly disclosed.
• A few hours later - confirmed fixed and bounty offered. Filled in my IBAN details.
• 2019-01-02 - £90 deposited in my account.
• 2019-01-04 - permission given to publish.

1. BA had 3rd party JS on its payment page
   <script src="https://example.com/whatever.js"></script>
2. The 3rd party's site was hacked, and the JS was changed.
3. BA's customers ran the script, which then harvested their credit card details as they were typed in.

This should have been a wake-up call to the industry. Don't load unauthenticated code on your website - and especially not on your payments page.

If you absolutely have to load someone else's code, check to see if it has been altered. This is done using SubResource Integrity (SRI).

SRI tells the user's browser to check that the code hasn't been changed since the website was published. It looks like this:

<script src="https://example.com/whatever.js"
        integrity="sha384-eP2mZH+CLyffr1fGYsgMUWJFzVwB9mkUplpx9Y2Y3egTeRlmzD9suNR+56UHKr7v" 
        crossorigin="anonymous"></script>

If even a single bit of the code has changed since it was added to the page, the browser refuses to run it.

Who isn't using this

Deliveroo

Gig-economy food flingers add in code from CDNJS.

What's especially annoying about this, is that the CDNJS website has a "one-click copy" for SRI.

Spotify

Their payment page loads code from live.adyen.com Adyen are their payment provider - so if they get hacked, credit card details are going to get compromised. But how much easier is it for an attacker to subtly change their JavaScript than to hack their entire mainframe?

The Guardian

Despite being a tofu-knitting member of the bourgeoisie, I am yet to subscribe to teh Gruan. If I did, I'd risk their affiliate tracker going rogue and stealing my organic credit card details. Bonus points for leaving a handy pointer to their internal Google docs...

Fanduel

Sports betting site running unverified scripts from external sources. They've also got external style-sheets

<link rel="stylesheet" href="//d2avoc1xjbdrch.cloudfront.net/6.26.0/styles/desktop.css">

If an attacker can change the JS or CSS, they could compromise users of the site.

EasyJet

I feel a bit conflicted about this one. You can probably trust Google not to get hacked. Right?

Google supports SRI - but doesn't mention it anywhere on their Hosted Libraries site.

British Airways!

Yup! They've not learned their lesson. Three pieces of unverified code running on the payment page.

• Maxymiser is an A/B testing and analytics tool. Run by Oracle now. Most ad-blockers prevent it loading.
• Google's reCAPTCHA. If that gets hacked, half the planet is compromised.
• SiteSeal "proves" your site is secure by displaying a image. No, I don't understand that either.

This does not make the site magically secure.

All three of them are highly trustworthy. But if you're BA and you've already been bitten by bad security practices, doesn't it make sense to go full "belt-and-braces"?

...and more?

These are just a small sample of the sites I've found. SRI has been available for two years and it still isn't being used enough.

Responsible Disclosure

I've reported this issue to a few sites by using responsible-disclosure aggregator HackerOne.

Typically, my warning goes unheeded with a response like:

Based on your initial description, there do not appear to be any security implications as a direct result of this behavior, this is an Informational issue at best, unless you can prove those third-party domains can be compromised in any way.

or

This appears to be more of a risk acceptance rather than a vulnerability. Although there is no PoC for this report, I will forward the information to the customer and see where to go from there.

That's fair enough. I'm not expecting a huge payout and it is only an informative report; I can't prove that the external sites are vulnerable. But there really ought to be a concerted effort to make payment sites as secure as possible.

This needs to be taken seriously. If you're handling users' details, you need to take every possible step to keep them secure.