“Sina (新浪) is a Chinese online media company for Chinese communities around the world. Sina operates four major business lines: Sina Weibo, Sina Mobile, Sina Online, and Sina.net. Sina has over 100 million registered users worldwide. Sina was recognized by Southern Weekend as the “China’s Media of the Year" in 2003.Sina owns Sina Weibo, a Twitter-like microblog social network, which has 56.5 percent of the Chinese microblogging market based on active users and 86.6 percent based on browsing time over Chinese competitors such as Tencent and Baidu. The social networking service has more than 500 million users and millions of posts per day, and is adding 20 million new users per month, says the company. The top 100 users now have over 180 million followers combined. Sina.com is the largest Chinese-language web portal. It is run by Sina Corporation, which was founded in 1999. The company was founded in China, and its global financial headquarters have been based in Shanghai since October 1, 2001." (Wikipedia)

Sina’s OAuth 2.0 system is susceptible to Attacks. More specifically, the authentication of parameter “&redirct_uri" in OAuth 2.0 system is insufficient. It can be misused to design Open Redirect Attacks to Sina.

At the same time, it can be used to collect sensitive information of both third-party app and users by using the following parameters (sensitive information is contained in HTTP header.),

“&response_type"=sensitive_info,token…

“&scope"=get_user_info%2Cadd_share…

It increases the likelihood of successful Open Redirect Attacks to third-party websites, too.

When a logged-in Sina user clicks the URL ([1]) above, he/she will be asked for consent as in whether to allow a third-party website to receive his/her information. If the user clicks OK, he/she will be then redirected to the URL assigned to the parameter “&redirect_uri".

If a user has not logged onto Sina and clicks the URL ([1]) above, the same situation will happen upon login.

After acceptance of third-party application:

A logged-in Sina user would no longer be asked for consent and could be redirected to a webpage controlled by the attacker when he/she clicks the URL ([1]).

For a user who has not logged in, the attack could still be completed after a pop-up page that prompts him/her to log in.

(2.1.1) Sina would normally allow all the URLs that belong to the domain of an authorized third-party website. However, these URLs could be prone to manipulation. For example, the “&redirect_uri" parameter in the URLs is supposed to be set by the third-party websites, but an attacker could change its value to make Attacks.

Hence, a user could be redirected from Sina to a vulnerable URL in that domain first and later be redirected from this vulnerable site to a malicious site unwillingly. This is as if the user is redirected from Sina directly. The number of Sina’s OAuth 2.0 client websites is so huge that such Attacks could be commonplace.

Before acceptance of the third-party application, Sina’s OAuth 2.0 system makes the redirects appear more trustworthy and could potentially increase the likelihood of successful Open Redirect Attacks of third-party website.

Once the user accepts the application, the attackers could completely bypass Sina’s authentication system and attack more easily.

(2.2) One of webpages was used for the following tests. The webpage is “http://tetraphlike.lofter.com/“. Can suppose it is malicious and contains code that collect sensitive information of both third-party app and users.

Covert Redirect is a class of security bugsdisclosed in May 2014. It is an application that takes a parameter and redirects a user to the parameter value without sufficient validation. This often makes use of Open Redirect and XSS (Cross-site Scripting) vulnerabilities in third-party applications.

Covert Redirect is also related to single sign-on, such as OAuth and OpenID. Hacker may use it to steal users’ sensitive information. Almost all OAuth 2.0 and OpenID providers worldwide are affected. Covert Redirect can work together with CSRF (Cross-site Request Forgery) as well.

“NetEase, Inc. (simplified Chinese: 网易; traditional Chinese: 網易; pinyin: Wǎng Yì) is a Chinese Internet company that operates 163.com, a popular web portal ranked 27 by Alexa as of April 2014. 163.com is one of the largest Chinese Internet content providers, and as such frequently appears in the top 10 domains used in spam." (Wikipedia)

163’s OAuth 2.0 system is susceptible to Attacks. More specifically, the authentication of parameter “&redirct_uri" in OAuth 2.0 system is insufficient. It can be misused to design Open Redirect Attacks to 163.

At the same time, it can be used to collect sensitive information of both third-party app and users by using the following parameters (sensitive information is contained in HTTP header.),

“&response_type"=sensitive_info,token…

“&scope"=get_user_info%2Cadd_share…

It increases the likelihood of successful Open Redirect Attacks to third-party websites, too.

When a logged-in 163 user clicks the URL ([1]) above, he/she will be asked for consent as in whether to allow a third-party website to receive his/her information. If the user clicks OK, he/she will be then redirected to the URL assigned to the parameter “&redirect_uri".

If a user has not logged onto 163 and clicks the URL ([1]) above, the same situation will happen upon login.

After acceptance of third-party application:

A logged-in 163 user would no longer be asked for consent and could be redirected to a webpage controlled by the attacker when he/she clicks the URL ([1]).

For a user who has not logged in, the attack could still be completed after a pop-up page that prompts him/her to log in.

(2.1.1) 163 would normally allow all the URLs that belong to the domain of an authorized third-party website. However, these URLs could be prone to manipulation. For example, the “&redirect_uri" parameter in the URLs is supposed to be set by the third-party websites, but an attacker could change its value to make Attacks.

Hence, a user could be redirected from 163 to a vulnerable URL in that domain first and later be redirected from this vulnerable site to a malicious site unwillingly. This is as if the user is redirected from 163 directly. The number of 163’s OAuth 2.0 client websites is so huge that such Attacks could be commonplace.

More seriously, some third-party websites may allow all URLs (even not belong to themselves) for “&redirect_uri" parameter.

Before acceptance of the third-party application, 163’s OAuth 2.0 system makes the redirects appear more trustworthy and could potentially increase the likelihood of successful Open Redirect Attacks of third-party website.

Once the user accepts the application, the attackers could completely bypass 163’s authentication system and attack more easily.

(2.2) Used one of webpages for the following tests. The webpage is “http://mathpost.tumblr.com/“. We can suppose it is malicious and contains code that collect sensitive information of both third-party app and users.

Covert Redirect is a class of security bugsdisclosed in May 2014. It is an application that takes a parameter and redirects a user to the parameter value without sufficient validation. This often makes use of Open Redirect and XSS (Cross-site Scripting) vulnerabilities in third-party applications.

Covert Redirect is also related to single sign-on, such as OAuth and OpenID. Hacker may use it to steal users’ sensitive information. Almost all OAuth 2.0 and OpenID providers worldwide are affected. Covert Redirect can work together with CSRF (Cross-site Request Forgery) as well.