Bug Bounty – Terence Eden’s Blog

Security Flaws in the WebMonetization Site

@edent — Tue, 26 Aug 2025 11:34:33 +0000

I've written before about the nascent WebMonetization Standard. It is a proposal which allows websites to ask users for passive payments when they visit. A visitor to this site could, if this standard is widely adopted, opt to send me cash for my very fine blog posts.

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

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:

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's a better bug-bounty reward than money?

@edent — Mon, 22 Aug 2022 11:34:13 +0000

Google has recently increased the price it pays out to security researchers who responsibly disclose a vulnerability.

That got me thinking. Is money the best thing with which to reward people?⁰

There's an interesting (if a little silly) economics paper about why gift giving is inefficient.

The crux of the argument, as I understand it, is that gift-givers rarely know what recipients need or want. So they give gifts which aren't optimal. Your aunt gets you a blue cardigan. But you'd rather have received a yellow t-shirt. Therefore you value the gift at a lower monetary cost than what the giver spent.

If you're happy to ignore all the social niceties around giving and receiving - I'd say it's pretty accurate. Giving the gift of cash prevents newly-weds from being inundated with toasters. A gift registry can solve some of that problem, but inevitably means some gifters end up spending much more or much less than they wanted.

A happy medium is, of course, gift vouchers. As a kid, I lost count of the number of book tokens, record tokens, and cinema coupons I received.

Vouchers have the (dubious) advantage of being unable to be mis-spent. A harried single-parent can't turn a pampering spa-voucher into paying the gas bill, and a student going off to university can't convert book tokens into beer¹.

Back when I was doing developer relations, we were always looking for ways to incentivise people to use our products. They generally fell into a few categories:

Stickers and other low-value goods.
Phones and other expensive hardware.
Credit for our platform.
Cash prizes.
Money-can't-buy-experiences.

Would a rational developer go out and buy a 2GB USB stick shaped like our logo? Or a t-shirt with our slogan? No. But they're useful low value items.

Would a rational developer buy the phone we were giving away? If it was a pre-release model, it would have high monetary value and social cachet. But that doesn't pay the bills.

Would a rational developer want £500 worth of credit on our service? Unlikely! It didn't cost us much to give it away, and the developer knew we were trying to hook them into spending more.

Would a rational developer want cash? Yes! Well, unless their accountant found out and told them what the state's tithe was!

And so we come to the most interesting one. Money-can't-buy-experiences. A few years ago I won a hackathon. The prize was A guided walking tour under the Thames Barrier. This was not something anyone could pay to do. Much like a tour of Wonka's chocolate factory, it was a limited offer to see the inner workings of something magnificent.

So, what are the money-can't-buy prizes that an organisation like Google could offer?

An adult-entertainment company I worked with once offered "win a date with one of our models" as a prize. Ignoring the obvious problematic aspects of that, would you like to win a 20 minute "date" with the CEO to pitch your idea?

What is it worth to a young security researcher to win an internship?

Would you place value on sitting in the command-centre when SpaceX launches a rocket?

Do you want an exclusive profile badge / challenge coin / avatar for the service?

Sure, you could get money, but how about a ride in our top-secret prototype?

We have tickets to the sports final that we sponsor - wanna come sit in the corporate box?

Can we name a character after you in our next hit movie?

We'll increase the number of followers you have on our social network.

How about a photo-op with the President / Prime Minister / Chancellor / Pope?

To be clear, I think cash-money is probably still the best. And there are an awful lot of Bug Bounty hunters out there who make a decent living fixing other people's mistakes. And, obviously, money-can't-buy is sometimes just another way of saying "we don't have to spend a lot on this".

But I can't help thinking that big organisations could offer something a lot more valuable - and memorable - than money.

What do you think? What would you like to win?

Yes. As the saying goes "Money can be exchanged for goods and services" ↩︎
Of course, vouchers can be exchanged for cash. Usually at a much lower value than the face price. ↩︎

Responsible Disclosure: Chrome security bug let tabs draw over each other ($1k bounty)

