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

Post by jdironman » Sun, Oct 22, 2023, 6:07 PM UTC

eterm wrote: post #23

EE84M3i wrote: post #16

Earlier quoted context omitted.

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…

So, bug bounty programmes sprung up as a well to help coordinate disclosure and help researchers engage in responsible disclosure. 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 disclos…

Post by mjevans » Sun, Oct 22, 2023, 6:31 PM UTC

driverdan wrote: post #20

Why wait 3 years for them to fix this? 90 days is more than enough time before disclosing it.

Post by Operyl » Sun, Oct 22, 2023, 7:12 PM UTC

michaelt wrote: post #64

scurvy_steve wrote: post #56

Earlier quoted context omitted.

They are adding a second redirect on top and sticking it into the state parameter, presumably so they can redirect to anywhere. so the flow wanted was Go the some harvest authorize url, That redirects to the Microsoft authorize url with redirect_uri=registered_uri and state=some_encoded_final_uri, user enters credentials, redirect to a registered uri read state parameter and redirect to uri encoded in state. This exp…

It's kinda normal that you'd want to let a user log in and return them to the page they were at. For example, if you're making a shopping website and a user asks to put something in their basket and you send them to log in, you'd want to return them to the item they were about to buy, not dump them back at the homepage. What's the proper way of doing this, without "abusing state" ?

Post by dang » Sun, Oct 22, 2023, 7:21 PM UTC

0xcrypto wrote: post #52

nurple wrote: post #51

Earlier quoted context omitted.

If only tokens minted by MS were in scope of the vulnerability because of Harvest's outlook integration, maybe something like "Harvest OAuth CSRF Leaks Tokens of Microsoft Outlook Users" or "CSRF in Harvest's Outlook Integration Leaks User Tokens". If you want to add any editorializing around mitigation, linking to the OAuth RFC[0] that dictates a MUST for binding the users auth state with the request to prevent such…

Oh yes, that sounds better. I am changing the title now. Updated to "Stealing OAuth tokens of connected Microsoft accounts via open redirect in Harvest App"

Post by johncolanduoni » Sun, Oct 22, 2023, 7:34 PM UTC

michaelt wrote: post #64

scurvy_steve wrote: post #56

Earlier quoted context omitted.

They are adding a second redirect on top and sticking it into the state parameter, presumably so they can redirect to anywhere. so the flow wanted was Go the some harvest authorize url, That redirects to the Microsoft authorize url with redirect_uri=registered_uri and state=some_encoded_final_uri, user enters credentials, redirect to a registered uri read state parameter and redirect to uri encoded in state. This exp…

It's kinda normal that you'd want to let a user log in and return them to the page they were at. For example, if you're making a shopping website and a user asks to put something in their basket and you send them to log in, you'd want to return them to the item they were about to buy, not dump them back at the homepage. What's the proper way of doing this, without "abusing state" ?