4 ms·

"Facebook" (or whoever) just sends a token that says the user authorized the use of its account for the application. What happens in this 'hack' is that the tok

"Facebook" (or whoever) just sends a token that says the user authorized the use of its account for the application. What happens in this 'hack' is that the token is valid, but was not actually intended for that application, but for another one (e.g. a malicious one, that is now trying to reuse the token to access other services of the same Facebook user). I don't know how Facebook tokens look like, but JWTs have a property called aud/audience indicating who the token was intended for. The application developer must verify that the token was actually intended for their application. That is my understanding, sorry if I got it wrong.

dboreham 3y ago
I get that. You're not wrong. I'm asking why Facebook tells the application anything other than "nope, that's not valid for you"? It doesn't seem to be a case of the application will accept random noise as a valid token. It does send the token to Facebook and Facebook responds with something that looks like "OK". But when they said "OK" they really meant "we gave you some valid information about the target user, but forgot to mention that the token you provided was not valid". I'm saying that Facebook should in all cases respond with "Nope, that's not a valid token". Their API just shouldn't have a way to get data on a user without providing a valid token (by valid, we mean valid for that purpose, not stolen from somewhere).
- locallost 3y ago
  Because I guess in this "flow", you do not actually supply the information to Facebook for them to verify that claim. From the article: > In steps 6-7: > randomsite.com reads the token from the URL and uses it to talk directly with Facebook using the following API: > https://graph.facebook.com/me?fields=id,name,email&access_token=[secret_token] https://graph.facebook.com/me?fields=id,name,email&access_to.... > The response is john@gmail.com. So you send the token only and the token is valid, and there's no way for Facebook to check if it was meant for you or not. As mentioned in other posts, this would not happen in other flows because you would send e.g. your client secret along with the code.
  - fulafel 3y ago
    The question still is, are Facebook failing to associate the token with the application context that requested it?
    - locallost 3y ago
      Failing sounds like its a requirement for them to do it, but this is not true. If you send them just a token, then how would they associate it with the application? Like I said, in another flow where you send your client secret and a code to exchange for the token, they need to verify it and it would be a failure on their part if they didn't.
      - fulafel 3y ago
        They have the client id when the token is requested, so they can associate the generated token with it by either keeping some state or encoding it in the token, no?

dboreham 3y ago

I get that. You're not wrong. I'm asking why Facebook tells the application anything other than "nope, that's not valid for you"? It doesn't seem to be a case of the application will accept random noise as a valid token. It does send the token to Facebook and Facebook responds with something that looks like "OK". But when they said "OK" they really meant "we gave you some valid information about the target user, but forgot to mention that the token you provided was not valid". I'm saying that Facebook should in all cases respond with "Nope, that's not a valid token". Their API just shouldn't have a way to get data on a user without providing a valid token (by valid, we mean valid for that purpose, not stolen from somewhere).

locallost 3y ago
Because I guess in this "flow", you do not actually supply the information to Facebook for them to verify that claim. From the article: > In steps 6-7: > randomsite.com reads the token from the URL and uses it to talk directly with Facebook using the following API: > https://graph.facebook.com/me?fields=id,name,email&access_token=[secret_token] https://graph.facebook.com/me?fields=id,name,email&access_to.... > The response is john@gmail.com. So you send the token only and the token is valid, and there's no way for Facebook to check if it was meant for you or not. As mentioned in other posts, this would not happen in other flows because you would send e.g. your client secret along with the code.
- fulafel 3y ago
  The question still is, are Facebook failing to associate the token with the application context that requested it?
  - locallost 3y ago
    Failing sounds like its a requirement for them to do it, but this is not true. If you send them just a token, then how would they associate it with the application? Like I said, in another flow where you send your client secret and a code to exchange for the token, they need to verify it and it would be a failure on their part if they didn't.
    - fulafel 3y ago
      They have the client id when the token is requested, so they can associate the generated token with it by either keeping some state or encoding it in the token, no?