Sina's security department has been committed to promoting product security on the open platform, so that microblog applications have better user experience and more secure functions. From the current situation, we find that some applications have the following common security vulnerabilities or defects. These security vulnerabilities will not only affect the application itself, but also cause losses to users.

App secret leaked

app_ Secret is the application request open platform to generate access_ Unique authentication of token, using app_ The purpose of secret is to ensure that the application is used by the developer himself.

Different applications have different interface call resources and API permissions on the open platform. If the application's interface resources are embezzled and malicious operations such as publishing spam information and paying attention are carried out, the open platform will restrict the application's resources and permissions, which will directly affect the normal API calls of the application. Therefore, it is necessary for developers to protect their own application security, and the corresponding security resources will not be used illegally, so as to ensure the normal operation of applications.

It is recommended to save the app secret on the application server. In order to better protect your application security, it is recommended to bind the application server IP in the management center/security settings.

If the app secret of an application is found to be leaked, please go to the application management center to reset it immediately http://open.weibo.com/apps/

Common reasons for app secret disclosure:

1. The app secret appears in the source code or url of the page, which can be obtained by viewing the source code directly.

2、app_ Secret is stored in the client's own program. All native applications (such as iOS, Android or Windows desktop applications) can be obtained by decompiling code.

3. Without using the HTTPS secure transport protocol, the attacker obtained it through network sniffing.

access_ Token leakage

access_ Token is the session ID of the user accessing the open platform through the application. The application should be protected from being stolen by a third party.

Common access_ Token leakage path:

1、access_ Tokens are stored in cookies or page code, and attackers steal user tokens through xss vulnerabilities.

2. The application server has an SQL injection vulnerability, which leads to the disclosure of user tokens.

Binding microblog user CSRF vulnerability

If your application has its own account system and has the function of binding Weibo users to log in, please check whether the binding interface has the function of preventing CSRF attacks. The state parameter of the authorization interface can be used to prevent CSRF attacks in the authorization process. For detailed usage, refer to the latest SDK code, https://github.com/ElmerZhang/WeiboSDK 。

Pay more attention to the CSRF vulnerability of microblogging

For more information about CSRF vulnerabilities, please refer to here. http://baike.baidu.com/view/1609487.htm

The CSRF vulnerability of microblog application is common at the writing interface such as adding attention and posting microblog. What users see is that microblog has more inexplicable attention, or forwarded some marketing microblogs.

Developers can check whether the referer is legal or add csrf to the form_ Token to defend against CSRF attacks.

User identity forgery

After completing the OAuth 2.0 authorization authentication, the application can obtain access representing the user's identity_ Token is generally used directly for interface calls. However, some applications need to obtain the user's uid as the authentication credential associated with their own account system to provide more services for their own applications. Typical cases include mobile applications that use microblog sso sdk and network storage service applications.

In this scenario, common vulnerabilities include:

1. The client directly uses the uid returned by the authorization interface or extracts access_ The uid in the token is returned to the application server as the authentication credential. The transmission process can be illegally intercepted, and the user identity can be forged by tampering with the uid.

2. The client will access_ The token returns to its own server. The server extracts the uid as the authentication credential, but does not verify the access_ The legitimacy of the token. At this time, access is obtained by cheating user A to authorize X application_ After the token is transferred to the Y application server, you can get the A user certificate of the Y application and access the service content of the user in the Y application.

Repair suggestions:

1. Do not use the uid without authorization information directly to exchange the authentication credentials of your own service. You can only use access_ Token.

2. Server side fetching access_ The uid in the token needs to call the OAuth2/get_ token_ info Interface. When using this interface, you need to verify the access_ Whether the appkey to which the token belongs applies the appkey to its own client. Only when the source of the Appkey matches can the authentication credentials of its own service be exchanged.

3. Access to all saved bindings_ Token checks and finds access_ The Sina uid in the token is inconsistent with the bound Sina uid, and the access authorized by the appkey is not applied to the client_ Token, expired access_ All exceptions such as token need to be revoked, and these abnormal users are required to re authorize login.

Click hijack vulnerability

Malicious sites nest microblog application sites in the form of iframe, and hijack users' click operations by using technologies such as HTML transparent overlay. So as to achieve the purpose of inducing users to execute malicious and pay attention.

Repair suggestions:

1. For applications that do not need to be used by iframe, one of the following methods can be used.

• • a. Header header declaration header ("X-FRAME-OPTIONS: DENY");
  • b. JS judges whether the current page is iframed. Example code: if (top. location!=location) {top. location=locaton;}

2. Products that need to be iframed.

• • a. Determine whether the parent window is an allowed page;
  • b. Pop up and add attention confirmation, and give the nickname of the follower.

Application security covers a wide range. In addition to avoiding the above common security problems, developers should also pay attention to the latest security trends, understand the security defects of their products, and more importantly, improve the security awareness of products and developers. Only in this way can security problems be minimized. If there is a security vulnerability, you can contact us in time, and we will provide solutions as soon as possible.

Welcome to keep in touch with us @Sina Security Or enter Weibo open platform question and answer system 。