1

Even though Authorization Code is short-lived comparing to Authorization token, isn't there a vulnerability in sending it in 'GET' as a query string? Isn't it similar to sending password using GET method?

In other words, after authentication facebook redirects user's browser to mysite.com sending the authorization code as a query string. Isn't it un-encrypted? middle man who is listening to your packets can read it and use it to highjack your session (session at mysite.com)?

Say,

  1. I blocked the redirect (after getting the 'code' from facebook) on my browser side (using some browser add-on/plug-in)
  2. I copied the complete redirect URL (www.mysite.com?code=AQCOtAV..blah) and trying it from a different browser.
  3. the request will go through and mysite.com will contact facebook with inbound Authorization Code along with secretKey and clientId and Authenticate and generate Authorization token (I haven't really tried this step : step 3)

I know I am missing something here. Kindly help me out.

KingJulien
  • 303
  • 3
  • 9
  • What vulnerability? What happens that should not be allowed to happen? – Kris Vandermotten Oct 12 '14 at 13:57
  • You are sending Authorization code over the network in unencrypted way. If there is any middleman listening to your packets, they will get the Authorization code and will be able to hijack the your session, right? – KingJulien Oct 12 '14 at 15:18
  • 1
    You're absolutely wrong. Please read the authorization code grant part in the specification. As a summary, code is securely exchanged for a token by the remote web application using a backchannel that you cannot see. Embedded applications use a different scenario. – Zólyomi István Oct 12 '14 at 16:58
  • Thanks Zólyomi. I understand that.. I am talking about one step before that, where user's browser gets the redirect (redirect to mysite.com) from facebook.... that time, when users browser send the 'authorization code' to mysite.com its unencrypted.. right? – KingJulien Oct 12 '14 at 19:51
  • 2
    Right, the authorization code is received as a GET parameter, but using a HTTPS connection. It's still possible to fetch it from the browser, but you need appropriate client_id/secret and redirect_uri to exchange it for a token, so only the appropriate webapp can do that. I don't see the vulnerability here. The specification considers a lot of different attack methods, please read it. – Zólyomi István Oct 13 '14 at 05:57
  • @ZólyomiIstván is correct. The authorization code is not secret, nor does it have to be (if a flow with a client secret is used). Things are different if an access token is sent that way, as in the Implicit Grant. Read the spec at http://tools.ietf.org/html/rfc6749. – Kris Vandermotten Oct 13 '14 at 07:06
  • And in addition to what @ZólyomiIstván already said, the authorization code is a one time code. As soon as you exchange it, it is useless. Even if a hacker already managed to exchange it before you did, you can detect that situation (and so can the authorization server), and the user can revoke their authorization. – Kris Vandermotten Oct 13 '14 at 07:12
  • @ZólyomiIstván Thanks! "authorization code is received as a GET parameter, but using a HTTPS connection" this answers my question. When I asked the OP I knew I was missing something... I just found out which piece was missing.. all this time I was thinking that query parameter sent in GET request is unencrypted and will appear as plain text (even if its https)... Guess what, I was wrong all this time! Thanks again. – KingJulien Oct 14 '14 at 02:18
  • I downvoted for the unclear question, unrealistic security assumptions and the RTFM-like nature. I'm willing to remove the downvote, but the site lets me do so only after you edit the question. Maybe you could clarify the question and summarize all this into an answer. – Zólyomi István Oct 14 '14 at 05:31

1 Answers1

1

Thanks @Zólyomi for pointing out that even though the authorization code is sent across as a query parameter, its using HTTPS to send.

Answer: The query string sent across https is secure. No matter which http method GET or POST you are using, its encrypted and no middleman can listen to it. More info. Is an HTTPS query string secure?

However for numerous other reason sending the password in query string is not a good practice (password may appear in server logs as plain text as part of the URL etc). But that doesn't apply here because the Authorization code is a short lived one and its useless once its exchanged for the Authorization token.

Community
  • 1
  • 1
KingJulien
  • 303
  • 3
  • 9