The so-called interface is a request similar to http://Example.com/index.php?module=users&action=info&user_id=333, and then the server directly performs the corresponding membership operation according to the user_id, which is extremely dangerous interface processing, equal to The current membership system is fully exposed, as long as the other party changes the user_id, the interface corresponding to all members can be operated.
Generally, on the PC side, we use encrypted cookies to identify members and maintain sessions; however, cookies belong to the local storage function of the browser. The APP side cannot be used, so we have to identify members through the token parameter; and how should this token be handled?
First of all, let’s talk about the four schemes I have experienced before doing this interface encryption:
Scheme 1. Agree a specific md5 combination algorithm
with the APP developer, and then compare the two ends. If they are the same, allow, and deny if they are different. ;
However, this is also unsafe. If the APP program is decompiled, these agreed algorithms will be exposed. Especially in Android APP, with the algorithm, it is possible to simulate the interface request and pass the verification
;
The password is the md5 value with random encryption and double encryption; when the user logs in, I return the corresponding uid and password of the member. Although the password is in plain text, others cannot log in. After all, it is encrypted, and then Every time the interface is requested user_id=333&token=aa37e10c7137ac849eab8a2d5020568f, you can quickly find the token corresponding to the current uid through the primary key uid, and then compare it again;
but this idea is too yang too simple, although the person who captures the packet cannot pass the ciphertext password to log in to the member, but once the token is known, unless the user changes the password, he can always use the token to operate the relevant interface of the member;
Scheme 3
Through a symmetric encryption algorithm, the encryption algorithm performs aging encryption on the uid+ website public key, which is available within a certain time limit. When the member logs in successfully, the server side encrypts the ID and returns it to the client side. The client side brings this parameter every time it requests the interface, and the server side passes the decryption and authentication;
however, it is not safe to do so. Because, it is not necessary to guard against the outside, and I heard that the downtime of Ctrip this time is because of the malicious operation of the internal staff. If internal malicious people know the corresponding algorithm rules, even if they do not have database permissions, they can operate related members through the interface;
Scheme 4: When a
member logs in, request the login interface, and then the server returns a token to the client, the token The generated rule is the website public key + current uid + current timestamp + a random number double encryption, according to the demand, it is decided whether to put the token in the cache and wait for a period of time to automatically expire, or put it in the database (if it is to be put in the database, it should be put into the database separately. Take out a table, record the user's login and logout time by the way), change it when the user logs out and log in, and ensure that the token is only useful between the user's artificial logout and login.
In order to ensure security, users should be guaranteed to automatically log out within a certain period of time; this solution cooperates with Linux and database rights management to prevent external and internal protection;
precautions for other interface development The
data format should preferably use JSON format data, because JSON has relatively Good cross platform. When generating JSON, pay attention to the two formats of JSON: object (dictionary) and array; there is no foreach similar to PHP in the mobile development language, which cannot traverse objects, but can only traverse arrays. Their operations on objects are generally done through key name to get the key value.
Whether it is success or failure. The interface must provide clear data status information, and cannot return NULL. If it returns NULL, it will crash on the IOS side.
Generally, on the PC side, we use encrypted cookies to identify members and maintain sessions; however, cookies belong to the local storage function of the browser. The APP side cannot be used, so we have to identify members through the token parameter; and how should this token be handled?
First of all, let’s talk about the four schemes I have experienced before doing this interface encryption:
Scheme 1. Agree a specific md5 combination algorithm
with the APP developer, and then compare the two ends. If they are the same, allow, and deny if they are different. ;
However, this is also unsafe. If the APP program is decompiled, these agreed algorithms will be exposed. Especially in Android APP, with the algorithm, it is possible to simulate the interface request and pass the verification
;
The password is the md5 value with random encryption and double encryption; when the user logs in, I return the corresponding uid and password of the member. Although the password is in plain text, others cannot log in. After all, it is encrypted, and then Every time the interface is requested user_id=333&token=aa37e10c7137ac849eab8a2d5020568f, you can quickly find the token corresponding to the current uid through the primary key uid, and then compare it again;
but this idea is too yang too simple, although the person who captures the packet cannot pass the ciphertext password to log in to the member, but once the token is known, unless the user changes the password, he can always use the token to operate the relevant interface of the member;
Scheme 3
Through a symmetric encryption algorithm, the encryption algorithm performs aging encryption on the uid+ website public key, which is available within a certain time limit. When the member logs in successfully, the server side encrypts the ID and returns it to the client side. The client side brings this parameter every time it requests the interface, and the server side passes the decryption and authentication;
however, it is not safe to do so. Because, it is not necessary to guard against the outside, and I heard that the downtime of Ctrip this time is because of the malicious operation of the internal staff. If internal malicious people know the corresponding algorithm rules, even if they do not have database permissions, they can operate related members through the interface;
Scheme 4: When a
member logs in, request the login interface, and then the server returns a token to the client, the token The generated rule is the website public key + current uid + current timestamp + a random number double encryption, according to the demand, it is decided whether to put the token in the cache and wait for a period of time to automatically expire, or put it in the database (if it is to be put in the database, it should be put into the database separately. Take out a table, record the user's login and logout time by the way), change it when the user logs out and log in, and ensure that the token is only useful between the user's artificial logout and login.
In order to ensure security, users should be guaranteed to automatically log out within a certain period of time; this solution cooperates with Linux and database rights management to prevent external and internal protection;
precautions for other interface development The
data format should preferably use JSON format data, because JSON has relatively Good cross platform. When generating JSON, pay attention to the two formats of JSON: object (dictionary) and array; there is no foreach similar to PHP in the mobile development language, which cannot traverse objects, but can only traverse arrays. Their operations on objects are generally done through key name to get the key value.
Whether it is success or failure. The interface must provide clear data status information, and cannot return NULL. If it returns NULL, it will crash on the IOS side.