scurvy_steve's comments

I work on low code cloud ETL tools. We provide the flexibility for the customer to do stupid things. This means we have extremely high variance in resource utilization.

An on demand button press can start a processes that runs for multiple days, and this is expected. A job can do 100k API requests or read/transform/write millions of records from a database, this is also expected. Out of memory errors happen often and are expected. It's not our bad code, its the customer's bad code.

Since jobs are run as microservices on isolated machines, this is all fine. A customer(or multiple at once) can set up something badly, run out of resources, and fail or go really slow and nobody is effected but them.

First, just don't enable implicit grant. That makes it a lot harder to screw up.

State is for preventing CSRF, not transferring data. Don't abuse state, it's wrong.

Use your own authorize url, add an encrypted cookie and redirect to the real one. Even if the cookie is encrypted, only put some kind of session/cache key in it, don't actually send "info". Read cookie in callback then delete it.

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 exploit still redirect to an authorized uri, but that endpoint then reads the the state parameter and happily forwards the response/token.

3 mistakes in this, abusing state, not encypting and validing state if you are going to abuse it. Enabling implicit grant(even if they needed it, should have made a second registration with limited uses).

It uses what's sometimes referred to as WTF-16. It's UTF-16 but with no actual guarantee that its well formed(i.e. invalid surrogate pairs).

- Always use a response envelope

I would mostly agree except in 1 case, streaming data is easier without an envelope. Making some array inside an envelope stream is usually more code and messier than just getting some metadata out of header. So if you have something like data integration endpoints and you expect someone could pull many megs of records, consider no envelope.

I have an app based around some long running resource intensive processes that run on scalable microservices. So you click a button and may have to wait 5+ minutes before you get a response. Websockets let you do notifications and make everything async. They've served me well for request/response that might take 3-30 minutes.