Application security development considerations
Sina’s security department has been committed to promoting product security on open platforms so that Weibo applications have a better user experience and more secure functions. Judging from the current situation, we have found that some applications have the following common security vulnerabilities or defects. In addition to affecting the application itself, these security vulnerabilities will also cause losses to users.
app secret leak
app_secret is the only authentication for applications to request the open platform to generate access_token. The purpose of using app_secret is to ensure that the application is being used by the developer himself.
Different applications have different interface calling resources and API permissions on the open platform. If the application's interface resources are misappropriated and malicious operations such as posting spam information and adding attention are performed, the open platform will restrict the application's resources and permissions, which will directly affect the application's normal API calls. Therefore, it is necessary for developers to protect the security of their own applications and prevent corresponding security resources from being 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 the security of your application, it is recommended to bind the application's server IP in the management center/security settings.
#If you find that the app secret of your application has been leaked, please go to the application management center to reset it immediately.
http://open.weibo.com/apps/
Common reasons for app secret leaks:
1. The app secret appears in the page source code or URL, resulting in direct viewing Source code is available.
2. The app_secret is saved in the client program itself. All native applications (such as iOS, Android or Windows desktop applications) can be obtained by decompiled code.
3. The HTTPS secure transmission protocol is not used, and the attacker obtains it through network sniffing.
access_token leakage
access_token is the session ID used by users to access the open platform through applications. Applications must be protected to prevent them from being stolen by third parties.
Common access_token leakage methods:
1. The access_token is stored in cookies or page codes, and attackers steal user tokens through xss vulnerabilities.
2. The application server has a sql injection vulnerability, causing the user token to be leaked.
Bind Weibo user CSRF vulnerability
If your application has its own account system and is bound to Weibo When users log in to this function, please check whether the binding interface has the function to prevent CSRF attacks. The state parameter of the authorization interface can be used to prevent CSRF attacks during the authorization process. For detailed usage, please refer to the latest version of the SDK code, https://github.com/ElmerZhang/WeiboSDK.
Follow and post the CSRF vulnerability on Weibo
For more information on the CSRF vulnerability, please refer here. http://baike.baidu.com/view/1609487.htm
CSRF vulnerabilities in Weibo applications are commonly found in writing interfaces such as adding followers and posting on Weibo. The phenomenon seen by users is Weibo has gained some inexplicable attention, or some marketing Weibo has been forwarded.
Developers can defend against CSRF attacks by checking whether the referer is legal or adding csrf_token to the form.
User identity forgery
After completing OAuth 2.0 authorization authentication, the application can obtain the access_token that symbolizes the user's identity, which is generally used directly for interface calls. However, some applications need to obtain the user's uid as an authentication credential associated with their own account system to provide more of the application's own service content. Typical situations include mobile applications and network storage service applications that use Weibo SSO SDK.
In this scenario, common vulnerabilities are:
1. The client directly uses the uid returned by the authorization interface or extracts the uid in the access_token, and returns the application's own server as authentication Credentials. This transmission process can be illegally intercepted and the user's 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 in it as the authentication credential, but does not verify the legality of the access_token. At this time, by defrauding user A to authorize the X application, obtaining the access_token and passing it to the Y application server, the A user's credentials for the Y application can be obtained and the user's service content in the Y application can be accessed.
Repair suggestions:
1. Do not directly use uid without authorization information in exchange for the authentication credentials of your own service. You can only use access_token.
2. To extract the uid in access_token on the server side, you need to call the OAuth2/get_token_info interface of the open platform. When using this interface, you need to also check whether the appkey to which the access_token belongs is your own client application appkey. Only those with consistent Appkey sources are allowed to exchange authentication credentials for their own services.
3. Check all stored bound access_tokens and find that the Sina uid in the access_token is inconsistent with the bound Sina uid, access_tokens authorized by non-own client application appkeys, expired access_tokens and other abnormal situations are required. All are revoked and these abnormal users are required to re-authorize their login.
Click Hijacking Vulnerability
Malicious sites embed Weibo application sites in iframes and use technologies such as HTML transparent overlays to hijack users' click operations. In order to achieve the purpose of inducing users to perform malicious actions and add attention.
Repair suggestions:
1. For applications that do not need to be iframed, you can choose one of the following methods.
- a. Header declaration header("X-FRAME-OPTIONS:DENY");
- b. JS determines whether the current page is iframed, sample code: if (top.location!=location){top.location=locaiton;}
2. Products that need to be iframed.
- a. Determine whether the parent window is an allowed page;
- b. Pop up the following confirmation and give the nickname of the person being followed.
Application security covers a wide range. In addition to paying attention to avoiding the common security issues above, developers should also pay attention to the latest security trends and understand their own products. It is more important to improve the security awareness of products and developers. Only in this way can security problems be reduced as much as possible. If a security vulnerability occurs, you can contact us in time and we will provide a solution as soon as possible.