21–30 of 114 posts
Earlier quoted context omitted.
They're a small company with an even smaller engineering team, I think 13 devs or something like that. I would imagine either everyone knows about it immediately or they are too overloaded with work that it gets deprioritised into oblivion after a quick first look.
If they had time to rewrite the whole native app to React Native then they should have enough time to triage this security issue.
Worth quoting here... "...In the process of disclosing and patching this vulnerability, the Harvest team was barely responsive. The company acknowledged the vulnerability by triaging but took a very long time to fix the vulnerability. After 3 years of reporting, the company finally fixed the vulnerability silently and didn't bother to inform...no bounty or even HackerOne points were rewarded by the company..." And fr…
Lol
I really feel like Hackerone isn't really holding up their end of the bargain if they let companies sit on things like this for 3 years.
Hackerone is beholden to the company running the bug bounty program. The extent that they are involved heavily depends on what services they are providing (triage, etc). At the most basic level, they're just providing a platform for disclosure of vulnerabilities and some boilerplate legalese to prevent legal departments from sueing researchers. In the vast majority of cases, companies deny requests for public disclos…
A key part of responsible disclosure is the disclosure part.
Often researchers would disclose unpatched issues to put weight on companies, even large companies, to actually patch issues.
One of the side-effects of programs like Hackerone is that actually doing your own responsible disclosure is now frowned upon (often to the point of legal problems).
But part of the social contract of absorbing coordinated disclosure should be an expectation that hackerone allows disclosing even unfixed issues.
Hackerone should not be "beholden" to companies. They make the rules. They could allow disclosure of issues if they wanted to make that a condition of the platform.
It's companies sitting on vulnerabilities that birthed the concept of "responsible disclosure" in the first place. If H1 etc are allowing it then there needs to be renaisance of the practice outside the platforms.
Can someone with OAuth expertise explain this issue in a few more details, as I've read the blog a few times, but still don't understand the actual vulnerability. From my very limited OAuth knowledge isn't this how it works: 1. The Harvest application asks Microsoft to verify a user. 2. The user is verified by Microsoft. 3. If the user verification is successful Microsoft redirects back to the callback URL, passing b…
The vulnerability came from the outlook-integration.harvestapp.com. It used a JSON object as `state` containing instructions once the OAuth2 Callback succeeded. The property `subdomain` was used to redirect the browser to a subdomain of harvestapp.com, passing the `#id-token`. The problem came from the fact that the value of `subdomain` was injected directly to: https://${subdomain}.harvestapp.com/...#id-token= ... B…
1. Make sure the redirect url is a valid harvestapp.com (more checks on state)
2. Encrypt the state since the start of the request, so then they can double check the state hasn't been forged by decrypt and compare
Is there any option beside those?
These are in fact harvest's tokens, which only erroneously exposed access to their app, because of an injection vuln in their code, and would be exactly as compromised behind any other IdP.
I really feel like Hackerone isn't really holding up their end of the bargain if they let companies sit on things like this for 3 years.
Of the three parties involved (HackerOne, the company, and the researcher finding the bug), the company has all of the leverage. If they feel like HackerOne is stepping on their toes and making decisions as to whether to "let" companies do things, those companies will just leave HackerOne and create an in-house solution.
Can someone with OAuth expertise explain this issue in a few more details, as I've read the blog a few times, but still don't understand the actual vulnerability. From my very limited OAuth knowledge isn't this how it works: 1. The Harvest application asks Microsoft to verify a user. 2. The user is verified by Microsoft. 3. If the user verification is successful Microsoft redirects back to the callback URL, passing b…
The vulnerability came from the outlook-integration.harvestapp.com. It used a JSON object as `state` containing instructions once the OAuth2 Callback succeeded. The property `subdomain` was used to redirect the browser to a subdomain of harvestapp.com, passing the `#id-token`. The problem came from the fact that the value of `subdomain` was injected directly to: https://${subdomain}.harvestapp.com/...#id-token= ... B…
* the additional redirect using the JSON object in state * the `subdomain` not being properly verified * the implicit grant being supported
Which allowed an attacker to get an access token for a user's Microsoft account.
From my reading, this seems to be entirely an issue due to an improper implementation on Harvest's side, nothing to do with Microsoft's implementation of OAuth. Am I correct?
Earlier quoted context omitted.
The vulnerability came from the outlook-integration.harvestapp.com. It used a JSON object as `state` containing instructions once the OAuth2 Callback succeeded. The property `subdomain` was used to redirect the browser to a subdomain of harvestapp.com, passing the `#id-token`. The problem came from the fact that the value of `subdomain` was injected directly to: https://${subdomain}.harvestapp.com/...#id-token= ... B…
Good explanation. Quick follow up, so to resolve this issue, what I have in mind are : 1. Make sure the redirect url is a valid harvestapp.com (more checks on state) 2. Encrypt the state since the start of the request, so then they can double check the state hasn't been forged by decrypt and compare Is there any option beside those?
Earlier quoted context omitted.
I'm guessing, as would be typical of many companies, it ended up on a backlog as low priority, survived a few Jira reorganisations and corporate restructuring, before eventually being noticed and fixed.
They're a small company with an even smaller engineering team, I think 13 devs or something like that. I would imagine either everyone knows about it immediately or they are too overloaded with work that it gets deprioritised into oblivion after a quick first look.