Introduction

This article is mainly based on some security issues encountered by JD Logistics' sorting business platform in the production environment, locating and adopting appropriate solutions for security governance, and leads to the exploration of security governance solutions for different business fields and different types of systems in the industry. , and finally the author also shared the API gateway governance solution based on his own experience in the financial field.

write in front

As the diversification, complexity, and servitization of Internet applications have become significant trends, application architectures in more and more scenarios use application programming interfaces (APIs) as inter-application data transmission and control processes. At the same time, the amount and sensitivity of data transmitted by the API interface is also increasing. Therefore, attacks against APIs are becoming more and more frequent and complex, becoming the number one security threat for many companies today.

According to a new report from API security service provider Salt Security, nearly 66% of enterprises lack a basic API security strategy. Over the past few years, the market has seen a huge increase in risks and attacks on APIs, not only from companies such as Facebook and T-Mobile, but also from the United States Postal Service (USPS) and Google+. Latest vulnerability leaks.

This is a wake-up call for us: safety is no small matter, and we need to be cautious in research and development!

1. Background

On February 14, 2022, I received feedback from front-line colleagues at a sorting center A: There were automatic inspections between the 9th and 13th of some unblocked trucks with unsubscribed goods. After questioning, the front-line staff at the sorting center said It has not been inspected.

2. Discover problems

2.1 Lock actual operation messages

Query the system log and locate the specific request message based on the waybill number JDV0055896869XX:

Figure 1 Inspection practical operation request log

2.2 Determine IP

Query the nginx log and locate the request IP:

Figure 2 nginx log

2.3 Confirm the venue

Based on the terminal detection function of the group's self-developed unified management platform for operation and maintenance assurance, the source of the site is located based on IP:

Figure 3 Terminal detection link

2.4 Locate the host

Check the routing information and locate the host device based on the binding relationship between IP and host:

Figure 4 Routing information

Figure 5 Host information

2.5 Draw conclusions

A certain B sorting center used the HB-TZFJ-33257A computer to use a script tool at around 17:55 on February 13, 2022, to disguise the HTTP request message and partially unblock the unblocked goods in a certain B sorting center. The inspection of goods to a sorting center A constitutes malicious sorting, causing the assessment data of sorting center B to be transferred to sorting center A.

Why is this so?

Due to historical development reasons, there are two versions of wince and android sorting pda. Due to the poor scalability of the wince version and high equipment cost, etc., the wince version is planned to be gradually offline. The wince version is not connected to the logistics gateway and calls the traditional rest service. This part does not verify and intercept the wince device access, so there is a vulnerability.

Finally, after comprehensive consideration of future promotion and development and rectification costs, the wince version is no longer connected to the logistics gateway, and only adds a layer of authentication and interception mechanism to the original architecture design, which not only ensures the safe transition of a small number of users, but also saves a certain amount of money. system modification costs.

3. Resolution process

Add authentication logic to the server-side RestAPI based on the sha256 digest algorithm to prevent illegal requests.

Specific details: The client needs to carry the following field information in the request header:

registerNo-device or identification code
signature serial number
siteCode is the calling device or the site to which the user belongs
timestamp timestamp
noceno random sequence
opCode operation code
authorization signature

registerNo and siteCode are the identity information of the caller, which need to be registered and obtained in the sorting management system in advance. The client sorts and encapsulates based on the fields and body information in the header, carries the salt value for sha256 summary calculation, and obtains the summary result as the authorization signature information. Sent to the server together with other fields. After receiving the request, the server performs sha256 digest calculation based on the same algorithm. If the signature information obtained is the same as that transmitted by the client, the verification is passed, otherwise it is an illegal request.

The reason why this authentication scheme is adopted is that the digest algorithm has high performance, meets the current security needs, and considering the convenience of upgrade implementation (currently there are many versions of the client: android and wince devices), this scheme was finally chosen. After the authentication function is launched online, requests without authentication logic are intercepted, system security issues are well resolved, and the source of illegal requests can be quickly located based on logs.

