API Interface General security policy and implementation-oss.core

This article has been said to write, slow hands, these two days to see some application interface data by others crawler, SMS interface was high frequency request attack, such as the case, feel a simple overview to share the interface security authentication or necessary. After all, the current basic client-based application, if the early negligence, post-release maintenance and upgrade will be a lot of trouble. Here I will mainly focus on the following aspects:

1. The underlying security policy

2. Introduction to RESTful security implementation

3. OSS. Core Implementation Case

4. OSS. Core Interface Parameter specification

I. The underlying security policy

It is discussed here only for the application itself, such as HTTPS or firewalls, etc. third-party support is not covered here.

For an interface project, the security policy I personally think that two main points: 1. Interface Validation Module 2. User Authentication Module

1. Interface Verification Module

This module is responsible for the entire interface security level. For the interface security, especially the client interface, is directly exposed to the entire Internet, we must first of all to ensure that we will not be someone else's false request for our interface data. Often used is the signature verification, in addition to the normal interface data transmission, the transfer of additional Convention encryption signature information, etc., to filter the non-authorized interface requests.

Here can give a typical case I met last year, there is a takeout site SMS send interface did not add any verification, interface address is also written on the page, imagine the consequences of how serious, the network of many SMS bombers with these interfaces, here to a time when the test was found:

650) this.width=650; "Src=" http://images2015.cnblogs.com/blog/154246/201706/154246-20170613233225525-113982281. PNG "width=" 218 "height=" 391 "style=" border:0px; "/>

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

2. User Authorization Verification Module

This module is mainly responsible for the user, the previous step is to some extent to filter some non-Self application interface requests. However, the application itself has problems, such as vulnerability or anti-compilation, or the secret key leakage caused by personnel flow, and how to ensure that the real user data of the interface is not easily tampered with.

For this problem, we can be independent of a user authentication module, the core idea is to give each login user token (can be encrypted by the user number, or number + time stamp), the user-related actions through token authentication, the user primary key information is not transmitted through the interface plaintext, Obtained through token decryption on the server. Token encryption and decryption process is done on the server side, and the signature verification module is independent.

These two modules can also be used to understand the relevant division of labor through a simple sequence diagram below:

650) this.width=650; "Src=" http://images2015.cnblogs.com/blog/154246/201706/154246-20170627235539258-1209611305. PNG "style=" border:0px; "/>

Two. Introduction to safe implementation under restful interfaces

The above describes a basic interface verification step, here I use the common HTTP interface protocol to briefly introduce the implementation process:

1. Signature Verification

This is mainly through the combination of parameters and random number of each request to generate a unique signature "sign" information, a variety of ways, here I introduce a common practice, if you are familiar with the third-party site signature verification can be skipped.

Because an interface project may provide data services to an application, we issue the corresponding AppID and appsecret information to each application.

The first step is to add the Appid,timespan (current timestamp) parameter in addition to the normal pass parameter, and use the format of the URL key-value pair (the dictionary order) in the parameter name ASCII code from small to large for the parameters in the current parameter collection (i.e., key1=value1& Key2=value2 ... ) stitching into a string str, at the same time need to pay attention to several points.

1. 
   

   1. Parameter name ASCII code from small to Large (dictionary ordering)

   2. The value of the parameter is null does not participate in the signature

   3. Parameter names are case-sensitive

In the second step, we will get STR using signature algorithm, generate sign (mainly see and the Server Convention encryption algorithm, generally use one-way signature algorithm can), the two common encryption algorithms

1. Using MD5

Append &appsecret=xxx after STR and then MD5 encryption, sign = MD5 (STR&APPSECRET=XXX)

2. Using SHA1

Because SHA1 natively supports salt-adding operations, it uses Appsecret to encrypt str directly, i.e. SIGN=SHA1 (str, appsecret)

Step three: Pass 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, such as signature information can also be placed in the request header, parameter format can be JSON, etc., it is important to ensure that each request signature will not be the same

2. User Authorization Verification implementation

This can be referred to the recent more popular JWT protocol implementation, the main idea is that after the user authorization, the service side issued token back to the client, when requesting the relevant authorization interface with token.

In this case, the encryption algorithm needs to use the bidirectional encryption algorithm, and then the service side intercepts and decrypts the relevant information when processing the request, saving in the context.

Three. OSS. Core Implementation Case

1. Signature Verification:

In the Oss.core project, I placed the signature-related authentication information in the request header (Httpheader) and intercepted it through the custom Authorizesignmiddleware middleware at the entrance of the program, which mainly contains the following parameters (Implementation code See GitHub ):

650) this.width=650; "Src=" http://images2015.cnblogs.com/blog/154246/201706/154246-20170629005934321-186618888. PNG "width=" 475 "height=" 390 "style=" border:0px; "/>

See Sysauthorizeinfo in Oss.common if you want to know more about processing sorting encryption, etc.

2. User Authentication module:

Mainly through the custom attribute registration implementation, the code is described in GitHub Authorizememberattribute, and I will keep the current user information in a asynclocal variable, For detailed code see Membershiper in Oss.common

Four. OSS. Core Interface Parameter specification

All of the interface information, I will define a set of global error code, all the interface return information will contain the RET identity, to return the current interface is normal or not, for example: If the ret=1423 to indicate illegal application source, ret=1425 need to obtain authorization token, Of course, each interface can also customize its own local error code.

Global error code see: Github under Resulttypes

At the same time, the interface request header Appsource,appversion,appclient parameters must be filled to ensure the subsequent activity, user registration, order distribution and other statistics.

API Interface General security policy and implementation-oss.core