Graphql-engine: Bug bounty for high impact security flaws like the one fixed in 1.2.0
If my interpretation of the patch commit is correct, the bug fixed in the latest release is indicative of distressingly lax fuzzing and security assessment of a product that guards the APIs of legions of websites. I'm building a company that works in information security and I've chosen to build a lot of our web presence off the back of Hasura. I would feel immensely more comfortable continuing to do so if the developers used a platform like HackerOne to crowdsource penetration testers so that extreme low hanging fruit like the aforementioned bug are harder to find, and when they are found, attackers are incentivized to report to Hasura rather than hack every internet-connected hasura instance available. It would be a great pain at this point in development to move off of hasura, but a recurrence of bugs like this (especially in an open source project where they are trivially reversible and there is almost no patch window) is something that could personally force us to do it.
hugbubby
>All comments
@hugbubby All valid points. The 1.2.1 release patched a very serious issue. Over the last week we’ve done a full retrospective to figure out what went wrong and how to best prevent situations like this in the future. This regression was introduced because of a refactor in 1.2-beta5 and a missing negative test.
We’ve put together an issue (#4736) consolidating the immediate next steps (that covers the points you mentioned as well) that is at the top of our backlog and tweaked our PR review process as well. We can move further discussions on this topic to that issue to consolidate discussions.
We’ve followed our vulnerability and disclosure process for issuing and distributing this patch. We were able to issue a patch within 6 hours of discovering the issue and subsequently reached out to vendors and users with whom we have direct communication channels. Our next wave of communication was via our security mailing list and discord. We then made the release public on GitHub so that “watchers” are identified. Our final step was publishing the advisory today. For this last step, we waited about 7 days along with observations on our telemetry to make sure the trend shifted to 1.2.1 from 1.2. For folks who’re reading this issue please do make sure that you’re on the security mailing list and are watching this repo for future release notifications.
Thankfully, we have not had a bug like this so far, given our testing and reviewing process. This was a very unfortunate occurrence and has prompted us to immediately improve our tests & processes so that this doesn’t happen again, especially adding element of fuzz-testing like you mentioned to counter human gaps. Incidentally, we had also already started discussions with hackerone/bugcrowd and that is in the final stages of being processed too and we should be live with a bug bounty program soon!
coco98
on 11 May 2020
Related issues
codepunkt
·
3Comments
cpursley
·
3Comments
tirumaraiselvan
·
3Comments
lishine
·
3Comments
hooopo
·
3Comments
Most helpful comment
@hugbubby All valid points. The 1.2.1 release patched a very serious issue. Over the last week we’ve done a full retrospective to figure out what went wrong and how to best prevent situations like this in the future. This regression was introduced because of a refactor in 1.2-beta5 and a missing negative test.
We’ve put together an issue (#4736) consolidating the immediate next steps (that covers the points you mentioned as well) that is at the top of our backlog and tweaked our PR review process as well. We can move further discussions on this topic to that issue to consolidate discussions.
We’ve followed our vulnerability and disclosure process for issuing and distributing this patch. We were able to issue a patch within 6 hours of discovering the issue and subsequently reached out to vendors and users with whom we have direct communication channels. Our next wave of communication was via our security mailing list and discord. We then made the release public on GitHub so that “watchers” are identified. Our final step was publishing the advisory today. For this last step, we waited about 7 days along with observations on our telemetry to make sure the trend shifted to 1.2.1 from 1.2. For folks who’re reading this issue please do make sure that you’re on the security mailing list and are watching this repo for future release notifications.
Thankfully, we have not had a bug like this so far, given our testing and reviewing process. This was a very unfortunate occurrence and has prompted us to immediately improve our tests & processes so that this doesn’t happen again, especially adding element of fuzz-testing like you mentioned to counter human gaps. Incidentally, we had also already started discussions with hackerone/bugcrowd and that is in the final stages of being processed too and we should be live with a bug bounty program soon!