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 only authentication that an application requests the open platform to generate access_token. The purpose of using app_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. The app_secret is saved 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 leak

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 leak paths:

1. Access_token is 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 defend against CSRF attacks by checking whether the referer is legal or adding the csrf_token method to the form.

User identity forgery

After completing the OAuth 2.0 authorization authentication, the application can obtain the access_token representing the user's identity, which is generally directly used 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 from the authorization interface or extracts the uid from access_token, and returns 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 sends the access_token back to its own server, and the server extracts the uid as the authentication credential, but does not verify the legitimacy of the access_token. At this point, you can obtain user A's credentials from application Y and access the user's service content in application Y by tricking user A to authorize application X, obtaining access_token and then transferring it to application Y server.

Repair suggestions:

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

2. The server side extracts the uid in access_token, and needs to call the OAuth2/get_token_info Interface. When using this interface, you need to verify whether the appkey to which the access_token belongs applies the appkey for your client. Only when the source of the Appkey matches can the authentication credentials of its own service be exchanged.

3. Check all the saved access_tokens. It is found that the Sina uid in access_token is inconsistent with the bound Sina uid, the access_token and expired access_token authorized by the app key of non own client applications need to be revoked. 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 。