I reported it on HackerOne, it was only after I refused to post it on their free program that they added me to their paid private one.

It was marked as "medium", I got $250 for it.

https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L...

But I think how private that data is to the end user should also be taken into account. It’s a medium for technical risk (relative to server remote exec), but it should be seen as a high priority for the company and rewarded as such.

If an end user were to ask that company “why did you leak all my private data” their response would be “your data is worth less than $250 in human labour and is seen as a medium security risk”?

CVSS scores are put into audit reports --- at the ouiji levels clients want --- to shut up the suits in compliance.

I'm not aware of any programs on HackerOne that don't follow this practice, so it's not "super uncommon".

I modified the assumptions that were made by the reporter and came out with Low.

This is one example of why this is a nonsense metric.

Compared with hiring a pen testing team, offering high bounties seems like a bargain as you get actual exploits that would impact the company.

I have, uh, some experience with the rates here.

"XSS bug in a popular note taking app ... attacker to download all the users notes just by having them visit a URL"

So as to not feel worried that future vulnerabilities would get sold on the black market instead

Interesting to hear,

Makes me think that there is not any big marked for exploits targeting smaller companies. Maybe such exploits (for smaller products) would be useful primarily for spear phishing? and not bring in so much money if sold, & hard to find a buyer?

Still, if the note taking app was sth well known like Ev*rnote, I wish they'd pay more. (No idea if it was.)

Don't undervalue the intangible permanence of doing the right thing, character outlasts cash come the grave.

Just curious - what makes XSS on the desktop different from other kinds of RCE vulnerability?

Electron used to default to insecure. You were basically running a web browser except with full access your entire machine file system/camera/mic/network etc. If you are an inexperienced developer it wasn't obvious that live linking to any 3rd party code could be an issue. Electron kind of fixed that. They warn you now and default to more secure. How many devs are capable of keeping it secure is up for debate.

As a related issue, it used to be (maybe still is) that by default, links you click in Electron open in Electron. So you make any app that accepts user data and links and suddenly people are browsing the entire net in an un-secured browser.

And worse, they break stuff. I made an electron app and explicitly made it so all links open in the user's browser. I updated to a new version and then to my horror found whatever I had done to make sure links opened in an external browser stopped opening links in an external browser.

Native apps can have exploits but most native apps aren't designed to be an environment for running arbitrary code. They're only an app for working on data.

Note, I love Electron, I've used it for several projects and it's great. But I'm also afraid of it and wish OSes were themselves more sandboxed so I didn't have to worry about it.

This is simply not true in a plurality of cases (eg, it implies that applications running under qemu are incapable of having RCE vulnerabilities) and frankly sounds like a distinction that was made up to avoid admitting that script tags are RCE bugs in web browsers.

By the way, the security bounty should be mandatory to display to customers. It’s like saying “We don’t value the sum of all your data of all customers to more than $1750”.

A better solution would be to only allow a bug to be reported once per quarter, or once per version of the software. If someone finds a bug in v1.0 that's fixed in v1.1, then someone (even the same person) should be able to report the same bug in a different place in v1.1. That's an incentive for companies to use the report to secure the whole app rather than just fixing the reported issue.

But you might have the same vulnerability found in several different places. Reports should really only be considered duplicates if the fix to one automatically fixes the other also. Your bug found in multiple locations might happen to be set up that way -- or it might not.

This exact problem occurs frequently when a company with a bounty program makes an acquisition and brings the new software into scope for the program. The acquired code is often full of relatively easy-to-find, high-impact bugs. What I've seen people do in this case is open the scope, accept a certain number of reports, and then suspend eligibility for that software for a certain period of time.

This would look like "we've had a lot of similar bugs filed against company-we-acquired.com, and we're taking that domain out of scope for X weeks while we work on it."

https://en.m.wikipedia.org/wiki/Zerodium