开放API接口签名验证（web和app）

 

接口安全问题

• 请求身份是否合法
• 请求参数是否被篡改
• 请求是否唯一
• 对于敏感的api接口，需使用https协议

AccessKey&SecretKey （开放平台）

请求身份：

为开发者分配AccessKey（开发者标识，确保唯一）和SecretKey（用于接口加密，确保不易被穷举，生成算法不易被猜测）。

防止篡改：

参数签名

1. 按照请求参数名的字母升序排列非空请求参数（包含AccessKey）(ASCII码排序)，使用URL键值对的格式（即key1=value1&key2=value2…）拼接成字符串stringA；
2. 在stringA最后拼接上Secretkey得到字符串stringSignTemp；
3. 对stringSignTemp进行MD5运算，并将得到的字符串所有字符转换为大写，得到sign值。

请求携带参数AccessKey和Sign，只有拥有合法的身份AccessKey和正确的签名Sign才能放行。这样就解决了身份验证和参数篡改问题，即使请求参数被劫持，由于获取不到SecretKey（仅作本地加密使用，不参与网络传输），无法伪造合法的请求。

重放攻击

虽然解决了请求参数被篡改的隐患，但是还存在着重复使用请求参数伪造二次请求的隐患。

timestamp+nonce方案

nonce指唯一的随机字符串，用来标识每个被签名的请求。通过为每个请求提供一个唯一的标识符，服务器能够防止请求被多次使用（记录所有用过的nonce以阻止它们被二次使用）。

然而，对服务器来说永久存储所有接收到的nonce的代价是非常大的。可以使用timestamp来优化nonce的存储。

假设允许客户端和服务端最多能存在15分钟的时间差，同时追踪记录在服务端的nonce集合。当有新的请求进入时，首先检查携带的timestamp是否在15分钟内，如超出时间范围，则拒绝，然后查询携带的nonce，如存在已有集合，则拒绝。否则，记录该nonce，并删除集合内时间戳大于15分钟的nonce（可以使用redis的expire，新增nonce的同时设置它的超时失效时间为15分钟）。

实现：

请求接口：http://api.test.com/test?name=hello&home=world&work=java

• 客户端

  1. 生成当前时间戳timestamp=now和唯一随机字符串nonce=random
  2. 按照请求参数名的字母升序排列非空请求参数（包含AccessKey) 
     stringA="AccessKey=access&home=world&name=hello&work=java&timestamp=now&nonce=random";
  3. 拼接密钥SecretKey 
     stringSignTemp="AccessKey=access&home=world&name=hello&work=java&timestamp=now&nonce=random&SecretKey=secret";
  4. MD5并转换为大写 
     sign=MD5(stringSignTemp).toUpperCase();
  5. 最终请求 
     http://api.test.com/test?name=hello&home=world&work=java&timestamp=now&nonce=nonce&sign=sign;

• 服务端 
  

---

  1. api请求客户端想服务器端一次发送用用户认证信息（用户名和密码），服务器端请求到改请求后，验证用户信息是否正确。

        如果正确：则返回一个唯一不重复的字符串（一般为UUID），然后在Redis（任意缓存服务器）中维护Token----Uid的用户信息关系，以便其他api对token的校验。

        如果错误：则返回错误码。

 

服务器设计一个url请求拦截规则：

（1）判断是否包含timestamp，token，sign参数，如果不含有返回错误码。

（2）判断服务器接到请求的时间和参数中的时间戳是否相差很长一段时间（时间自定义如半个小时），如果超过则说明该 url已经过期（如果url被盗，他改变了时间戳，但是会导致sign签名不相等）。

（3）判断token是否有效，根据请求过来的token，查询redis缓存中的uid，如果获取不到这说明该token已过期。

（4）根据用户请求的url参数，服务器端按照同样的规则生成sign签名，对比签名看是否相等，相等则放行。（自然url签名也无法100%保证其安全，也可以通过公钥AES对数据和url加密，但这样如果无法确保公钥丢失，所以签名只是很大程度上保证安全）。

（5）此url拦截只需对获取身份认证的url放行（如登陆url），剩余所有的url都需拦截。

 3.Token和Uid关系维护

    对于用户登录我们需要创建token--uid的关系，用户退出时需要需删除token--uid的关系。

获取全部请求参数：

               String sign = request.getParameter("sign");
		Enumeration<?> pNames =  request.getParameterNames();
		Map<String, Object> params = new HashMap<String, Object>();
		while (pNames.hasMoreElements()) {
			String pName = (String) pNames.nextElement();
			if("sign".equals(pName))continue;
			Object pValue = request.getParameter(pName);
			params.put(pName, pValue);
		}

生成签名：

        public static String createSign(Map<String, String> params, boolean encode)
			throws UnsupportedEncodingException {
		Set<String> keysSet = params.keySet();
		Object[] keys = keysSet.toArray();
		Arrays.sort(keys);
		StringBuffer temp = new StringBuffer();
		boolean first = true;
		for (Object key : keys) {
			if (first) {
				first = false;
			} else {
				temp.append("&");
			}
			temp.append(key).append("=");
			Object value = params.get(key);
			String valueString = "";
			if (null != value) {
				valueString = String.valueOf(value);
			}
			if (encode) {
				temp.append(URLEncoder.encode(valueString, "UTF-8"));
			} else {
				temp.append(valueString);
			}
		}
 
		return MD5Utils.getMD5(temp.toString()).toUpperCase();
	}

 

---

Token&AppKey（APP）

在APP开放API接口的设计中，由于大多数接口涉及到用户的个人信息以及产品的敏感数据，所以要对这些接口进行身份验证，为了安全起见让用户暴露的明文密码次数越少越好，然而客户端与服务器的交互在请求之间是无状态的，也就是说，当涉及到用户状态时，每次请求都要带上身份验证信息。

Token身份验证

1. 用户登录向服务器提供认证信息（如账号和密码），服务器验证成功后返回Token给客户端；
2. 客户端将Token保存在本地，后续发起请求时，携带此Token；
3. 服务器检查Token的有效性，有效则放行，无效（Token错误或过期）则拒绝。

安全隐患：Token被劫持，伪造请求和篡改参数。

Token+AppKey签名验证

与上面开发平台的验证方式类似，为客户端分配AppKey（密钥，用于接口加密，不参与传输），将AppKey和所有请求参数组合成源串，根据签名算法生成签名值，发送请求时将签名值一起发送给服务器验证。这样，即使Token被劫持，对方不知道AppKey和签名算法，就无法伪造请求和篡改参数。再结合上述的重发攻击解决方案，即使请求参数被劫持也无法伪造二次重复请求。

实现

登陆和退出请求

后续请求

• 客户端 
  和上述开放平台的客户端行为类似，把AccessKey改为token即可。

• 服务端 
  

---

源码

请移步聚合支付平台，博主正在开发的一款开源项目，其中接口验证采用的就是上文中开放平台的验证方案，欢迎大家Star!