@edent — Sat, 04 Dec 2021 12:34:26 +0000

Chrome for Android had a flaw which let one tab draw over another - even if the tabs were on completely different domains. A determined attacker might have been able to abuse this to convince a user to download and installed a spoofed app.

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.

https://shkspr.mobi/blog/wp-content/uploads/2021/08/Chrome-Bug.webm

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.

Full Disclosure: XSS in Getty Images

@edent — Tue, 17 Aug 2021 11:39:17 +0000

I've spent two months trying to report this issue to Getty images. They haven't responded to my emails, phone calls, Tweets, or LinkedIn messages. I've tried escalating through OpenBugBounty and HackerOne - but still no response. I've taken the decision to fully disclose this XSS because the Getty Images sites accept payments from users - and users need to be aware that the content they see on Getty Images sites may have been tampered with.

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.

Responsible Disclosure - John Lewis

@edent — Mon, 10 Feb 2020 08:13:36 +0000

The HTML5 specification is complicated. I've been an author on it, and even I couldn't tell you all the weird little gotchas it contains. Between that and "idiosyncratic" browser engines, it's a wonder the world wide web works at all.

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

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:

Eden" what's yours?">

And you'll see this echoed into the page:

Eden" what's yours?">

Most browsers interpret rogue HTML in the as content.

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

The John Lewis shop website had this problem. If you searched for loremipsum you saw this:

The server correctly encodes the text in:

But it incorrectly encoded it in the OpenGraph meta element:

The server is smart enough to filter out
Three's website detects script elements as hostile and refuses to serve them back.

But, curiously, it does allow some HTML elements through. The underline element, for example.

It wouldn't allow or or most other troublesome content. But I was surprised to see it let through SVG (Scalable Vector Graphics). This means some minor naughtiness can be had!

Doing a search for

Results in a big blue circle being drawn on the page. ...and that's when I stopped and tried to find someone to report it to!

Why is this a problem?

Drawing a circle is not malicious. But SVGs are complex. They can store intricate graphics.

Because the search parameter is sent in the URL - http://www.three.co.uk/Search/?q= - it would be easy for a spammer to send a message saying "Click here for great deals on Three!!!" and then use the SVG to draw a graphic encouraging the hapless user to visit a malicious site.
Or they could create a form to phish users' details. Or... Well, use your imagination. Reporting it to Three *sigh* Three don't publish any security contact details. Nor do they participate in any bug bounties that I could find. I reached out to my friends in the mobile industry - because I didn't have much faith in reporting it via Twitter... Kieran @REALSgtBrdStk Replying to @ThreeUKSupport@ThreeUKSupport your site "three.co.uk" is showing up as 'Not Secure' and there's no valid SSL Certificate for the site. So it will appear as this. pic.x.com/0trepindah ❤️ 1💬 0🔁 015:08 - Wed 16 January 2019 ThreeUKSupport @ThreeUKSupport Replying to @REALSgtBrdStk@REALSgtBrdStk don't worry, if you go to any pages where you need to enter any personal details or sensitive info the webpage will be https secure ☺🔐 >KH ❤️ 0💬 0🔁 015:34 - Wed 16 January 2019 Eventually a friend of a friend sent me a security email address which Three do not publicise. I fired off a quick disclosure and was pleasantly surprised at how seriously they took the issue. Timeline 2019-08-22 - Discovered and disclosed. Got a reply in under an hour that it was being looked at and that a 90 day disclosure was fine. 2019-09-20 - Three informed me the issue was fixed, which I verified. They offered to send me a token of their appreciation in lieu of a formal bug bounty. 2019-09-22 - Bug Bounty delivered! Big ol' box of chocolates!

