javascript - SINGLE SIGN ON SECURITY THREAT! FACEBOOK access_token broadcast in the open/clear -

02/20/2011:

it confirmed facebook today indeed there 1 call in access_token broadcast in open . . . happens 1 call use make sure user still logged in before saving application database. recommendation use ssl option provided of last month canvase , facebook whole. part auth , auth secure.

findings:

subsequent posting there remark made not question thought did indeed postulate one. there no ambiquity here question lead in:

since there no data sent facebook during canvas load process not @ point divulged, including access_token, session , other data uniquely identify user, 1 see other way other adding 1 more layer, i.e., password, sent on wire via https along access_toekn, insure unique untampered security user?

using wireshark captured local broadcast while loading canvas application page. hugely surprised see access_token broadcast in open, viewable 1 see. access_token appended https call facebook opengraph api.

using facebook single click log on has raised huge concerns me. stored in session object in memory , cookie cleared upon app termination , after reviewing fb.init calls saw lot of https calls assumed access_token encrypted.

but last night saw in status bar call http call included app id felt should sniff application canvas load sequence.

today did sniff broadcast , in attached image can see there http calls access_token being broadcast in open , clear gain access to.

am missing something, seeing , interpretation correct. if 1 can sniff , access_token can theorically make calls graph api via https, though call still need site established in facebook's application set up.

but security threat using access_token access own site. not see value of single sign on via facebook if thing established secure access_token - becuase can see not secure. access tokens never have expire date not change. access_tokens different every user, access site held tight single user, compromising single user's data unacceptable.

http://www.creatingstory.com/images/intheopen.png

went , did more research on this:

findings:

went re ran canvas application verify not of code not broadcasting.

in call: http /connect.php/en_us/js/cachedata http/1.1

the user id visible in cookie. user_id's visible, already. can go pretty ones page , hover on image , see user id. no big threat. app_id obtainable - . . .

http://www.creatingstory.com/images/intheopen2.png

the above file shows full access token in open via facebook initiated call.

am wrong. tell me wrong because want wrong this.

i have since reset app secret showing real sniff of canvas page being loaded.

additional data 02/20/2011:

@ifaour - appreciate time took compile response.

i pretty familiar oauth process , have pretty solid understanding of signed_request unpacking , utilization of access_token. perform substantial amount of processing on server , facebook server side flows complete , function without flaw know of. application secret secure , never passed front end application , changed regularly. being fanatical security can be, knowing there don’t know come , bite me.

two huge access_token issues:

the issues concern possible utilization of access_token user agent (browser). during fb.init() process of facebook javascript sdk, cookie created object in memory called session object. object, along cookie contain access_token, session, secret, , uid , status of connection. session object structured such supports both new oauth , legacy flows. oauth, access_token , status pretty al used in session object.

the first issue access_token used make https calls graph api. if had access_token, browser:

https://graph.facebook.com/220439?access_token=...

and return ton of information user. 1 access token can gain access facebook account. can make additional calls info user has granted access application tied access_token. @ first thought call graph had have callback url established in app setup, tested mentioned below , return info right browser. adding callback feature idea think, tightens things bit.

the second issue utilization of unique private secured data identifies user third party data base, i.e., in case, use single sign on populate user information database using unique secured data item (i.e., access_token contains app id, user id, , hashed secret sequence). none of problem on server side. signed_request, unpack secret, make https calls, https responses back. when user has information entered via user agent(browser) must stored via post, unique secured data element sent via https such validated prior data base insertion.

however, if there no secured piece of unique data supplied via single sign on process, there no way guarantee unauthorized access. access_token 1 piece of data utilized facebook make https calls graph api. considered unique in regards both user , application , secure via signed_request packaging. if however, subsequently transmitted in clear , if can sniff wire , obtain access_token, can pretend application , gain information have authorized application see. tried above example safari , ie browser , returned of information me in browser.

in conclusion, access_token part of signed_request , how application obtains it. after oauth authentication , authorization, i.e., user has logged facebook , runs app, access_token stored mentioned above , have sniffed such see stored in cookie transmitted on wire, resulting in there being no unique secured identifiable piece of information can used support interaction database, or in other words, unless there 1 more piece of secure data sent along access_token database, i.e., password, not able discern if legitimate call. luckily utilized secure ajax via post , call has come same domain, sure there way hijack that.

i totally open ideas on topic on how uniquely identify users other adding layer (password) via single sign on process or if share me read , analyzed data incorrectly , access_token secure on wire.

mahalo nui loa in advance.

i not terribly familiar facebook's authentication/authorization methods, believe implement oauth (or close it) delegation, distributed authorization, , "single sign-on".

oauth described rfc-5849
edit: facebook uses oauth 2.0 still in working draft.

in oauth, , similar systems, "access_token" part of picture. there typically secret key, known service provider (facebook) , client application (your app). secret key part expected stay secret - , part never sent on wire (after it's initial issuance).

in case of facebook, think secret key assigned when register application use api, , 'access_token' returned given user, whenever user agrees allow app access info.

messages sent in clear, including user's username, , relevant "access_token"; however, each message must include valid signature in order accepted server. signature cryptographically computed string, created using technique called hmac.

computing hmac signature requires both token , secret, , includes other key parts of message well. each signature unique given message contents; , each message uses nonce ensure no 2 messages can ever identical.

when server receives signed message, starts extracting access_token (clear-text), , determining app token issued for. retrieves matching secret own local database (the secret not contained in message). finally, server uses clear-text message, clear-text access_token, , secret compute expected hmac signature message. if computed signature matches signature on received message, message must have been sent knows same secret (i.e. application).

have @ section 3.1 of rfc-5849 oauth specific example, , further elaboration on details.

incidentally, same approach used amazon control access s3 , ec2, other service providers offer api access long-term authorization. suffice - approach is secure. might little counter-intuitive @ first, makes sense once think through.

---

adding few links , quotes facebook documentation:

• facebook indeed using hmac-sha256 algorithm. registration document (php example reading signed_request section).
• always verify signed_request:

if unable validate signed_request because can't embed application secret (e.g. in javascript or desktop application) must use 1 piece of information payload, oauth_token.

• the authentication document contains lot of useful info different flows may use authenticate user. read security considerations section @ bottom of page:

cross site request forgery attack in trusted (authenticated , authorized) user unknowingly performs action on website. prevent attack, should pass identifier in state parameter, , validate state parameter matches on response. recommend app implementing facebook user login implement csrf protection using mechanism.