4. Industry plan analysis

There are many solutions for API authentication in the industry. The author has sorted out the following three application scenarios based on his own work experience:

4.1 BS architecture system (website type)

Most of these use cookie+session or token mechanisms to implement some security management functions such as login sessions.

4.1.1 cookie+session mechanism

Cookie + session is the most traditional API authentication method. For example, the login modules of many websites rely on this method to implement session management. A session will be generated on the server to save the session state. Each session is identified by a unique session_id. The session_id will be returned to the front-end when responding to the front-end request. The front-end will save it in a cookie. All subsequent requests will carry the cookie. On the server side, the server parses the cookie and finds the corresponding session to determine which client initiated it.

The advantages are:

It is more traditional, has more information for development, and has complete language support.
Easier to expand, external session storage solutions are already very mature (such as Redis).

weakness is:

The performance is relatively low: after each user is authenticated by the back-end application, the back-end application must make a record on the server to facilitate the identification of the user's next request. Generally speaking, the session is saved in the memory, and the session is stored in the memory. As the number of authenticated users increases, the server-side overhead will increase significantly.
Because user identification is based on cookies, if the cookie is intercepted, the user will be vulnerable to CSRF attacks; if the user disables browser cookies, this mechanism will no longer apply.
It is difficult to cross-platform: sessions and cookies are difficult to work on mobile applications. You cannot share the sessions and cookies created by the server with mobile terminals.

Generally speaking, if it is a traditional web website and the number of people authenticated at the same time is not large enough (for example, it is only for internal use), this method can be used. Many websites still use this method.

4.1.2 token mechanism

The token mechanism is used to replace the session authentication scheme. Now many APIs are authenticated through the token mechanism. The token mechanism is an encrypted string generated by the server and issued to the client. The client will bring this token when requesting all resources on the server, and the server will verify the validity of the token. It has the advantages of being stateless, suitable for distribution, good scalability, high performance and good security.

4.2 CS architecture system (client-server)

Most of these are based on digest algorithms and encryption algorithms.

4.2.1 Summary algorithm

The message digest algorithm is also called a hash algorithm or Hash algorithm. After any message is processed by a hash function, it will obtain a unique hash value. This process is called "message digest", and its hash value is called "digital fingerprint". If the digital fingerprints are consistent, it means that the message is consistent. of.

The mainstream digest algorithms include md5 and sha series. The sha series is also divided into sha1 and sha2 series (including sha-224, sha-256, sha-384 and sha-512). What is the difference between md5 and sha series? The core process of the algorithm is similar, but the number of output digest information is different. The MD5 digest length is 128 bits, and the SHA-1 digest length is 160 bits. What does the extra 32 bits mean? The probability of collision of different plaintexts is reduced by 2^32 = 324294967296 times, thereby improving security. The improvement in security comes at the expense of performance.

md5 divides the 128-bit information summary into four segments (Words) A, B, C, and D, each segment is 32 bits, and alternately operates A, B, C, and D during the loop process to finally form a 128-bit summary result.

Figure 6 md5 calculation process

The core process of the sha-1 algorithm is similar. The main difference is that the 160-bit information summary is divided into five segments: A, B, C, D, and E.

Figure 7 sha-1 calculation process

The core process of the sha-2 series of algorithms is more complex, dividing the information summary into eight segments A, B, C, D, E, F, G, and H.

Figure 8 sha-2 calculation process

The longer the message digest, the lower the chance of collision and the more difficult it is to crack. But at the same time, the performance and space occupied will be higher. There is no best choice, just make your choice based on the actual required performance and security. Due to its one-way irreversibility, the digest algorithm is often used in scenarios such as verifying file integrity (such as code version comparison) and storing system user passwords.

4.2.2 Encryption algorithm

Encryption algorithms are generally divided into two broad categories: "symmetric" encryption and "asymmetric" encryption.

Symmetric encryption means that the same key is used for encryption and decryption. Asymmetric encryption means that encryption and decryption use different keys. There are usually two keys, called "Public Key" and "Private Key". They must be paired together, otherwise Unable to open encrypted file.

