Shulou(Shulou.com)06/01 Report--

This article has been written for a long time, but it has not been done for a long time. In the past two days, I have seen some cases such as application interface data being crawled by others and SMS interfaces being requested frequently. I feel that it is necessary to briefly summarize and share the security verification of the interface. After all, most of the current applications are based on client applications. If you are negligent in the early stage and the maintenance and upgrade after the release will be very troublesome. Here I will mainly focus on the following aspects:

1. Basic security policy

2. Introduction of Restful security implementation

3. OSS.Core implementation case

4. OSS.Core interface parameter specification

one。 Basic security policy

The discussion here is only for the application itself, and third-party support such as Https or firewall is not discussed here.

For an interface project, I personally think that the security policy is mainly divided into two parts: 1. Interface verification module 2. User authentication module

1. Interface verification module

This module is responsible for the entire interface security level. As far as interface security is concerned, especially the client interface, it is directly exposed to the entire Internet. The first thing we need to ensure is that we will not be asked for our interface data under the false name of others. Signature verification is often used to filter unauthorized interface requests by passing additional agreed encryption signature information in addition to the normal data transmission of the interface.

Here is a list of typical cases I encountered last year. At that time, there was a delivery site SMS sending interface without any verification, and the interface address was written on the page. You can imagine how serious the consequences are. Many SMS bombers on the network use these interfaces. Here is a screenshot of the test when found at that time:

Of course, signature verification is only the most basic security check, if coupled with IP current restrictions and other verification measures, the effect is better!

two。 User authorization verification module

This module is mainly responsible for individual users, and the previous step is mainly to filter some non-self application interface requests to a certain extent. However, there is something wrong with the application itself, such as vulnerabilities or decompilation, or the disclosure of the secret key caused by the flow of personnel, and how to ensure that the real user data of the interface will not be easily tampered with.

For this problem, we can have an independent user authentication module, the core idea is to issue token to each logged-in user (can be encrypted by user number, or number + timestamp), the related operations of the user are verified by token, and the user primary key information is not transmitted through the plaintext of the interface, but is obtained through token decryption on the server side. The encryption and decryption process of token is completed on the server side and is independent of the signature verification module.

These two modules can also learn about the relevant division of labor through the following simple sequence diagram:

two。 Introduction of Security implementation under Restful Interface

A basic interface verification step is described above. Here, I will briefly introduce the implementation process with common http interface protocols:

1. Signature verification

This is mainly to generate a unique signature [sign] information through the sorting combination of parameters and random numbers for each request, in a variety of ways. Here I introduce a general practice, which can be skipped if you are familiar with signature verification on third-party websites.

Here, because an interface project may provide data services to each application, we issue the corresponding appid and appsecret information to each application.

The first step is to add the appid,timespan (current timestamp) parameter to the normally passed parameters, sort the parameters in the current parameter set that are not empty according to the parameter name ASCII code (lexicographical order), and use the format of URL key-value pairs (i.e. key1=value1&key2=value2 … Concatenated into the string str, at the same time need to note a few points.

Parameter names ASCII codes are sorted from smallest to largest (lexicographical order)

Parameter is empty and does not participate in signing

Parameter names are case sensitive

In the second step, we will get that str uses the signature algorithm to generate sign (mainly look at the encryption algorithm agreed with the server, generally using an one-way signature algorithm). Here are two common encryption algorithms.

1. Use MD5

Append & appsecret=xxx after str and then encrypt it with md5, that is, sign = md5 (str&appsecret=xxx)

two。 Use SHA1

Because sha1 itself supports salt operation, use appsecret to encrypt str directly, that is, sign=sha1 (str, appsecret)

Step 3: deliver the content str&sign=xxxx to the server.

The above is a basic signature implementation process. Of course, the specific implementation can be adjusted according to the actual situation. For example, the signature information can also be placed in the request header, and the parameter format can also be json. It is important to ensure that the signature of each request will not be the same.

two。 Implementation of user Authorization Verification

You can refer to the recent popular jwt protocol and other implementations. The main idea is that after the user is authorized, the server issues token and returns it to the client, and the token is attached when requesting the relevant authorization interface.

Here, the encryption algorithm needs to use a two-way encryption algorithm, and then when processing the request, the server intercepts and decrypts the relevant information and saves it in the context.

three。 OSS.Core implementation case

1. Signature verification:

In the OSS.Core project, I put the signature-related verification information in the request header (httpheader) and intercept the program entry through custom AuthorizeSignMiddleware middleware, which mainly contains the following parameters (for more information on the implementation code, please see GitHub):

If you want to learn about detailed sorting, encryption, etc., you can see SysAuthorizeInfo in OSS.Common

two。 User authentication module:

This is mainly achieved through custom Attribute registration. For more information, please see AuthorizeMemberAttribute in GitHub. At the same time, I will save the current user information in an AsyncLocal variable. For more information, please see MemberShiper in OSS.Common.

four。 OSS.Core interface parameter specification

In all the interface information, I will define a set of global error codes, and all the API return messages will include the ret logo to return whether the current interface is normal or not. For example, if ret=1423 indicates an illegal application source, ret=1425 needs to obtain the authorization verification token. Of course, each API can also customize its own local error code.

For more information on global error codes, please see ResultTypes under Github.

At the same time, the AppSource,AppVersion,AppClient parameter in the API request header is required to ensure subsequent activity, user registration, order distribution and other statistics.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.