€100 Bug Bounty from Intigriti - please stop tracking your confirmation emails! @edent — Sat, 05 Jan 2019 12:06:26 +0000 There's a new bug bounty provider in town! The Belgian company Intigriti. This is a quick write-up of how I found a trivial bug in their own system. 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. $3k Bug Bounty - Twitter's OAuth Mistakes @edent — Fri, 14 Dec 2018 12:09:32 +0000 Imagine the scenario. You're trying out some cool new Twitter app. It asks you to sign in via OAuth as per usual. You look through the permissions - phew - it doesn't want to access your Direct Messages. You authorise it - whereupon it promptly leaks to the world all your sexts, inappropriate jokes, and dank memes. Tragic! What's going on? Many years ago the official Twitter API keys were leaked. This means that app authors who can't get their app approved by Twitter are still able to access the Twitter API. For some reason, Twitter's OAuth screen says that these apps do not have access to Direct Messages. But they do! In short, users could be tricked into allowing access to their DMs. Restrictions There are some restrictions which Twitter has put in place in the name of good security. The most important of these is restricting callback addresses. After successful login, the apps will only return to a predefined URL. That means you can't take the official Twitter keys and send the user to your app. This is a sensible security decision. Except... Not every app has a URL. Or supports callbacks. Or is an actual app. Twitter has a secondary authorisation mechanism for such cases. You log in, it provides a PIN, you type the PIN into your app. It appears that these official PIN apps don't display the correct OAuth information to the user. Fixing it Will Twitter audit old apps and make sure the permissions are correctly displayed? I hope so! Ideally, Twitter should have a much more granular permissions model. Allow apps to read DMs, but not send them. Write tweets, but not delete them. Read Tweets, but not follow people. Timeline 2018-11-06 Submitted via HackerOne 2018-11-06 Provided clarification and PoC. Issue accepted. 2018-11-15 Proposed publication date of 30th November rejected due to US holidays. 2018-11-16 Bug Bounty of $2,940 offered. Filled in the W2 form to say I'm not a US taxpayer. 2018-11-17 Drank a fair amount of cider. 2018-11-21 £2,287.05 deposited in my UK bank account. There was also the option of receiving it via PayPal. 2018-12-06 Twitter fixed the issue and published the bounty payout. They let me know I was clear to publish. 2018-12-07 I provided clarification that the issue was still present on some API keys. 2018-12-14 Published this report. Responsible Disclosure: CloudFlare - more interested in tracking than security @edent — Tue, 20 Nov 2018 12:08:25 +0000 CloudFlare claim they want to secure the web - but they seem more interested in tracking their customers than giving them decent security. Upon registering with the Internet giant, users are encouraged to confirm their email addresses. So far, so standard. This is the confirmation message CloudFlare sends out: Looks good! Hey! I wonder where that garish orange button goes? WHAT!?! An http URl? Surely some mistake. Every baby-in-a-basket knows that we should use https everywhere. No matter, I'll click on the raw link underneath. That's got an https at the start, right? WRONG! Yup, the clumsy clowns at CloudFlare have managed to turn a secure URl into an insecure one. Bless. Why do they do this? Because they want to track every click on their emails. Their statistics are more important than your 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. It gets worse! Hey, at least email.cloudflare.com belongs to Cloudflare, right? Well... Not quite. Visit it, and you'll find that it is run by Customer.io's edge event collection service. Visit an incorrect URl like email.cloudflare.com/example and you'll be taken to Customer.io's site. Basically, if Customer.io gets hacked, or goes rogue, they can start phishing all of Cloudflare's customers. Nice... How to solve it? STOP TRACKING EVERY LINK IN YOUR EMAILS! Or, if you really have to - make sure your tracking server supports https and is controlled by you. Disclosure timeline I went through HackerOne in the vague hope of getting a tiny bug bounty. 2018-10-19 - Disclosed 2018-10-26 - Response from HackerOne asking for clarification 2018-10-27 - "We were able to validate your report, and we have submitted it to the appropriate remediation team for review." 2018-11-05 - Informed them that I indented to publish on the 19th. Received no objection. 2018-11-19 - Response from HackerOne "It looks like the problem has been solved and future emails will provide https:// verification links." 2018-11-20 - Published All this has happened before... This is an identical bug to the one I disclosed to Udacity who were kind enough to say thanks and send me some merchandising. Udacity Bug Bounty - or, please stop tracking every link in your emails @edent — Fri, 13 Apr 2018 10:50:15 +0000 Look, I know your company wants metrics. I know your boss wants to see the exact percentages of people who click on links in your emails. Your sales team are desperate to track conversions. Someone wants to optimise your funnel for reasons which are unclear to you, a lowly engineer. So you make the mistake of adding tracking to every email you send out. Including sensitive ones. I recently signed up to online learning platform Udacity. As part of registration, they want me to confirm my email address. Pretty normal behaviour. Because I'm a paranoid fellow, I wanted to see where the big VERIFY EMAIL link went. Ah! An insecure http link to their email tracking platform. Never mind, thought I, there's a plain link underneath that one. Hmmm.... I wonder where that goes. Oh, right. That's also insecurely tracked. To be clear, the text of the URl is https but the link it points to is http. What's the problem? 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. Your ISP can change the contents of that page and a malicious entity could - potentially - hijack your credentials. In this case, all the links go via SendGrid. You have no protection if they get hacked, or decide to harvest your credentials. How to solve it? STOP TRACKING EVERY LINK IN YOUR EMAILS! Or, if you really have to - make sure your tracking server supports https. Disclosure timeline There's no dedicated security contact for Udacity. I went through their regular contact page 2018-03-11 Asked to make responsible disclosure 2018-03-12 Udacity asked for more information. I sent details & screenshots. 2018-03-13 Report accepted and bug bounty issued. 2018-04-13 Publication. Reward Obviously, for a vulnerability of this magnitude, I was expecting a bug bounty of several million dollars. Nevertheless, I'm rather pleased with my free Udacity T-Shirt, sticker, pen, and notebook 😊 Self-inflicted Denial of Service on GitHub (Disclosed) @edent — Tue, 14 Feb 2017 07:36:16 +0000 I've found an interesting, but low severity, way for a malicious user to selectively deny access to specific GitHub issues and Pull Requests. This doesn't affect the whole site - just targeted pages. It doesn't require elevated permissions, nor any special skills. This is just GitHub punching itself in the face. Here's how it works. An attacker creates thousands of comments in their own repos which contain references to a specific issue or PR in an external repo. When that issue or PR page is loaded, GitHub tries to render every single reference from all repos. This often makes the page completely unavailable (Unicorn Error) and always slows down page loading and rendering time. Site owners are unable to remove the malicious links, leading to a either permanent degradation of page loading time, or a page which can never be loaded. Uses Suppose a GitHub issue is talking about a security vulnerability - a malicious actor can deny access to that page. Similarly, a competitor can disrupt your normal GitHub workflow. Users on slow / mobile Internet connections will have a markedly worse experience accessing pages. Examples A good source of examples is the Linux Kernel. Take a look at Pull Request #12. (Edit - this page now appears fixed and no longer times out.) Most of the time, the page fails to load. When it does load, it renders slowly on desktop. At the bottom are hundreds of links to places which appear to refer back to this. But they don't! Instead, the comments often contain lists of numbers like: #5 ffffffff812a12de (____fput+0x1e/0x30) #6 ffffffff8111708d (task_work_run+0x10d/0x140) #7 ffffffff810ea043 (do_exit+0x433/0x11f0) #8 ffffffff810eaee4 (do_group_exit+0x84/0x130) GitHub gets confused and thinks that those numbers refer to an Issue or Pull Request. When it tries to render the page, it can timeout while gathering all of the comments which appear to be links. In my experiments I found dozens of pages which repeatedly gave timeout errors. Severity and Disclosure This is a low impact bug. When there are thousands of comments across dozens of repositories, gathering all references can be time consuming. Once the servers have managed to successfully render the page, it reduces the likelihood of the page being blocked again. I reported it via HackerOne on the 13th of February. The next day GitHub responded: In the meantime, there isn't much you can do to protect yourself. There's no way to bulk remove malicious references. On GitHub's side, they should be truncating pages before a timeout occurs. They already do this on mobile - perhaps it should be standard everywhere?