How do you define legal and illegal? Under the SSO framework, if you have a token, you will go sideways. If it is a third party, you will definitely need the appid and appsecret. If you need authorization, you will also need to bring the AccessToken. This will also go sideways. The simplest way is to write an IP interceptor to only allow trusted IPs to pass. , but it is used for high-level interception of internal mutual calls. Generally speaking, if the other party provides a token or appsecret, it is basically legal, right?
When designing an API, to ensure the security of a RESTful API, three major aspects should be considered:
1. Login authorization for restricted resources 2. Identity authentication for requests 3. Encrypt sensitive data
1. Login authorization for restricted resources This process is not the focus of this article and will not be described in detail. The basic process is as follows:
The client submits the account information (username + password) to the server
The server verifies successfully and returns the AccessToken to the client for storage 3. When accessing restricted resources, the client can access them by bringing the AccessToken.
2. Request authentication If the request is not signed and authenticated, you can easily capture the data through tools such as fiddler, tamper with it, submit it, and make large-scale batch calls, which will cause the system to generate a lot of junk data and system resources. It is consumed in large quantities and cannot even be used normally (in addition, of course, the current can be limited through GateWay), so we need to perform signature authentication on the request.
URL format URL:schema://domain/path?query&imei×tamp&sign
Verification process Authentication logic 1. Initially, the server has the SIGN_KEY of each App version, and the client has the corresponding version of SIGN_KEY 2. Before sending the request, encrypt it through the signature method to get a sign 3. When sending a request, it is sent to the server together with the sign 4. The server first verifies whether the timestamp timestamp is valid. For example, requests with a server timestamp 5 minutes ago are considered invalid; 5. Then take the corresponding version of SIGN_KEY to verify the sign Is it legal? 6. In order to prevent replay attacks, you need to check whether the sign is stored in redis. If it does not exist, store it in redis (cache for 5 minutes)
How to prevent data tampering
The signature parameters include all parameters of the original request. If any parameter is changed, the sign value will be different, so it cannot be tampered with.
How to prevent replay attacks
Since the signature algorithm also has imei (unique device ID) and timestamp parameters, and the signature algorithm is an irreversible algorithm (such as md5 or sha1), the sign value will not be repeated for each normal request. At this time, the server can store the 5-minute sign value for verification and filtering during replay attacks. Requests that exceed 5 minutes are directly filtered by timestamp verification.
Summary
In this way, request authentication is achieved to prevent data tampering and replay attacks, but it is necessary to ensure the safe storage of the App key (SIGN_KEY). The advantage is that it is easy to understand and implement, but the disadvantage is that it requires safe storage of the key and regular updates. Burden of keys.
3. Sensitive data encryption
1) Deploy SSL infrastructure (i.e. HTTPS), and the transmission of sensitive data is all based on SSL. 2) Only encrypt some sensitive data (such as account number + password), and add some random number as an encryption salt to prevent data from being tampered with.
We use the RSA encryption algorithm. All the parameters of the request data are converted into json and then the server RSA certificate is used to encrypt the json. The http request is enough and the server private key is decrypted
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Verify the token, or use the OAuth2 framework on the server side
How do you define legal and illegal? Under the SSO framework, if you have a token, you will go sideways. If it is a third party, you will definitely need the appid and appsecret. If you need authorization, you will also need to bring the AccessToken. This will also go sideways. The simplest way is to write an IP interceptor to only allow trusted IPs to pass. , but it is used for high-level interception of internal mutual calls. Generally speaking, if the other party provides a token or appsecret, it is basically legal, right?
When designing an API, to ensure the security of a RESTful API, three major aspects should be considered:
1. Login authorization for restricted resources
This process is not the focus of this article and will not be described in detail. The basic process is as follows:
The client submits the account information (username + password) to the server
The server verifies successfully and returns the AccessToken to the client for storage
3. When accessing restricted resources, the client can access them by bringing the AccessToken.
2. Request authentication
If the request is not signed and authenticated, you can easily capture the data through tools such as fiddler, tamper with it, submit it, and make large-scale batch calls, which will cause the system to generate a lot of junk data and system resources. It is consumed in large quantities and cannot even be used normally (in addition, of course, the current can be limited through GateWay), so we need to perform signature authentication on the request.
URL format
URL:schema://domain/path?query&imei×tamp&sign
Parameter description
Signature method
sign=signature(path?query&imei×tamp&SIGN_KEY)
Verification process
How to prevent data tamperingAuthentication logic
1. Initially, the server has the SIGN_KEY of each App version, and the client has the corresponding version of SIGN_KEY
2. Before sending the request, encrypt it through the signature method to get a sign
3. When sending a request, it is sent to the server together with the sign
4. The server first verifies whether the timestamp timestamp is valid. For example, requests with a server timestamp 5 minutes ago are considered invalid;
5. Then take the corresponding version of SIGN_KEY to verify the sign Is it legal? 6. In order to prevent replay attacks, you need to check whether the sign is stored in redis. If it does not exist, store it in redis (cache for 5 minutes)
The signature parameters include all parameters of the original request. If any parameter is changed, the sign value will be different, so it cannot be tampered with.
How to prevent replay attacksSince the signature algorithm also has imei (unique device ID) and timestamp parameters, and the signature algorithm is an irreversible algorithm (such as md5 or sha1), the sign value will not be repeated for each normal request. At this time, the server can store the 5-minute sign value for verification and filtering during replay attacks. Requests that exceed 5 minutes are directly filtered by timestamp verification.
SummaryIn this way, request authentication is achieved to prevent data tampering and replay attacks, but it is necessary to ensure the safe storage of the App key (SIGN_KEY). The advantage is that it is easy to understand and implement, but the disadvantage is that it requires safe storage of the key and regular updates. Burden of keys.
3. Sensitive data encryption1) Deploy SSL infrastructure (i.e. HTTPS), and the transmission of sensitive data is all based on SSL.
2) Only encrypt some sensitive data (such as account number + password), and add some random number as an encryption salt to prevent data from being tampered with.
We use the RSA encryption algorithm. All the parameters of the request data are converted into json and then the server RSA certificate is used to encrypt the json. The http request is enough and the server private key is decrypted
Use oauth2 or similar token