[bsamuels]

Seriously. I don't think the researcher realizes how many people try to bypass hackerone because H1 would have flagged their finding as invalid.

Using h1 isn't about bug bounties, it's about not having to spend a 1-2 of your team's full time engineers triaging security researcher reports.

[thaeli]

If H1 was willing to take and triage reports without requiring acceptance of their terms and NDA, that would be fine.

We also need to be very clear that the moment a company, or it's authorized representative, flags something as a wontfix or "not a security issue", full and immediate disclosure is fair game.

[tptacek]

I think that clarity already exists.

[0x457]

We had some of the dumbest H1 "findings" at some companies that I worked:

- Service that is explicitly out of scope of program is "leaking" default CloudFront headers.

- Android application can be decompiled (that's it, not secret is there, just the fact that it's possible)

- "I can do something bad IF I had a way to load malicious JavaScript" (no, CSRF protection was one and correctly implemented) (there is also no way to upload your own JavaScript)

- "I can do things if I open a console in a browser" (can't do anything because CORS policy only allowed for read-only endpoints)

- "You can make requests with CURL and not official client"

Every week, there was at least one variation of one of those reports. "Hackers" also got very defensive about their "findings" and acted like we don't want to pay them for some "mega hack of the year 0day total domination of user device" vulnerabilities.

Not once has anyone found even a minor vulnerability, just wannabes trying to get quick cash. Until we had H1 we had zero reports, with H1 we had moronic reports every other day.

[kstrauser]

This has been my experience, too, with security reports in general. We see things like:

- "An attacker could spoof an email from you to a user." (POC video shows Yahoo webmail succeeding. We try the same thing in Gmail, and it gets sent to the spam folder because it fails SPF and DKIM.)

- "If I try logging in as a user with an invalid email too many times, it locks them out of their account. That's a denial of service." (Well, yeah, and that's a bummer, but it beats allowing an attacker unlimited attempts.)

I'll say, though, that H1 has been super helpful at screening the worse reports. Sometimes they'll initially block reports like the above, but the researcher will insist that this time it's for real. I don't feel too bad closing those reports as invalid.

In all, I'm a very happy H1 customer. They've been good to work with.

[Sohcahtoa82]

My favorite was an e-mail titled "[Critical Urgent] Vulnerability Report 1 : Clickjacking On Login Lead to Account Takeover Of Any User/Cross Site Scripting Attacks/DOM Based Xss/Csrf Attacks/Deletion OF Account/User Account Privilege Escalation/Victim Privilege Escalation/Malware Execution/Victim PC Hijack/Unauthorized Access To Any User Account/Account Takeover Of All The Users Registered On Your Application"

The finding that we didn't include the "X-Frame-Options: DENY" header was correct, but the app simply doesn't work in an iframe anyways, so it wasn't exploitable.

It certainly wouldn't result in all the other things listed.

[UncleMeat]

Not only have I seen similarly stupid reports, I’ve received death threats from “researchers” who didn’t receive the payout they expected for basically clicking “inspect element” in their browser.

[RHSeeger]

Then they should provide a path that doesn't involve arbitrary NDAs if you're willing to forego the reward.

[tptacek]

That path already exists: it's called "email security@vendor, tell them what you found, ask when a patch is expected, and then tell them they have 60 days".