怪我咯2017-04-18 10:57:00
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?
高洛峰2017-04-18 10:57:00
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
Parameter description
Signature method
sign=signature(path?query&imei×tamp&SIGN_KEY)
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)
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.
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.
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.
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.
PHPz2017-04-18 10:57:00
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
