Discussion on the security issues of PHP writing APP interface

Before discussing this issue, one thing to confirm is that as an Internet Coder, whether you are a front-end or a back-end, you must have a certain understanding of http requests, know the characteristics of http, and clearly understand the inside of http. What are Request and Response? Know why cookies, sessions, and verification codes exist on websites, and the meaning and necessity of them. Because discussing the security of APP interfaces is discussing the security of HTTP requests;

I generally divide APP interfaces into three categories, ordinary interfaces, form interfaces, and member interfaces; this article focuses on member interfaces

ordinary interfaces

general For GET requests, such as getting a news list GET http://Example.com/index.php?module=news&action=list, in order to prevent collection or violent query, our PC side generally does the following processing:

1. Prevent this site File_get_contents is blocked by it, so user_agent must be identified. If it is not accessed through a browser, it will not be shown directly.
   
2. If others visit by forging user_agent, the crawler will be controlled by the number of visits per unit of time. You can write an algorithm to process if another IP has more visits in one minute before and after. However, there will be a situation, that is, if a certain community or company uses a certain IP for the external network, this will lead to a dead end, so it must be handled with the cookie in the browser
   Summary: The request header can Forgery, the IP address can be changed, and the cookies can be cleared. Basically, it is difficult to prevent this problem on the PC side. For example, I often collect data from major sites such as Taobao and Dianping.

How to deal with this problem on the APP side? We can grab the http request packet of Dianping APP and take a look:

<code>GET http://114.80.165.113/mapi/ugcuserfeeds.bin?filtertype=5&userid=129059048&token=73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff&start=0 HTTP/1.1
Host: 114.80.165.113
Accept: */*
pragma-appid: 351091731
pragma-newtoken: c2032338f6abf96c8e2984db1655f2bac73b88f799e49aab4a426d414f994b5f
pragma-token: 73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff
pragma-dpid: 9214560561001942797
pragma-device: 566fe5aeb75a827967fbad8356608134ba98a4a6
Proxy-Connection: keep-alive
pragma-os: MApi 1.1 (dpscope 7.5.0 appstore; iPhone 8.3 iPhone7,1; a0d0)
Accept-Language: zh-cn
network-type: wifi
User-Agent: MApi 1.1 (dpscope 7.5.0 appstore; iPhone 8.3 iPhone7,1; a0d0) Paros/3.2.13 </code>

When you visit directlyhttp://114.80.165.113/mapi/ugcuserfeeds.bin?filtertype=5&userid =129059048&token=73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff&start=0, block it directly from the server and return a 450 error;

PHP servers are generally Apache or Nign x, we can also configure the configuration items according to some agreement with the client developer. Customized Request header information, such as parama-* above, can be obtained in the server configuration items, and then based on whether it is the agreed Request information, if not, it will be rewritten to 450;

But , we can obtain all the request header information by capturing the packet, and then we can completely simulate the request header information to obtain the data;

Many APPs can obtain the data of the API interface at most this step, and it is very easy to process. json format, and the Dianping APP directly returns here a bunch of garbled data that looks like it has been compressed:

This is somewhat similar to gzip on the PC side. The server side returns gzip compressed data, and the browser decompresses it. Use this gzip to get the real data and then display it;
I don’t know if the garbled data in the review is also based on this principle. If so, I have to say it is really "awesome" because the decompression algorithm occurs in Its own APP, which not only ensures data security, but also saves bandwidth traffic and speeds up data transmission. How it is done is not yet known;

Form interface

is similar to the from form in HTML, which mainly submits data to the server. Generally, it is a post HTTP request. The main danger is from forcing HTTP requests and bursting the database. On the PC side, we usually solve this problem through verification codes, but on the APP side, the only thing I can think of is passing verification codes. The method is just that the PC side stores the verification code into the session, while the APP side stores it into the cache; but if the verification code is added, the user experience will definitely be greatly compromised. There must be a better way for this. Solution, how to solve it is still unknown;

Member interface

The so-called member interface is a request similar to http://Example.com/index.php?module=users&action=info&user_id=333, and then the server The end directly performs corresponding membership operations based on user_id. This is extremely dangerous interface processing, which is equivalent to exposing the current membership system. As long as the other party changes the user_id, all member-corresponding interfaces 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 token parameters; and how to deal with this token?

First of all, let me talk about the four solutions I have experienced before encrypting this interface:

Option 1
Agree with the APP developer on a specific md5 combination algorithm, and then compare the two ends. If they are the same, allow , deny if they are not the same;
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;

Option 2
The password in the database membership table is an 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 if they know it. , after all, it is encrypted, and every time you request the interface 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;
But this idea is too yang too simple Yes, although the person who captured the packet cannot log in to the member through the ciphertext password, once he knows the token, unless the user changes the password, he can always use the token to operate the relevant interface of the member;

Option 3
Passed Symmetric encryption algorithm. This encryption algorithm performs time-sensitive encryption on uid+website public key and is available within a certain time limit. When the member logs in successfully, the server encrypts the ID and returns it to the client. The client brings this parameter every time it requests the interface, and the server authenticates through decryption;
But doing so is also unsafe. Because, to protect ourselves from the outside, we cannot protect ourselves from the inside. I heard that the Ctrip outage this time was due to the malicious operations of internal personnel who resigned. If internal malicious personnel know the corresponding algorithm rules, they can operate related members through the interface even if they do not have database permissions;

Option 4
When members log in, they request the login interface, and then the server returns a token to the client , the token generation rule is website public key + current uid + current timestamp + a random number double encryption. Depending on the needs, decide whether to put the token into the cache and wait for a period of time to automatically expire, or put it into the database (if you want to put it in When entering the database, create a separate table to record the user's login and logout time), and change it when the user logs out to ensure that the token can only be used between the user's manual logout and login.
To ensure security, users should be allowed to log out automatically within a period of time; this solution cooperates with Linux and database permission management to prevent both external and internal protection;

Notes on the development of other interfaces

1. It is best to use JSON format for data format Data, because JSON has better cross-platform capabilities. When generating JSON, you should pay attention to the two formats of json: object (dictionary) and array; there is no similar foreach in PHP in mobile development languages. It cannot traverse objects, but can only traverse arrays. Their operations on objects are generally through Key name to get the key value.
   
2. Whether it is success or failure. The interface must provide clear data status information and cannot return NULL. If NULL is returned, it will crash on the IOS side.

The above has introduced the first discussion on the security issues of writing APP interfaces in PHP, including aspects of the content. I hope it will be helpful to friends who are interested in PHP tutorials.