HTTP interface Encryption "one": in mobile apps, protect the data on the server by encrypting the URL accessed by the client

Source: http://meiyitianabc.blog.163.com/blog/static/10502212720131056273619/

I think there are a few key points to securing server-side data:

1. Cannot have an impact on the experience, which excludes practices such as requiring the user to enter a verification code for each interface call
2. The network interaction of the interface call needs to be irregular, such as article/1–> article/1000 such an interface is too easy to be crawled away by other people
3. In order to stop the crawler in a strict sense, every network request must be non-replayed, so that other people can listen to the network interaction and replay to crawl the data
4. Server-side coding does not have a large impact, if you want to the server-side hurt – the big change, it must be unacceptable

Usually, we will take a simple and efficient method: The data returned by the server encryption to solve, but this practice does not solve the above mentioned 2nd, the interface calls when the URL of the regularity is too strong, the network to listen to the data, it is easy to find the law of the URL address, encryption of the crack is very simple, The decompile directly navigates to the decryption function and gets the key. Of course, in the face of powerful anti-compilation projects, all efforts are futile, no matter what method you use, you can find the intermediate logic and simulate a client to crawl the data.

I would like to propose a more complex method of decoding, when the client generates the request, the interface URL for RSA encryption processing.

Suppose we would have needed access to an interface such as Http://api.example.com/articles, and the interface would return JSON data. Before the client accesses this URL, we'll do this:

1. Add client timestamp: http://api.example.com/1322470148/articles
2. RSA encrypts the path segment of the URL, and then base64:http://api.example.com/tbhiskcgcn+ Wmk3pftbyzpqfakvx9se9omoxvl00kcblnikw2c1mb7ogcfueptxaug06nlbnhr5bftjt7xu7uwdpuyyvcfrdi37svygrcozaxacogxgpx5dhzqqjia0icxww j+d1rijqxfwq++3/iguogdzgvqnpil420bpztb8=

Our real access to the address has become such a long URL structure, we through the RSA algorithm padding parameters and timestamps, we can let the long bas64 string after the time of each access changes, and we can on the server side of the request within one hours of the string is written down , does not allow the re-visit, which prevents the Crawler replay request attempt.

On the server side, we need to restore the URL back before the response is made. On the server side, now is the framework of the world, generally have a unique portal, if you are using the PHP language, mainly in the entrance of the index.php plus some code on it:

123456789101112131415161718192021222324252627282930

if ($_SERVER[‘HTTP_HOST‘] == "api.example.com"){ // 只针对api这个域名做处理    include_once dirname(__FILE__).‘/protected/components/EncryptUtil.php‘; // 加解密库，你需要实现你自己的加解密类    $request_uri = $_SERVER[‘REQUEST_URI‘];    if(isset($_SERVER[‘HTTP_HOST‘])){        if(strpos($request_uri,$_SERVER[‘HTTP_HOST‘])!==false){            // 把 REQUEST_URI 中可能包含的host信息去除掉            $request_uri=preg_replace(‘/^\w+:\/\/[^\/]+/‘,‘‘,$request_uri);        }    }    $encoded = base64_decode(substr($request_uri, 1));    if($encoded && strlen($encoded) % 128 ===0){        $real_uri = EncryptUtil::private_decrypt($encoded);         // 解密url路径        if(!$real_uri){ echo ":)"; return; }                        // 解密失败        if(preg_match("/([0-9]+)\\/(.+)/", $real_uri, $matches)){   // 提取出时间戳和真实的url请求地址            $timestamp = $matches[1];                               // 客户端请求的时间戳            $real_uri = $matches[2];                                // 客户端请求的真实地址            $_SERVER[‘REQUEST_URI‘] = $real_uri;                    // 置上本来应该有的全局$_SERVER[‘REQUEST_URI‘]            if(preg_match("/^[^?]+\\?(.+)/", $real_uri, $matches)){                $_SERVER[‘QUERY_STRING‘] = $matches[1];             // 置上本来应该有的全局$_SERVER[‘QUERY_STRING‘]                parse_str($_SERVER[‘QUERY_STRING‘], $array);                $_REQUEST = array_merge($_REQUEST, $array);         // 置上本来应该被设置的全局$_REQUEST                $_GET = array_merge($_GET, $array);                 // 置上本来应该被设置的全局$_GET            }        }else{ // url的格式不符合，没有包含时间戳            echo ":)"; return;        }    }else{ // url的长度不符合规则        echo ":)"; return;    }}

After such a piece of code processing, the framework is all right, the other code does not need to make changes, there is RSA encrypted URL support, of course, these lines of code can not prevent replay attacks, there is no request for the URL to record processing, to achieve the uniqueness of URL access, Additional code is required.

Server-side completed, the client also need to do the corresponding operation, I do not explain in detail here, paste a modified code of the actual running, IOS, the application of the THREE20 library, and compatible with the tturlrequest cache mechanism.

 

The Java version of Android I took out the HTTP part of the actual running code, because there are some related configuration, the code does not compile properly, but also put here for reference.

Android-rsa-http.zip

Usage examples:

123	BaiyiApiRequest request = newBaiyiApiRequest("articles/1");request.setListener(this);request.start();

HTTP interface Encryption "one": in mobile apps, protect the data on the server by encrypting the URL accessed by the client