Security Radar 21

[gratipay-bot]

← Security Radar 20

---

Docs

http://inside.gratipay.com/howto/sweep-the-radar

Mission

The mission of the security team is to protect our sensitive information.

Scope

• our HackerOne account
• the "Handle Security Issues" document
• Security Team issues
• the legacy Hall of Fame page on gratipay.com
• the @gratipay/security team
• the https://github.com/gratipay/security repo
• the [email protected] email address

Queue

Unclear Risk

https://hackerone.com/reports/117195

Severe Risk

Moderate Risk

https://hackerone.com/reports/127218
https://hackerone.com/reports/128844

Mild Risk

https://hackerone.com/reports/76304
https://hackerone.com/reports/80907
https://hackerone.com/reports/90805
https://hackerone.com/reports/108645
https://hackerone.com/reports/109161

https://hackerone.com/reports/111325
https://hackerone.com/reports/117187
https://hackerone.com/reports/117739
https://hackerone.com/reports/117984
https://hackerone.com/reports/118023

https://hackerone.com/reports/118699
https://hackerone.com/reports/123688
https://hackerone.com/reports/123697
https://hackerone.com/reports/128121
https://hackerone.com/reports/140387

https://hackerone.com/reports/140432

Theoretical Risk

https://hackerone.com/reports/78151
https://hackerone.com/reports/90777
https://hackerone.com/reports/116147
https://hackerone.com/reports/117142

https://hackerone.com/reports/117833
https://hackerone.com/reports/123942
https://hackerone.com/reports/123897
https://hackerone.com/reports/124096

https://hackerone.com/reports/127824
https://hackerone.com/reports/127949
https://hackerone.com/reports/127995
gratipay/gratipay.com#823
https://hackerone.com/reports/137002

https://hackerone.com/reports/138693

[chadwhitacre]

@Nashe Currently we maintain a list of all of our HackerOne issues in the description here on the Security Radar. I've removed 120026 now that it's closed. Can you help us maintain this list? I realize it's not ideal, but we need some way to visualize how many of each risk category we have—since the whole point of classifying them that way is to help us focus our attention on the higher risks first. We may be able to use the HackerOne API for this, as we do with our disclosures (though it'd be more complex since we'd have to authenticate). HackerOne's own UI doesn't give us a good way to see this ranking, that I've found.

[ghost]

@whit537 OK!
I'll close 136720 too (we talked about this yesterday), and I won't forget to remove it from this ticket too.

[chadwhitacre]

@Nashe Awesome, thanks. :) There may be some additional drift, with tickets open in HackerOne that aren't reflected here.

[ghost]

@whit537 Ticket 136720 closed, removed from the list. I'm finishing the "big-picture" translation (and some personal work :P) and I'll focus on closing all the HackerOne reports, because the "Average time to resolution: 2 months" on our HackerOne page is not very pretty ;-(

[ghost]

We closed closed ~15 H1 reports in the last two days, the ones left will take more time to fix but we are on track! Thanks for the help @whit537 o/

[chadwhitacre]

!m @Nashe

Awesome work! 👍 💃

[chadwhitacre]

Received in email to [email protected]:

We got a note saying you want to change your email address for the @know.0nix account to [email protected].

Security researcher?

[chadwhitacre]

I've deleted the mail in Freshdesk, to avoid accidentally clicking "confirm." :)

[TheHmadQureshi]

@Nashe Kindly don't use Not Applicable state for invalid bugs. As we don't reward researchers with great bounties, if we start giving N/A we won't get bug reports because N/A state hurts the reputation and signal both of researcher's profile.
Use informative instead, it's a great alternative.

[ghost]

OK, noted.

[chadwhitacre]

I think it's okay to use N/A when someone files a report that we've already disclosed as "No Risk." But yeah, I agree with @TheHmadQureshi that the first time someone reports something which we determine is No Risk, we should use Informative.

[ghost]

I think that the confusion came from the fact Gratipay's "No risk" is like a mix of "Informative" and "N/A", while HackerOne's "Informative" is defined as "useful information but no need for an immediate fix since it's not a big risk/vulnerability" and N/A "Invalid or irrelevant". Their "Informative" is in fact more related to Gratipay's "Theoretical" definition ("Let's fix it but don't make it a priority").

To my mind, reporting a nosniff on a service which is only serving static content and where 0 file is uploaded by arbitrary users or telling that we can find that grtp.co is powered by nginx can't be categorized as "Informative" if we strictly follow HackerOne definition. I suppose that the signal/reputation system was precisely created to avoid nearly-automatic reports like the ones that were closed the last days.

I also think that the HackerOne policy should be kept up-to-date with the "No risk" reports (eg. directory listings) we had (I'll do it if you are both OK) to get less N/A/OOS/Duplicates reports.

By the way, I will follow what you both said for future reports, I'm just trying to make this progress if there is a need to ;-)

[chadwhitacre]

I also think that the HackerOne policy should be kept up-to-date with the "No risk" reports (eg. directory listings) we had (I'll do it if you are both OK) to get less N/A/OOS/Duplicates reports.

We already say "Review our No Risk disclosures to avoid filing unwanted reports". Is that not enough?

[ghost]

Depends if you think that something without any risk is out of scope or not?