我們一起聊聊如何保證API接口安全？
一、背景介紹
在實際的業務開發過程中，我們常常會碰到需要與第三方互聯網公司進行技術對接，例如支付寶支付對接、微信支付對接、高德地圖查詢對接等等服務，如果你是一個創業型互聯網，大部分可能都是對接別的公司api接口。
當你的公司體量上來了時候，這個時候可能有一些公司開始找你進行技術對接了，轉變成由你來提供api接口，那這個時候，我們應該如何設計并保證API接口安全呢？
二、方案介紹
最常用的方案，主要有兩種：
- token方案
- 接口簽名
2.1、token方案
其中 token 方案，是一種在web端使用最廣的接口鑒權方案，我記得在之前寫過一篇《手把手教你，使用JWT實現單點登錄》的文章，里面介紹的比較詳細，有興趣的朋友可以看一下，沒了解的也沒關系，我們在此簡單的介紹一下 token 方案。
圖片
從上圖，我們可以很清晰的看到，token 方案的實現主要有以下幾個步驟：
1、用戶登錄成功之后，服務端會給用戶生成一個唯一有效的憑證，這個有效值被稱為token
2、當用戶每次請求其他的業務接口時，需要在請求頭部帶上token
3、服務端接受到客戶端業務接口請求時，會驗證token的合法性，如果不合法會提示給客戶端；如果合法，才會進入業務處理流程。
在實際使用過程中，當用戶登錄成功之后，生成的token存放在redis中時是有時效的，一般設置為2個小時，過了2個小時之后會自動失效，這個時候我們就需要重新登錄，然后再次獲取有效token。
token方案，是目前業務類型的項目當中使用最廣的方案，而且實用性非常高，可以很有效的防止黑客們進行抓包、爬取數據。
但是 token 方案也有一些缺點！最明顯的就是與第三方公司進行接口對接的時候，當你的接口請求量非常大，這個時候 token 突然失效了，會有大量的接口請求失敗。
這個我深有體會，我記得在很早的時候，跟一家中、大型互聯網公司進行聯調的時候，他們提供給我的接口對接方案就是token方案，當時我司的流量高峰期時候，請求他們的接口大量報錯，原因就是因為token失效了，當token失效時，我們會調用他們刷新token接口，刷新完成之后，在token失效與重新刷新token這個時間間隔期間，就會出現大量的請求失敗的日志，因此在實際API對接過程中，我不推薦大家采用 token方案。
2.2、接口簽名
接口簽名，顧名思義，就是通過一些簽名規則對參數進行簽名，然后把簽名的信息放入請求頭部，服務端收到客戶端請求之后，同樣的只需要按照已定的規則生產對應的簽名串與客戶端的簽名信息進行對比，如果一致，就進入業務處理流程；如果不通過，就提示簽名驗證失敗。
圖片
在接口簽名方案中，主要有四個核心參數：
1、appid表示應用ID，其中與之匹配的還有appsecret，表示應用密鑰，用于數據的簽名加密，不同的對接項目分配不同的appid和appsecret，保證數據安全
2、timestamp 表示時間戳，當請求的時間戳與服務器中的時間戳，差值在5分鐘之內，屬于有效請求，不在此范圍內，屬于無效請求
3、nonce 表示臨時流水號，用于防止重復提交驗證
4、signature 表示簽名字段，用于判斷接口請求是否有效。
其中簽名的生成規則，分兩個步驟：
- 第一步：對請求參數進行一次md5加密簽名
//步驟一
String 參數1 = 請求方式 + 請求URL相對地址 + 請求Body字符串;
String 參數1加密結果= md5(參數1)- 第二步：對第一步簽名結果，再進行一次md5加密簽名
//步驟二
String 參數2 = appsecret + timestamp + nonce + 參數1加密結果;
String 參數2加密結果= md5(參數2)參數2加密結果，就是我們要的最終簽名串。
接口簽名方案，尤其是在接口請求量很大的情況下，依然很穩定。
換句話說，你可以將接口簽名看作成對token方案的一種補充。
但是如果想把接口簽名方案，推廣到前后端對接，答案是：不適合。
因為簽名計算非常復雜，其次，就是容易泄漏appsecret！
說了這么多，下面我們就一起來用程序實踐一下吧！
二、程序實踐
2.1、token方案
就像上文所說，token方案重點在于，當用戶登錄成功之后，我們只需要生成好對應的token，然后將其返回給前端，在下次請求業務接口的時候，需要把token帶上。
具體的實踐，也可以分兩種：
- 第一種：采用uuid生成token，然后將token存放在redis中，同時設置有效期2哥小時
- 第二種：采用JWT工具來生成token，這種token是可以跨平臺的，天然支持分布式，其實本質也是采用時間戳+密鑰，來生成一個token。
下面，我們介紹的是第二種實現方式。
首先，編寫一個jwt 工具。
public class JwtTokenUtil {
//定義token返回頭部
public static final String AUTH_HEADER_KEY = "Authorization";
//token前綴
public static final String TOKEN_PREFIX = "Bearer ";
//簽名密鑰
public static final String KEY = "q3t6w9z$C&F)J@NcQfTjWnZr4u7x";
//有效期默認為 2hour
public static final Long EXPIRATION_TIME = 1000L*60*60*2;
/**
* 創建TOKEN
* @param content
* @return
*/
public static String createToken(String content){
return TOKEN_PREFIX + JWT.create()
.withSubject(content)
.withExpiresAt(new Date(System.currentTimeMillis() + EXPIRATION_TIME))
.sign(Algorithm.HMAC512(KEY));
}
/**
* 驗證token
* @param token
*/
public static String verifyToken(String token) throws Exception {
try {
return JWT.require(Algorithm.HMAC512(KEY))
.build()
.verify(token.replace(TOKEN_PREFIX, ""))
.getSubject();
} catch (TokenExpiredException e){
throw new Exception("token已失效，請重新登錄",e);
} catch (JWTVerificationException e) {
throw new Exception("token驗證失敗！",e);
}
}
}接著，我們在登錄的時候，生成一個token，然后返回給客戶端。
@RequestMapping(value = "/login", method = RequestMethod.POST, produces = {"application/json;charset=UTF-8"})
public UserVo login(@RequestBody UserDto userDto, HttpServletResponse response){
//...參數合法性驗證
//從數據庫獲取用戶信息
User dbUser = userService.selectByUserNo(userDto.getUserNo);
//....用戶、密碼驗證
//創建token，并將token放在響應頭
UserToken userToken = new UserToken();
BeanUtils.copyProperties(dbUser,userToken);
String token = JwtTokenUtil.createToken(JSONObject.toJSONString(userToken));
response.setHeader(JwtTokenUtil.AUTH_HEADER_KEY, token);
//定義返回結果
UserVo result = new UserVo();
BeanUtils.copyProperties(dbUser,result);
return result;
}最后，編寫一個統一攔截器，用于驗證客戶端傳入的token是否有效。
@Slf4j
public class AuthenticationInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
// 從http請求頭中取出token
final String token = request.getHeader(JwtTokenUtil.AUTH_HEADER_KEY);
//如果不是映射到方法，直接通過
if(!(handler instanceof HandlerMethod)){
return true;
}
//如果是方法探測，直接通過
if (HttpMethod.OPTIONS.equals(request.getMethod())) {
response.setStatus(HttpServletResponse.SC_OK);
return true;
}
//如果方法有JwtIgnore注解，直接通過
HandlerMethod handlerMethod = (HandlerMethod) handler;
Method method=handlerMethod.getMethod();
if (method.isAnnotationPresent(JwtIgnore.class)) {
JwtIgnore jwtIgnore = method.getAnnotation(JwtIgnore.class);
if(jwtIgnore.value()){
return true;
}
}
LocalAssert.isStringEmpty(token, "token為空，鑒權失敗！");
//驗證，并獲取token內部信息
String userToken = JwtTokenUtil.verifyToken(token);
//將token放入本地緩存
WebContextUtil.setUserToken(userToken);
return true;
}
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
//方法結束后，移除緩存的token
WebContextUtil.removeUserToken();
}
}在生成token的時候，我們可以將一些基本的用戶信息，例如用戶ID、用戶姓名，存入token中，這樣當token鑒權通過之后，我們只需要通過解析里面的信息，即可獲取對應的用戶ID，可以省下去數據庫查詢一些基本信息的操作。
同時，使用的過程中，盡量不要存放敏感信息，因為很容易被黑客解析！
2.2、接口簽名
同樣的思路，站在服務端驗證的角度，我們可以先編寫一個簽名攔截器，驗證客戶端傳入的參數是否合法，只要有一項不合法，就提示錯誤。
具體代碼實踐如下：
public class SignInterceptor implements HandlerInterceptor {
@Autowired
private AppSecretService appSecretService;
@Autowired
private RedisUtil redisUtil;
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
throws Exception {
//appId驗證
final String appId = request.getHeader("appid");
if(StringUtils.isEmpty(appId)){
throw new CommonException("appid不能為空");
}
String appSecret = appSecretService.getAppSecretByAppId(appId);
if(StringUtils.isEmpty(appSecret)){
throw new CommonException("appid不合法");
}
//時間戳驗證
final String timestamp = request.getHeader("timestamp");
if(StringUtils.isEmpty(timestamp)){
throw new CommonException("timestamp不能為空");
}
//大于5分鐘，非法請求
long diff = System.currentTimeMillis() - Long.parseLong(timestamp);
if(Math.abs(diff) > 1000 * 60 * 5){
throw new CommonException("timestamp已過期");
}
//臨時流水號，防止重復提交
final String nonce = request.getHeader("nonce");
if(StringUtils.isEmpty(nonce)){
throw new CommonException("nonce不能為空");
}
//驗證簽名
final String signature = request.getHeader("signature");
if(StringUtils.isEmpty(nonce)){
throw new CommonException("signature不能為空");
}
final String method = request.getMethod();
final String url = request.getRequestURI();
final String body = StreamUtils.copyToString(request.getInputStream(), Charset.forName("UTF-8"));
String signResult = SignUtil.getSignature(method, url, body, timestamp, nonce, appSecret);
if(!signature.equals(signResult)){
throw new CommonException("簽名驗證失敗");
}
//檢查是否重復請求
String key = appId + "_" + timestamp + "_" + nonce;
if(redisUtil.exist(key)){
throw new CommonException("當前請求正在處理，請不要重復提交");
}
//設置5分鐘
redisUtil.save(key, signResult, 5*60);
request.setAttribute("reidsKey",key);
}
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)
throws Exception {
//請求處理完畢之后，移除緩存
String value = request.getAttribute("reidsKey");
if(!StringUtils.isEmpty(value)){
redisUtil.remove(value);
}
}
}簽名工具類SignUtil：
public class SignUtil {
/**
* 簽名計算
* @param method
* @param url
* @param body
* @param timestamp
* @param nonce
* @param appSecret
* @return
*/
public static String getSignature(String method, String url, String body, String timestamp, String nonce, String appSecret){
//第一層簽名
String requestStr1 = method + url + body + appSecret;
String signResult1 = DigestUtils.md5Hex(requestStr1);
//第二層簽名
String requestStr2 = appSecret + timestamp + nonce + signResult1;
String signResult2 = DigestUtils.md5Hex(requestStr2);
return signResult2;
}
}簽名計算，可以換成hamc方式進行計算，思路大致一樣。
三、小結
上面介紹的token和接口簽名方案，對外都可以對提供的接口起到保護作用，防止別人篡改請求，或者模擬請求。
但是缺少對數據自身的安全保護，即請求的參數和返回的數據都是有可能被別人攔截獲取的，而這些數據又是明文的，所以只要被攔截，就能獲得相應的業務數據。
對于這種情況，推薦大家對請求參數和返回參數進行加密處理，例如RSA、AES等加密工具。
同時，在生產環境，采用https方式進行傳輸，可以起到很好的安全保護作用！
