Horseluke · 2013/09/13 15:06
0 x00 background
Looking at the history of account communication, we can find that OAuth is more popular than other protocols (such as OpenID) because both sides of the business not only require the authentication of the account itself (authentication; It can be understood as “what is my name and who is my name on both sides of the territory”), but more needs the authorization of business flow of both sides. Can be interpreted as “what can I do on both sides’ turf”), because it is the latter that yields real mutual benefits.
As 2013 approaches the middle of the year, discussions about OAuth do tend to cool, as the agreement becomes more rational in its commercial value; And the implementation of OAuth 2.0 in China has also been mature, “third-party login” has been scaled. A security review at this time may serve as a reference for the security implementation of similar protocols in the future. Before this, Captain Pysolve “OAuth Security (OAuth Security)” (November 2012) and PNIG0s “OAuth Security” (December 2012), both conducted a history and vulnerability review of OAuth; Eran Hammer’s famous July 2012 article OAuth 2.0: The Road to Hell, as a protocol maker, explains in principle why OAuth 2.0 is “prone to unsafe implementation results in the hands of most developers.” This paper mainly reviews the implementation process of OAuth 2.0 from the perspective of the classification of attacked resources, combined with disclosure cases such as Wooyun, and reflects the historical attention of domestic open platforms as a whole. In order to simplify the responsibility description, this paper mainly includes the following roles: platform, application and user. This article may contain errors. Please correct them.
0x01 OAuth 2.0 security Focus
The OAuth 2.0 standard was finalized in October last year: RFC 6749 The OAuth 2.0 Authorization Framework. And RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage . OAuth 2.0 is more of a framework guide than a practical summary of OAuth 1.0. The main features of OAuth 2.0 are:
(1) Try to adapt to multiple scene authorization: increase the attack point under the complicated scene
From the business point of view, one of the biggest motivations for developing OAuth 2.0 protocol is to use a protocol to adapt to multiple business scenarios, that is, it needs to meet both traditional client authorization scenarios and authorization scenarios without server participation, and even mobile application authorization scenarios and so on.
The widening business scenarios as a result, the general also means increasing vulnerabilities, this is because in the case of scene complexity, easy developer divide thoughtless, and insufficient for application of the relevant safety instructions, party also easy mistake to use application occasions, and agreement to these scenarios also no further instructions. In addition, it may lead to the intersection of security problems between scenarios. Some potential threats are easily turned into explicit vulnerabilities through scene transformation. For attackers who specialize in point-to-point, it is now possible to successfully attack common vulnerabilities, especially in the authorization process.
The RFC of OAuth 2.0 defines several scenario authorization modes and allows the platform to extend them. This article discusses:
(A) Authorization Code Grant
After a user logs in to the platform authorization page, the parameter segment (for example, http://cakkback_url/? Code = aaAAa&state = SSSS) with code; In this case, the application needs to send a request to the specified interface of the platform (usually the Access Token interface) and exchange the Access Token with the code parameter.
This is almost the only business scenario defined in OAuth 1.0 and is primarily used for traditional clients and web site authorization with server participation.
Figure: RFC6749 Section 4.1 Authorization Code Grant flowchart
Figure: Authorization Code Grant Common implementation modes: Take website application as an example
(B) Implicit Grant
After the user logs in to the platform authorization page, the REdirect_URI segment (such as http://cakkback_url/#access_token=aaaaaa&uid=aaaaa) directly carries the Access token.
This scenario does not validate the application and is mainly used for browser-only javascript/HTML5 interactions where no application server is involved.
Figure: RFC6749 section 4.2 Implicit Grant flowchart
Figure: A common implementation pattern for Implicit Grant: A browser plug-in with no application server as an example
(C) The Resource Owner Password Credentials Grant XAuth is one of these.)
Application directly to the platform side of the specified interface (typically dedicated XAuth login interface; Or to obtain the Access Token interface) to obtain the Access Token directly with the user name and password.
Figure: Resource Owner Password Credentials Grant flowchart in section 4.3 of rfc6749
Figure: Common implementation modes of Resource Owner Password Credentials Grant The following uses traditional client applications as an example
(2) Simplification and no mandatory requirements: frustrated developers’ desire for security
In terms of specific technical implementation, OAuth 2.0 does not impose requirements on many aspects in order to enable the platform side to integrate existing resources with the minimum cost of business transformation. One of the core spirit of OAuth 2.0 is to simplify (or even remove) the application layer signature process and rely on transport layer encryption (TLS). In industry practice, this spirit has been translated into Unbounded and Bearer tokens: OAuth 2.0 neither exists Access Token Secret and other signature specific parameters, nor gives up the practice of generating a signature hash value based on request parameters. The entire API communication process is superficially similar to a browser visiting an HTTPS site, except that cookies are replaced with Access tokens. Although the standard recommends a signature flow proposal similar to Oauth-HTTP-MAC, it is not appreciated in practice.
This simplification and non-mandatory requirements raise the requirements of the platform and the application for secure coding. In the absence of protocol security guarantee (OAuth 1.0 relies on mandatory signature), both parties (especially the application) need to implement a security scheme that can cooperate with each other to ensure the whole process of OAuth 2.0 use. All are authorized by the user’s own will. But the problem is that there is a general lack of security awareness in development, and it is difficult to investigate the difference between “authentication” and “authorization”, not to mention the security asymmetry and mutual shirking between platform and application, which makes the good idea of relying on development to guarantee security frustrated.
The differences between the two protocols are given here with Sina Weibo API as an example:
[HTTP, Sina Weibo OAuth 1.0a]
GET /users/show/123456.json? Oauth_consumer_key = [APP KEY] &oauth_nonce= [OAuth random value] &oauth_signature= [query parameter + APP SECRET+Access Token Secret Value of the three signatures 】&oauth_signature_method= hMAC-sha1 & oauth_TIMESTAMP = [Request time] &oauth_token= [Access Token] &oauth_version= 1.0A HTTP / 1.1 Host: api.t.sina.com.cnCopy the codeHTTPS, Sina Weibo OAuth 2.0
Json? Uid =123456 HTTP/1.1 Authorization: OAuth2Copy the code0x02 Compromised the Account system of the Application
Most of the security implementation problems of OAuth 2.0 fall on the account system of the application party. This is because the application party’s level is uneven and uncontrollable, and its security consciousness is weaker, so the attacker will choose the weakest area to attack.
Improper parameter selection or no authentication mechanism when authorization is used for authentication
Vulnerability frequency: Common
Responsible Party: Application Party (main), platform Party (none or minor)
Wooyun case:
2012-08-24 WooYun: Sina oauth authentication login vulnerability
OAuth 2.0 unbound Token issue
2013-01-19 WooYun: Jinshan Express Disk mobile client arbitrarily access other people’s account
Causes of vulnerabilities and recommended repair schemes:
No matter OAuth 1.0 or OAuth 2.0, the most common application scenario is third-party login (account Access). The key step is that when the application obtains the authorization information (Access token, UID, expire_time, etc.) through the Access token of the platform, How to match it as a parameter to your application’s account and then automatically log in (or automatically register). One of the common attacks against this process is to modify authorization information, and if the subsequent matching processing logic is flawed (such as poor parameter selection or no authentication mechanism), it can lead to serious vulnerabilities for any login to any application account.
Figure: Weak spot for attacking Access Token data
In the era when OAuth 1.0 was still the dominant Authorization Code Grant, since it was mainly used for server website applications, this problem was at best a potential problem. After all, if you want to change Authorization information, you can only operate the server or arp on the website where the server is located. There have been open platforms that have implemented Implicit Grant scenarios in advance. Then there have been websites that have made the mistake of using this model, getting uid/access tokens in javascript and submitting them to websites for direct login. As a result, these authorized information can be easily cut and modified by attackers, causing security problems – tao url vulnerability, is so come.
However, OAuth 2.0 tends to return access token in the authorization of mobile phone, tablet and other applications. The application then reports the Access token to the server for authentication and login using its own account. This change in scenario makes tampering much easier (the easy way to verify this is to intercept tampering with fiddler2), but many mobile developers, and even the server API developers behind the phone, don’t realize it, The result is that the authorization information is incorrectly selected as a parameter (such as simply selecting uid), or the access token is not authenticated from the source, resulting in such vulnerabilities.
Figure: After the introduction of OAuth 2.0, mobile developers often commit the cause of serious vulnerability of arbitrary login to the application account
The key to solving this vulnerability is mainly the application side, but the platform side must also be involved:
(1) The application should seriously consider whether the authorization information (especially access token and UID) returned by the platform will be tampered with by users during the whole automatic login/automatic registration process; If any of the authorization information can be tampered with, then the access Token authentication interface provided by the platform must be used again in the server to verify that the Access Token is issued by the specified source application, and the UID given by the access Token authentication interface must be used. You cannot use the original UID value that could be tampered with.
If the application has been affected by the vulnerability, it needs to check all the bound Access_tokens that have been deposited. If the platform UID in the Access_Token is inconsistent with the platform UID bound to the access_Token, the access_token that is not authorized by the client appKey, or the access_token that has expired, all exceptions must be revoked and the abnormal user must be authorized to log in again.
(2) The platform needs to develop access Token authentication interface, receive parameters such as Access Token, and return results should include the issued application source (generally appkey), UID, expiration time, etc. At the same time, the platform should issue security bulletins and guidelines for affected developers that describe vulnerability and scenarios in which this interface can be used.
Hijacking a third-party account for application CSRF
Vulnerability frequency: Common
Responsible Party: The application party (mainly), the platform party (mainly if there is no CSRF defense with the application party; Or not)
Wooyun case:
2012-11-10 WooYun: Youku is at risk of account hijacking
2013-01-07 WooYun: Damai has a risk of account hijacking
2013-03-01 WooYun: Oauth vulnerability can hijack Accounts
Causes of vulnerabilities and recommended repair schemes:
There was a big discussion about application CSRF hijacking in November 2012. The vulnerability scenarios discussed in that discussion are mainly applications that use Authorization Code Grant (mostly websites). The main reason for the vulnerability is that the Code parameter in redirect_URI is not bound to the current client state, and the attacker can send the pre-obtained Code parameter to the victim’s computer. The victim’s currently logged in application account is bound to the platform (such as Weibo) account specified by the attacker. At that time, I wrote an article called “A Small discussion on the State parameter of OAuth 2.0 — from a development perspective, also said that the Internet’s largest account hijacking vulnerability is about to explode”, and I will not repeat it here.
Figure: Authorization Code Grant attack on code parameters; And the flowchart relationship with rfc6749
To prevent this type of CSRF hijacking, adding the state parameter is an easy way for an application to use. According to section 10.12 of rfc6749, this value is both unpredictable and must be able to prove that the application (client) is associated with the current login authentication status of a third-party website (preferably with an expiration date). A simple way to do this is to evaluate a random string, store it in session, and check the state parameter and session values on the callback.
The platform should also support the application’s state parameter during callbacks (although it can also support the application’s own anti-CSRF parameter if the redirecT_URI parameter is allowed).
However, strictly speaking, only the state parameter is not enough. It also needs to combine the defense means mentioned in 3.3.
More obscene for application CSRF hijacking third-party accounts: application authorization action itself CSRF + platform login vulnerability… .
Vulnerability frequency: Common
Responsible Party: Application party (main), platform party (main? Secondary?
Wooyun case:
no
Other cases:
Webstersprodigy, May 9, 2012, Common OAuth Issue You Can use to take over accounts:
Webstersprodigy.net/2013/05/09/…
CSRF StackExchange + CSRF Facebook = Bypass the state parameter + bind the victim’s StackExchange account to the target Facebook account)
Causes of vulnerabilities and recommended repair schemes:
Does adding the state parameter mean there is no problem? For example, I admitted that only focusing on the state parameter in my article last year was indeed one-sided, and even violated the principle of “security as a whole”, artificially separated the overall analysis of the entire authorization process, and covered up other problems and even attack angles: The state parameter does effectively protect the current user’s only real action during authorization, but what about before authorization is initiated? After authorization? This case abroad gives a good answer (discussed on zone) :
(1) Facebook (platform side) has login vulnerability, which can be CSRF
If the platform can be XSS, or does not have XSS but its login process is vulnerable to CSRF (for example, the login form is not secured by referer), then the victim’s computer can be logged into the platform account specified by the attacker. What does this do? Don’t worry, look down.
Figure: WebstersProdigy CSRF PoC for Facebook login
(2) StackExchange CSRF initiates the binding request
Think back to the process of binding a platform account on the application side (Facebook) as a normal user in StackExchange: when the user goes to the StackExchange binding page and is prompted not to bind to Facebook, of course he clicks “Start binding.” Has it ever occurred to you that the action of “start binding” is actually not protected by CSRF? This is a problem that applications (myself included) have long ignored — when an application clicks to initiate binding authorization, it does not make an authorization request to the platform, it must make some logical decisions (including generating the state parameter) before it can jump to the platform’s authorization page…
Figure: WebstersProdigy shows the binding page of the application
Therefore, in combination with the facebook (platform side) CSRF logins mentioned above, the attacker can first log the victim’s computer into the specified Facebook account, and then bind the request to CSRF StackExchange (application side), which can achieve the purpose of hijacking the application account. The two causes are different from the attack scenarios defended by the state parameter, so they can be completely bypassed.
Figure: WebstersProdigy’s CSRF application bind requests POC
Figure: WebstersProdigy’s complete attack flowchart
@Wocunwantao’s comments at that time can better illustrate the nature of the issues related to CSRF hijacking app accounts, but unfortunately I woke up too late: “In fact, the root cause of this vulnerability is a violation of RFC6749 without any CSRF protection, not without the use of the state parameter. According to RFC6749t.cn/zlTZyo6state, it is recommended rather than MUST. But CSRF protection is MUST. It is not a violation of the standard, but without CSRF protection, it is a violation.”
Returning to this vulnerability, “security is a whole” again – only the joint efforts of the platform and the application can be completely fixed. But as you all know, with a loophole like this where there are multiple parties to blame, it’s almost impossible… .
Suggestions for platform side:
(1) Check all login pages and procedures to prevent login vulnerabilities.
For example, referer and one-time token validation are enforced on pages where logins exist (especially on pages with SSO logins) to prevent CSRF logins.
Or check all login-related processes to prevent bugs. Here are some examples:
2013-02-19 WooYun: No password login to any account
2013-03-18 WooYun: Fan Tong website login arbitrary account vulnerability
(2) Detect whether it can respond to the remote login of the account and take measures.
But if there’s a targeted attack, it doesn’t seem to help.
Recommendations for applications:
(1) CSRF protection should be carried out for initiating binding platform accounts (Sina Weibo, Qzone, Renren, etc.), unbinding, etc., etc. This is a point that the entire development community has been ignoring.
(2) Display the bound platform nickname, UID and other information on the binding page to prevent users from being unable to self-check the binding information.
(3) Notify users when binding or unbinding.
Exploit inherent logic flaws in account system
Vulnerability frequency: rare
Responsible Party: Application Party (main)
Wooyun case:
Duplicate nickname accounts can be created with third-party connections
Causes of vulnerabilities and recommended repair schemes:
In fact, this kind of vulnerability has nothing to do with the OAuth protocol (or any one account exchange login protocol), but is purely a problem in the account system logic designed by the application side. Put it in here is mainly hope remind application developers, carefully review the account system design and implementation approach, when using flat island’s account each other to pay more attention to the other account system differences (in implementations, is mainly reflected in the application account binding and registration code logic), to avoid duplicate account problem.
0x03 Attacking Platform Account and Resource System
After OAuth 1.0, platforms have become more aware of security issues, such as mandatory callback addresses (mostly in the validation domain) to reduce the scope of redirect_URI jumps. Enforce the access token expiration period (or even provide little refresh token and the like) to limit the application’s resource usage and abuse for a long time. However, due to the diversification of business scenarios, attackers wander between scenarios to tear the surface. Platforms, on the other hand, are constrained by the cost of defense (both from themselves and from the application).
Response_type =token
Vulnerability frequency: Common
Responsible Party: Application Party (major or minor), platform Party (major or minor)
Wooyun case:
2012-04-15 WooYun: Oauth 2.0 authorization on Renren can cause user access_token disclosure
2012-08-27 WooYun: Call API to publish microblog through sina Weibo official source. Without client_sec
Wooyun-2012-11314: No need for client_sec to log on to QQ
Oauth authorization interface can hijack access_token
WooYun: Baidu open platform oauth authorization interface can hijack access_token
Other cases:
Egor Homakov, How we hacked Facebook with OAuth2 and Chrome bugs, 2013-2-19: homakov.blogspot.com/2013/02/hac…
Get Facebook Access Tokens with OAuth 2.0 Implicit Grant + Chrome Bug
Causes of vulnerabilities and recommended repair schemes:
For a discussion of Implicit Grant scenarios, see the September 2012 Zone article “On OAuth 2.0 Authentication Flaws from Wooyun-2012-11314.” Here are some key points to discuss.
Implicit Grant scenarios require only client_id and redirect_URI as application identifiers during authorization authentication. When returned, access Tokens are directly returned in URI fragments. The proposal of this scenario is closely related to the client-side business requirements. Typical examples are browser plug-ins with pure javascript interaction and various website widgets without server participation. In this kind of service, it is difficult for clients to encrypt app secret (Access token secret), so these restrictions are simply simplified.
But Implicit Grant scenarios are also deeply troubling for the platform in terms of security:
(1) Because the signature of double secret is missing, API can hardly distinguish the source of application request by access token
(2) Most open platforms obtain client-side access token through Implicit Grant authentication. It can be used in server API communication (that is, the permission is the same as the server-side Access token obtained through Authorization Code Grant).
(3) Due to the implementation of applications such as website widgets, open platforms often give the green light to transfer pages or cross-domain files on their own open platforms. That is, redirect_URI allows two types of domain names: the application’s own domain name and the platform’s own designated forwarding domain name.
Client_id (appKey) and redirect_URI are basically public information.
The above confusion leads to one of the most common and intractable website security problems. That is, as long as one of the partner website (the most common), platform website or even browser has any XSS, it is very easy for an attacker to XSS obtain access token and use it to attack the victim’s platform account without knowing app Secret.
Another problem is described in “Improper parameter selection or no authentication mechanism when authorization is used for authentication”. Since THE API cannot distinguish the source of application request, as long as the access token of the victim in application A is known and replaced in some key request steps in application B, Then it is possible to successfully log into the victim application account of application B.
The third is application impersonation, the attacker can only use the above public parameters to impersonate other applications to call out the authorization page, access token obtained can be used to control the victim’s platform account. If it is a high privilege client_ID, the access token acquired is obviously more damaging.
To address this issue, section 10.16 of rfc6749 only vaguely states that additional security measures are required, reflecting the difficulty of defending such scenarios. As a matter of practice, one approach is necessary: platforms must enforce categorization of applications — that is, applications must select which category they belong to when applying for Client_id (appKey); The platform then opens the corresponding permissions according to the classification, and takes specific defense and monitoring measures. The following analysis is conducted by logging in to the SDK using mobile SSO.
An alternative mobile version of Implicit Grant scenarios: Mobile SSO login SDK
Vulnerability frequency: Common
Responsible Party: Platform Party (main)
Wooyun case:
2013-03-27 WooYun: Open platform SSO scheme design flaws lead to phishing risk
Other cases:
@Jionghu Zhang Jianwei, Sina Weibo Android Client SSO Authorization Defects, 2013-09-08: www.blogjava.net/zh-weir/arc…
Causes of vulnerabilities and recommended repair schemes:
Photo: Sina Weibo open platform development documentSSO authorization for mobile applications
Sso login SDK for mobile application generally means that after the application uses the SDK, when the user clicks authorization, if the official mobile application of the platform has been installed, the user will jump there and the official application will authorize the user without re-entering the user name and password.
If OAuth is involved, there are echoes of Implicit Grant in their implementations. In the early days, when an application initializes the SSO SDK, it only needs client_ID (i.e. application AppKey) and redirect_URI to initiate authorization requests. And these two parameters are basically public; Even with client_secret, it’s a snap to get hold of after decompiling/reverse-engineering (more on that later). Therefore, the attack can carry out application impersonation and obtain access token to control the user’s account on the platform side.
The platform’s initial focus is to protect against authorization page forgery and replay attacks (and it does), so the authorization page URL that pops up in the official mobile app is signed with a parameter, but this does not protect against malicious use of client_id. Later, people realized that it was better to solve this problem by verifying the package name and signature of mobile applications. However, it should be noted that fallback can be bypassed if the fallback mechanism is not correct (for example, the authorization process is not good after the official client is not installed) or if the signature comparison mechanism itself is flawed……
Controversial Xauth scenarios (Resource Owner Password Credentials Grant; Grant_type = password)
Vulnerability frequency: not common
Responsible Party: Platform Party (main)
Wooyun case:
2012-11-05 WooYun: Kaixin001 Android client brute force crack vulnerability, test 2000 accounts, successful 132
Other cases:
The 2013-03-15, 315 party in CCTV 2013 “charges” gold map low version “collect sina weibo user name and password” (after gold, issued a statement denying) : jingji. CNTV. Cn / 2013/03/15 /…
Causes of vulnerabilities and recommended repair schemes:
This is a highly controversial scenario: at the negotiating table, it’s a power struggle between the application company and the platform company; In the development world, this is a great way to improve user experience and conversion rates; In the security world, there are backdoors that steal privacy and harm users. The thing that is causing a lot of controversy in the development and security communities is called XAuth, the Resource Owner Password Credentials Grant, or simply obtaining access tokens with the platform user name and Password.
There are two common target services for XAuth :(1) service invocation from internal or its own official application; (2) Advanced cooperation and deep integration of application parties. It can be said that XAuth represents advanced authorization, which is the greatest trust and cooperation between the platform and the application.
However, XAuth submits the user name and password to the interface on behalf of the application, bypassing the platform’s own authentication page. Therefore, in terms of security, it is difficult to ensure that the user name and password will not be leaked without ensuring the application’s ability reputation and security status. For example, if a website application is allowed to use XAuth, it will be designed to pop up the proxy login interface directly on the website of the application party according to the process of deep integration. After entering the platform account and password, the user logs in to the platform and application account through the application server. However, this design process can easily leak sensitive information such as account passwords during transmission to the application website or even on the application server. Mobile applications can also be analogous (see Autonavi low version of weibo recording process).
Figure: Common XAuth threats
On the other hand, due to XAuth’s advanced authentication, the restrictions are often placed more broadly, which can cause the protection process for regular logins to fail at the XAuth interface, allowing an attacker to perform a crash sweep attack.
However, it is not practical to eliminate XAuth completely, so a practical solution must be proposed based on the business:
(1) For external partners, the authorization of XAuth shall be cancelled and not opened to the maximum extent. For cases that cannot be cancelled due to contractual reasons, monitoring needs to be strengthened. I have to say that the 2013 CCTV 315 gala helped all the major platforms, giving them more confidence to say no to XAuth when negotiating.
(2) Internal applications should also be classified, and XAuth and internal interfaces are prohibited for unnecessary applications. For official applications, it is also not recommended to use XAuth directly, instead, it is better to use the proxy interface, because of the following issue: application identity leaks such as high-privilege client_id.
Unblocked high privileges client_id (appkey) and client_secret (app secret) leaks
Vulnerability frequency: Common
Responsible Party: Platform Party (major), application Party (minor or major)
Wooyun case:
2011-06-01 WooYun: The Oauth key leak problem of Kingsoft drug Boss micro service
2011-12-02 WooYun: Sina Weibo may cause user information leakage BUG
Other cases:
In 2013-03-08, John Leyden, Leaked: The ‘secret request app keys’ to Twitter’ s VIP lounge: www.theregister.co.uk/2013/03/08/…
2013-4-10, Nicolas Seriot (HitBSecConf2013-Amsterdam), Busing Twitters API and OAuth Implementation: Conference.hitb.org/hitbsecconf…
[client_id and client_secret] [client_id and client_secret] [client_id and client_secret] [client_id and client_secret] Finally, it is fundamentally wrong to apply OAuth to traditional clients.
Causes of vulnerabilities and recommended repair schemes:
Client_id and client_secret can be leaked for a number of reasons, such as:
(1) Official or senior partner client decompilation/reverse. This is one of the focal points of many discussions about whether OAuth can be used on clients, whether traditional desktop clients or mobile clients.
(2) Application source code leak client_id and client_secret.
Because Implicit Grant scenarios require only client_id and redirect_URI to cause damage, the reason why only the high-privilege client_ID is leaked also needs to be taken into account:
(1) Wrong design of proxy interface. Some OAuth proxy interfaces designed to pass client_id are intercepted.
(2) Advanced application parties (advanced partners) use open platform pendants, etc.
Disclosure usually leads to resource abuse, including:
(1) Application impersonation: for example, replace client_id and client_secret, install android mobile application as iPhone client, the official can not block, because this client_id represents the official application, sealing will be cut off business; Another example is that in Implicit Grant scenarios, only client_id can be used to impersonate another application and control the victim’s platform account, as described earlier.
(2) Non-cooperative data mining: such as crawling data, automatic batch private message harassment, etc.
(3) Abnormal high-level interface calls.
To mitigate client_ID disclosure and resulting resource abuse, the following solutions can be considered:
(1) The application party correctly designs a set of proxy interfaces to wrap OAuth without disclosing client_id and client_secret.
For example, the mobile client of Sina Weibo does not go through the OAuth process in the later version, but accesses the proxy interface instead. Client_id and client_secret will not be passed during the use of the proxy interface. After modification, client_ID and client_secret leakage problems are solved, and the judgment of mobile phone models can be better adjusted.
(2) Platform side blocks batch call of different client_id from protocol.
The example is Tencent Open platform. Since user relationship is the core of QQ, Tencent has made some changes to the OAuth standard for anti-relationship data mining, and the user OpenID obtained by each client_id is different. In this way, It can prevent attackers from batch calling different clientids for data mining and user harassment.
Figure: Problems related to OpenAPI invocation of Tencent open platform database
However, it should be noted here that academic research, commercial data mining, and spammers are not going to take advantage of OAuth. After all, there are so many ways to abuse resources, such as crowdsourcing page crawling and client insertion. Therefore, it may not be important for the platform to discuss whether OAuth can lead to resource abuse, but rather whether OAuth can prevent other aspects of resource abuse by using OAuth — after all, OAuth establishes an attitude and framework for business cooperation with the outside world, so that the platform can prevent unauthorized resource abuse outside this framework. Seems to have nothing to do with security. .
(3) The platform side shall improve interface authority control and behavior monitoring, and handle and alarm abnormalities found.
Comprehensive protocol implementation is not considered
Vulnerability frequency: not common
Responsible Party: Platform Party (main)
Wooyun case:
2012-10-30 WooYun: Interception of OpenID and OpenKey on Tencent weibo
2013-04-11 WooYun: Potential risks of OAuth2.0 obtaining Authorization Code on Sohu Weibo
Causes of vulnerabilities and recommended repair schemes:
This part is mainly due to the lack of consideration of the scenario led to the incomplete implementation of OAuth 2.0 protocol. Since I haven’t done platform development, I can’t give more specific analysis and suggestions beyond suggesting scenarios to consider.
Other miscellaneous
The following content is not unique to the OAuth protocol (or even unrelated to OAuth), it just reflects the common problems in implementing API protocols, so it is classified as miscellaneous.
API interface and main business flow mismatch
Vulnerability frequency: Common
Responsible Party: Platform Party (main)
Wooyun case:
(Disconnected from the main business flow)
2012-11-24 WooYun: Tencent has circumvented its restrictions on weibo
(Mixed with faulty integration of main business flow)
A malicious exploit of sina Weibo’s open platform interface could lead to the spread of viruses
CSRF bug in Sina Weibo
WooYun: A security breach on Sina Weibo has made it easy to steal accounts
WooYun: Douban API 2.0 CSRF
Causes of vulnerabilities and recommended repair schemes:
The problem of business flow imbalance is not unique to OAuth protocol. All software development with multiple business flows (especially different entrances can complete the same task) is prone to this kind of bug (further is vulnerability), which reflects the problem of business division without a formula. The above example illustrates the problem of having too many choices between the API interface and the main business flow (typically used on the platform’s main site) :
On the one hand, apis want to be logically independent to facilitate platform-wide extension. But if the API lags behind the main business flow, then there is a disconnect. For example, due to the lag of development plan, real-name microblogging is restricted on the main site temporarily, but API has not implemented this strategy, then the attacker can directly use API to bypass this restriction.
On the other hand, the main business flows also want to integrate themselves into API interfaces to ensure policy consistency across the platform. However, if you mix them incorrectly in the spirit of “do not duplicate the wheel,” interference will occur. For example, the host site can use login cookies as access tokens to call the API directly, which makes it easy to implement various CSRF attacks.
The key to solving the imbalance of business flow still lies in the division of business scope and the division of service granularity (and API granularity), which requires the joint discussion and implementation of several (or even dozens) business flow-related project teams within the platform. This topic is very large and demands a lot of architects.
Attacking API interfaces or supporting systems (traditional Web security issues)
Vulnerability frequency: Common
Responsible Party: Platform (main), application (main)
Wooyun case:
(Platform API interface problems)
2012-10-08 WooYun: XSS exists in netease Oauth authentication mechanism
(Platform API interface + platform SDK or application output filtering problem)
WooYun: “Log in with QQ” API XSS
(Problems with platform API supporting system)
2010-11-08 WooYun: A channel XXS bug
2012-07-08 WooYun: Tencent open platform storage XSS vulnerability
WooYun: An open platform storage XSS scripting vulnerability successfully hijacked the backend
Causes of vulnerabilities and recommended repair schemes:
Because OAuth is an HTTP service in nature, both the API interface itself and the supporting system will also have security threats such as XSS (often appear in various JSSDK and website add-ins), CSRF, SQL injection, and even ddos and so on. Its root causes and solutions (mitigation) are basically the same with traditional Web security in some topics, but there are also some differences, see Yunshu’s research on CC attacks and PPT.
It is important to note that applications and platform developers working on the official SDKS may not be filtering data from the API, which still needs to be filtered with an “input untrusted” method.
Can’t let go of browser controls (such as WebView)
Vulnerability frequency: Common
Responsible Party: Platform Party (mainly? Secondary? , application (main? Secondary?
Wooyun case:
2013-03-18 WooYun: Wechat accounts illegally record passwords of other websites
(note: this case is only the webview comes, the features of the automatic recording claudxiao has carried on the analysis and explanation: blog.claudxiao.net/2013/03/and…
Other cases:
Taobao open platform, wireless open platform development requirements “wireless application authorization must go browser mode rather than a webview model”, the 2013-9-12 visit and validation: open.taobao.com/doc/detail….
Causes of vulnerabilities and recommended repair schemes:
In mobile development, browser controls are commonly used to embed web pages within applications to enable html5 hybrid interaction between applications and websites and improve user experience. Android and ios generally refer to WebView components based on webKit engine, while Windows Phone has WebBrowser controls based on IE (the following content is not verified for WP).
Some users cannot trust the application to open the OAuth authentication login page using browser controls. The main reasons are as follows:
(1) Unable to see the open URL, easy to be phished.
(2) Browser controls can be injected into the application malicious JS code, resulting in account leakage.
Of course, it’s not out of the question that the recently popular WebView interface coding could lead to arbitrary code execution, but based on historical discussions of the issue, that’s not a major cause for concern.
In order to make users trust the application authorization page in the browser control, the current main practice mode is that the platform develops the official mobile application SDK with more convenient interaction (such as mobile SSO SDK, etc.) and requires to use the official SDK or comply with relevant development requirements when submitting the application for review. At present, taobao open platform is the most strict in China, and the development requirements of wireless open platform clearly require that “wireless application authorization must be in browser mode rather than Webview mode” (for specific implementation, please refer to the documents in the download packages of two kinds of wireless SDK). Of course, in the early stage of this measure, As a result, Taobao has great pressure and encountered fragmentation problems (see 1, 2, 3 for discussion).
In addition to the SDK and development requirements, there is an issue on the platform side of how the authorization page itself prevents browser controls and browser auto-recording (on both mobile and PC). This is where autocomplete=off comes in handy.
Annoyance from HTTPS
Vulnerability frequency: Common
Responsible Party: Platform Party (mainly? Secondary?
Wooyun case:
There is no
Other cases:
“According to Eve and Mallory Love Android: SSL (In) An Analysis of Android Security” Jane turn In Chinese (with the original) : zone.wooyun.org/content/139…
Causes of vulnerabilities and recommended repair schemes:
The term HTTPS is used here because it is better known than TLS. OAuth 2.0 relies on transport layer encryption for security, so HTTPS security issues will also affect OAuth 2.0 (or other protocols) security, but it is a vexing problem to analyze.
On the one hand, HTTPS is prone to timeouts when the network is unstable. In 2012 [email protected] offered a bitter lesson: “Be careful with HTTPS on mobile. In China’s vast cities other than Beijing, Shanghai, Guangzhou and Shenzhen, 20 to 25 percent of users encounter HTTPS connection difficulties. The screening found that the problem was unrelated to the access point, and that the signal and network were unstable, making HTTPS requests difficult to complete.” .
On the other hand, even if HTTPS is used, the code in most applications does not check for certificates, leading to a basic game over in the event of ARP and man-in-the-middle attacks.
So there’s a lot of balancing between platforms and applications (for example, making important interfaces and processes HTTPS, while others go back to HTTP + request parameter signatures in the form of OAuth 1.0), although theoretically any OAuth 2.0 process should be HTTPS free, Are suspected of violating the security conditions of the agreement.
For some important interface application development, it is recommended to enable the certificate checking code (preferably certificate locking) when using HTTPS. However, the problem is that it is not easy to debug.
Appendix: Those Security Cases in OAuth 1.0’s
The following errors do not mean that OAuth 2.0 does not exist, but that lessons have been learned and are becoming rare.
(1) CSRF of platform authorization page
2012-02-15 WooYun: CSRF causes automatic authorization of Weibo applications
2012-07-20 WooYun: Third-party APP forced Sina user OAUTH authorization vulnerability
WooYun: Netease open platform third-party application Oauth forcible user authorization vulnerability
(2) OAuth 1.0 session fixation
Attack source: The callback URL parameter oauth_callback can be controlled by the attacker, resulting in arbitrary jumps.
Attack process:
(A) The attacker obtains the authorization page URL with REQUEST TOKEN parameter from the application party in advance, but does not jump, but records the original OAUTH_callback parameter and replaces it with the attacker’s URL.
(B) After the victim accesses the maliciously constructed authentication page URL, he/she uses his/her platform account for authorization. After that, the platform instructs the victim’s browser to redirect to the attacker’s URL according to oauth_callback, together with REQUEST TOKEN and other parameters.
(C) The attacker accesses the original oauth_callback parameter first, and successfully logs in to the victim’s application account. During the whole process, APP SECRET and REQUEST TOKEN SECRET are not required and CSRF defense of the application side can be bypassed.
Defense methods:
Subsequent specifications OAUTH1.0A and RFC 5849 clearly specify that oAUTH_callback parameter should be added to the signature that generates REQUEST TOKEN. And the platform side returns the callback URL with an unpredictable oauth_verifier parameter. Details please refer to the related: sakinijino.com/archives/12…
Comparison with OAuth 2.0:
Because OAuth 2.0 does not have a signature, the open platform application management interface on the platform side has “bind domain name” or “callback URL” Settings. If these Settings do not match, an error will be reported on the authorization page (for example, invalid_redirect_URI). The oauth_verifier parameter is replaced by the code parameter.
Case study:
Http://blog.sina.com.cn/blog/oauth (http://blog.sina.com.cn/blog/oauth
2011-02-18 WooYun: Sina Weibo app URL jump
2011-04-29 WooYun: Third-party login hijacking vulnerability
2013-07-01 WooYun: Accounts can be hijacked due to third-party authentication defects
2013-07-23 WooYun: The group 800oauth defect may lead to account hijacking
(3) OAuth version 1.0 does not consider comprehensive protocol implementation
Email OAuth 1.0 standard protocol design defects
WooYun: Impersonation authorization vulnerability of third-party application Oauth on Tianya open Platform
0x05 Appendix: List of acknowledgements and partial references
This article is based on a variety of literature and vulnerability cases, thanks to all authors and white hat.
Some oauth-related articles are not included in this article, please click here to see the list if necessary.
The author has made a PDF for you to download and save: 20130914_PDF_pub_oauth-2.0_security_case_review.pdf