The "public key" here means that it can be disclosed to the outside world, but the "private key" cannot, and can only be known by the holder. Its superiority lies here, because symmetric encryption uses a common set of keys for encryption and decryption, and the key needs to be told to the other party. Once the key is transmitted, it may be eavesdropped by others no matter what method is used. The asymmetric encryption method has two keys, and the "public key" can be made public. Even if it is leaked, it will only reveal part of the data permissions. The private key can only be kept by the holder himself, and the data permissions can still be controlled. This effectively avoids key transmission security issues.

4.3 Open platform (open API)

Scenarios with high security factors (payment, fund issuance, etc.) are mainly based on digital signatures.
Scenarios where the security factor is not very high (querying user information, etc.) are dominated by the accessToken mechanism. The specific process is that the application needs to obtain an accessToken based on the AppId and AppSecret assigned by the platform (cached locally and needs to be refreshed regularly), and subsequent request interfaces can bring the accessToken, so that interfaces that do not have such a high security factor do not need to add it every time. Decryption logic to improve performance.

4.3.1 Digital signature

Digital signature is a comprehensive application of digest algorithm and asymmetric encryption algorithm. The client (requester) and the server (receiver) each hold a pair of keys (there are two sets of keys). Each gives its public key to the other party and holds its own private key. The requesting party first digests the message to obtain the signature information, and then uses its own private key to encrypt the summary information (this process is called signing). The receiving party uses the requesting party's public key to verify the signature. In the same way, the receiving party completes the processing. The business response is also signed with its own private key. After the data is responded to the requester, the requester also uses the recipient's public key to verify the signature. This algorithm is widely used in the API security design of open platforms (especially payment platforms represented by WeChat and Alipay).

There are currently two mainstream signature algorithms on the payment open platform:

Open platform signature algorithm name	Standard signature algorithm name	Remark
RSA2	sha256WithRSA	First use sha256 to make the digest, and then use RSA to asymmetrically encrypt the digest (strongly recommended). It is mandatory that the length of the RSA key is at least 2048
RSA	sha1WithRAS	First use sha1 to make the digest, and then use RSA to asymmetrically encrypt the digest (there is no limit on the length of the RSA key, it is recommended to use more than 2048 bits)
Digital signatures are equivalent to a trade-off between performance and security, because the data length of the digest result is fixed and efficient. The digest is asymmetrically encrypted each time, and the performance loss is controlled.

5. Own practical experience

5.1 Background introduction

The author has been engaged in R&D work in financial payment-related business fields before, and has participated in the API design and R&D of related systems such as 2c wallet app applications, 2b fund distribution SaaS systems, and fund distribution open platforms. Let’s take the open platform for fund distribution as an example to talk about the construction of API security in detail.

Let’s first talk about what an open platform is: in a nutshell, it means that enterprises accumulate capabilities based on their own business ecology (or based on their own business SOPs), and open them in the form of APIs for use by third-party developers (individuals or enterprises) ( Developers integrate capabilities into their own applications to achieve the purpose of empowerment). This behavior is called Open API, and enterprises/platforms that provide open APIs are called open platforms.

The fund issuance open platform is based on the salary issuance SOP (standard business process) to accumulate capabilities and is open to the outside world in the form of API, which facilitates enterprises to integrate the salary issuance capability into their own applications, thereby having the ability to issue salary. The open platform for fund distribution adopts the API GateWay architecture design as a whole.

5.2 Overall architecture of API gateway

Figure 9 API GateWay architecture design

