App Interface Security

For
---> Non-open platform
---> Intercompany products
 
Interface Features Summary:
1, because the non-open, so all the interface is closed, only for the company's internal products;
2, Because it is non-open, the OAuth protocol does not work, because there is no intermediate user authorization process,
3, a bit of interface requires users to log in to access;
4, a bit of interface does not require user login to access;
 
for the above characteristics, Mobile-to-server communication requires 2 keys, or 2 tokens.
The first token is for the interface (Api_token);
The second token is for the user (User_token);
 
First token (api_token)
 
Its responsibility is to maintain interface access to the concealment and effectiveness, to ensure that the interface can only be used for their own people, how to do? The following ideas are as follows: The
generates a random string by the common properties owned by both the server side and the client, and the client generates the string, and the server generates a string to validate the client's string by the same algorithm.
Now the interface is basically the MVC pattern, the URL is basically restful style, the URL is in the following format:
http://blog.snsgou.com/module name/Controller name/method name? parameter Name 1 = parameter value 1& parameter name 2 = parameter value 2 & parameter Name 3 = argument value 3
 
Interface token generation rule reference is as follows:
Api_token = MD5 (' module name ' + ' controller name ' + ' method name ' + ' 2013-12-18 ' + ' encryption key ') = 770fed4 Ca2aabd20ae9a5dd774711de2
where
1, ' 2013-12-18 ' is the time of day,
2, ' encryption key ' is a private encryption key, the mobile phone side needs to register an "interface user" account on the server side, The system will assign an account and password, the data table design reference is as follows:
Field name   field type   Comment
Client_id varchar   Client ID
Client_secret  varchar   Client (encryption) key
(note: Only the core fields are listed, other extensions!!!)
 
Server-side interface verification, PHP implementation process is as follows:

<?php//1, get the Get parameter value $module = $_get[' mod '); $controller = $_get[' ctl '] $action = $_get[' act ']; $client _id = $_get[' Client _id ']; $api _token = $_get[' api_token];//2, according to the client passed client_id, query the database, get the corresponding Client_secret$client_secret = Getclientsecretbyid ($client _id);//3. Regenerate a copy of the server Api_token$api_token_server = MD5 ($module. $controller. $action  . Date (' y-m-d ', Time ()).  $client _secret);//4, the client passes the Api_token with the server generated Api_token to proofread, if not equal, the validation fails if ($api _token! = $api _token_server) {exit (' Access deny ');  Deny access to}//5, validate pass, return data to client//...?>

　　

Say the second token (user_token)

Its role is to protect the user's user name and password multiple submissions, in case the password leaks.
If the interface requires a user to log in, the access process is as follows:
1, users submit "user name" and "password", to achieve login (conditions allow, this step is best to go HTTPS);
2, after the successful login, the server returns a User_token, the generated rule reference is as follows:
User_token = MD5 (' UID of user ' + ' unix timestamp ') = ETYE0FGKGK4CA2AABD20AE9A5DD77471FGF
The service side uses the data table to maintain the status of the User_token, and the table is designed as follows:
Field Name Segment Type Comment
user_id int User ID
User_token varchar (36) User Token
expire_time int Expiration Time (Unix timestamp)
(Note: Only the core fields are listed, other extensions!!!) ）
After the server generates User_token, return to the client (own storage), each time the client interface requests, if the interface requires users to log in to access, you need to send user_id and user_token back to the server, the service side to accept the 2 parameters, the following steps need to do:
1, the effectiveness of testing api_token;
2, delete the expired User_token table records;
3, according to user_id,user_token get table records, if the table record does not exist, directly return the error, if the record exists, then proceed to the next step;
4, update the expiration time of the User_token (delay, to ensure that the validity of continuous operation is not lost line);
5, return interface data;

The interface use cases are as follows:

1, publish the log
url:http://blog.snsgou.com/blog/index/addblog?client_id=wt3734wy636dhd3636sr5858t6&api_token= 880fed4ca2aabd20ae9a5dd774711de2&user_token=etye0fgkgk4ca2aabd20ae9a5dd77471fgf&user_id=12
Request Method: POST
Post parameters: title= I am the title &content= I am content
Return Data:
{
' Code ' = 1,//1: Success 0: Failure
' msg ' = ' operation succeeded '//Login failed, unauthorized access
' Data ' = []
}

For Api_token verification, the security can be further enhanced:

Reinforcement Place One:

Add 2 more tables, an interface table, an authorization table, and the design reference is as follows:

Interface table

Field name	Field type	Comments
api_id	Int	Interface ID
Api_name	varchar (120)	Interface name, with "/" as a split line, such as Blog/index/addblog
Api_domain	VARCHAR (256)	Industry
Is_enabled	tinyint (1)	Available 1: Available 0: Not available
Add_time	Int	Add Time (Stamp)

(Note: Only the core fields are listed, other extensions!!!) ）

Authorization Form

Field name	Field type	Comments
client_id	Int	Client ID
api_id	Int	API number
Api_name	varchar (120)	Interface name, with "/" as a split line, such as Blog/index/addblog
Is_enabled	tinyint (1)	Available 1: Available 0: Not available
Add_time	Int	Add Time (Stamp)
Expire_time	Int	Expiration Time (stamp)

(Note: Only the core fields are listed, other extensions!!!) ）

The execution process is as follows:

1, the mobile side and the server generated by the Api_token comparison, if not equal, then directly return the error, otherwise, go to the next step;

2, according to the interface URL, assembly Api_name, plus the client back client_id as parameters, look for "authorization table" record, if the record exists, and valid (whether available, whether expired), then the authorization pass, return interface data, otherwise return error message;

Reinforcement Place Two:

For some very special interface, how special, which is special, I do not know, in a word, is to feel the HTTP request may be robbed, passing parameters may be tampered with, or for example:

There is a direct transfer interface, the page I input is 5 yuan, I want to give each other a transfer of 5 yuan, the result in the HTTP transmission process, was robbed and changed into 10000 yuan, and the object into a "hacker" account, that is not lost Dafa, think about, there should be 2 solutions to this problem,

Scenario One: Take the HTTPS, this is not much to say, more commonly recognized security mechanisms;

Scenario Two: Walk the digital signature, the realization principle is as follows:

An HTTP request, if required to pass the following 3 parameters

Parameter Name 1 = value of parameter 1

Parameter Name 2 = value of parameter 2

Parameter name 3 = value of parameter 3

We can append another parameter with the name Identity_key (what is not important) and the value of the parameter is the encryption key ')

Service end to the parameters, and then the same encryption rules to regenerate a copy of the Identity_key, the service side of the Identity_key and the client's identity_key to proofread, if not equal, said to be channeling, then how to operate, see for yourself!

Article reprinted from: http://blog.snsgou.com/post-766.html

App Interface Security