Warning: Illegal string offset 'filter' in /home/crypton1/public_html/mobilesecuritythreat.com/wp-includes/taxonomy.php on line 1409
Facebook had a long list of vulnerabilities and their Security team is incapable in dealing with the real world security. Unfortunately their mission of making the world open also aligns with Security principles as well. This is just the opinion and may not be the reality.
This vulnerability still exists and the author says in his blog that facebook repeatedly denied this since 2013.
Ahmed Elsobky (@MrEagle0x), a security enthusiast identified a flaw with the way how tokens are mobilized. As per the researcher, “Facebook allows the HTTP version of the Canvas URL to be used even if the app already has an HTTPS URI. Facebook also allows the request without any special tokens so anyone can make a request. (i.e Although Skype has a HTTPS Canvas URL, Facebook allows the HTTP link in redirect_uri parameter)”
Prerequisite for this exploitation :
The target user or victim must be logged into facebook (Not applicable for : Facebook Messenger, Facebook Camera, Facebook for android/ios/symbian since these are pre-authorized apps).
The Attack :
If the target user or victim is using apps such as Skype ,Spotify, Pinterest or anything similar, its possible to obtain access_token with the permissions of that application (Skype, Pinterest or similar ) by injecting this basic iframe into any webpage that this target user or victim visits :
<iframe src=https://www.facebook.com/dialog/oauth?redirect_uri=http%3A%2F%2Flogin.skype.com%2Flogin%2Foauth%3Fapplication%3Daccount&client_id=260273468396&response_type=token width=0 height=0>
Facebook allows the HTTP link at the redirect_uri parameter, so a GET request will be sent and the target user/victim observe a 302 redirect to that HTTP URL with the access_token value of the application with all of its permissions.
Access token with expires= [the current expiry value]
(usually zero with Skype and 0=never expires which will be in response which can be intercepted and exploited !!! BINGO
Considering above works you can use your own crafted urls in following format and replace anything you need without HTTPS.
URL/vector(http%3A%2F%2Fwww.facebook.com%2Fconnect%2Flogin_success.html&response_type=token&client_id=[app_id]) after the redirect_uri parameter[if the configuration of the application doesn’t allow this URL(http%3A%2F%2Fwww.facebook.com%2Fconnect%2Flogin_success.html)then use the Canvas URL of the application with HTTP instead of HTTPS]
This vector can be used if the user has authorized Facebook Graph APIs Explorer app( official app of Facebook used by many developers!) then an attacker can get access_token via the link (https://www.facebook.com/dialog/oauth?response_type=token&client_id=145634995501895&redirect_uri=http%3A%2F%2Fwww.facebook.com%2Fconnect%2Flogin_success.html) screenshot shown below of the same
“Generate a secret code/hash for every request(something like the gfid anti-CSRF token for users and a secret code for applications) that is required in order to accept the request before any access_token value get returned! something like this:
https://www.facebook.com/dialog/oauth?redirect_uri=<URL>&client_id=ID&secret_code=XXXXXX ” — recommends by Ahamed to fox this issue in his blog
Recommendation to protect yourself :
i) Using “HTTPS’ Everywhere” Browser Extension which is available from EFF (https://www.eff.org/https-everywhere)
ii) Avoid using apps which doesn’t use SSL
The research on this post was extracted from Ahmed