The API gateway uses pipeline (chain of responsibility model) to implement the core processing flow of the gateway, treating each processing logic as a pipe, and each pipe handles one thing. In this way, whether you add processing logic or add services of different protocols, you only need to add a pipe to the scheduling logic. If you want to disable a certain pipe, you can also exclude it statically or dynamically, which is pluggable. After the client requests it, a series of prerequisite logic such as authentication, access control, flow control, and offloading are implemented through the pipeline. The underlying container is implemented based on netty, and the http protocol is used for external exposure. The request is processed by the container thread pool, and then distributed to the application thread pool for asynchronous processing. When designing the application thread pool, we considered that different types of tasks may take different times, so we split the tasks into different thread pools for isolation, improve the concurrency of different types of tasks, and thereby improve the overall throughput.

5.3 Reasons for choosing a gateway

Why adopt the design of API GateWay? There are three core considerations

1. Isolation

Isolation is a kind of protection for the security of enterprise systems. Since APIs are provided at the boundary for access between enterprise organizations or outside the enterprise, it is the primary responsibility of APIs to ensure that enterprise systems are not accessed by threats. In terms of security, the API gateway realizes the separation of security access control capabilities from the application to the API gateway, achieving security isolation.

2. Decoupling

Service providers often hope that services have always stable service provision capabilities, so they often do not want to be interfered by too many external functional requirements. However, the rapid development of business determines that the needs of business access parties are changeable, so through the service An intermediate layer is set up between the provider and the service visitor, through which different business access requests are encapsulated and transformed and accessed according to the unified service provider requirements. Through such an intermediate layer, two parties with completely different demands can be effectively reconciled and decoupled.

3.Extensibility

In terms of location and form, API GateWay plays a role similar to that of a proxy. In addition to being responsible for receiving, routing, and responding to requests, it can also perform tasks such as flow control, log management, and security control. Since the business may change rapidly, if the core business functions cannot quickly meet the requirements in some aspects, API GateWay can realize the rapid expansion of custom functions through plug-in design to adapt to the flexible and changing needs of the business.

5.4 Gateway security construction

When an application accesses the platform, the platform needs to assign appId and appSecret to the application, set security rules (encryption method), mainly using two authentication methods: digest algorithm sha256 (salt) and digital signature sha256WithRsa, and then allocate resource (interface) permissions As well as related configurations such as interface current limiting and whitelisting. Then the access party encapsulates the message and requests the debugging interface according to the corresponding encryption rules, and then accesses it.

details:

IP whitelist : IP whitelist refers to opening the access rights of the interface to some IPs, so as to avoid access attacks by other IPs.
Timestamp : The timestamp carried in the request message is compared with the current time of the server and is directly intercepted if it exceeds the specified threshold.
Random sequence : No repetition is allowed within the valid range of the timestamp. Timestamp + random sequence effectively solves the replay problem.
Interface current limiting : protect server resources.

Take sha256WithRsa as an example: the requester carries the business field, appId, random sequence, timestamp and other fields for sorting, then performs sha256 summary calculation, and then uses its own private key to encrypt the summary result with Rsa to obtain the sign (this process is called adding signature), the signature result and other fields are encapsulated and transmitted to the server. After receiving it, the server first verifies the timestamp, random sequence, and IP. After the verification passes, it uses the public key of the requester to verify the signature. After the signature verification passes, the business process is carried out. After the business processing is completed, the response data is sha256. Then use the private key to perform RSA encryption on the summary data to obtain the sign, and respond to the requester together with the business message. The requester verifies the signature and processes the data in the same way. This is the entire request-response security process mechanism.

5.5 Summary

API gateway is not only a security solution, but also a comprehensive solution for API governance. It takes comprehensive considerations of security, isolation, scalability and other aspects into an enterprise-level API governance. universal solution.

write at the end

This article combines the actual business pain points to rectify the security risk vulnerabilities in the system, and implement the verification to solve the problems, then compares and analyzes the industry security solutions, and discusses some architectural designs related to API security based on previous work experience. It may not be comprehensive, or it may not be completely applicable to all situations, but the significance of this article is more to inspire people to think about API security and awaken awareness of API security.

Author: JD Logistics Wei Xiaofeng

Source: JD Cloud Developer Community Ziyuanqishuo Tech Please indicate the source when reprinting

Practical combat of sorting platform API security governance | JD Logistics technical team