SpringCloud微服務，如何保證對外接口的安全？
大家好，我是飄渺。如果你的微服務需要向第三方開放接口，如何確保你提供的接口是安全的呢？
1. 什么是安全接口
通常來說，要將暴露在外網的 API 接口視為安全接口，需要實現防篡改和防重放的功能。
1.1 什么是篡改問題？
由于 HTTP 是一種無狀態協議，服務端無法確定客戶端發送的請求是否合法，也不了解請求中的參數是否正確。以一個充值接口為例：
http://localhost/api/user/recharge?user_id=1001&amount=10如果非法用戶通過抓包獲取接口參數并修改 user_id 或 amount 的值，就能為任意賬戶添加余額。
1.1.1 如何解決篡改問題？
雖然使用 HTTPS 協議能對傳輸的明文進行加密，但黑客仍可截獲數據包進行重放攻擊。兩種通用解決方案是：
- 使用 HTTPS 加密接口數據傳輸，即使被黑客破解，也需要耗費大量時間和精力。
- 在接口后臺對請求參數進行簽名驗證，以防止黑客篡改。
簽名的實現過程如下圖所示：
圖片
- 步驟1：客戶端使用約定好的規則對傳輸的參數進行加密，得到簽名值sign1，并且將簽名值也放入請求的參數中，隨請求發送至服務端。
- 步驟2：服務端接收到請求后，使用約定好的規則對請求的參數再次進行簽名，得到簽名值 sign2。
- 步驟3：服務端比對 sign1 和 sign2 的值，若不一致，則認定為被篡改，判定為非法請求。
1.2. 什么是重放問題？
防重放也叫防復用。簡單來說就是我獲取到這個請求的信息之后什么也不改,，直接拿著接口的參數去 重復請求這個充值的接口。此時我的請求是合法的, 因為所有參數都是跟合法請求一模一樣的。重放攻擊會造成兩種后果：
- 針對插入數據庫接口：重放攻擊，會出現大量重復數據，甚至垃圾數據會把數據庫撐爆。
- 針對查詢的接口：黑客一般是重點攻擊慢查詢接口，例如一個慢查詢接口1s，只要黑客發起重放攻擊，就必然造成系統被拖垮，數據庫查詢被阻塞死。
1.2.1 如何解決重放問題？
防重放，業界通?；?nonce + timestamp 方案實現。每次請求接口時生成 timestamp 和 nonce 兩個額外參數，其中 timestamp 代表當前請求時間，nonce 代表僅一次有效的隨機字符串。生成這兩個字段后，與其他參數一起進行簽名，并發送至服務端。服務端接收請求后，先比較 timestamp 是否超過規定時間（如60秒），再查看 Redis 中是否存在 nonce，最后校驗簽名是否一致，是否有篡改。
如果看過我DDD&微服務系列中冪等方案的文章，對于nonce方案肯定比較熟悉，這就是冪等方案中的token機制，只不過此時冪等key是由客戶端生成的。
圖片
2. 身份認證方案
我們已經了解了如何解決對外接口可能遇到的篡改和重放問題，但還遺漏了最關鍵的身份認證環節。一般而言，對互聯網開放的接口不是任何人都能調用的，只有經過認證的用戶或機構才有權限訪問。解決身份認證問題通常通過 AppId 和 AppSecret 實現。
2.1 AppId + AppSecret
AppId作為一種全局唯一的標識符，主要用于用戶身份識別。為防止其他用戶惡意使用別人的 AppId 發起請求，通常采用配對 AppSecret 的方式，類似一種密碼。在請求方發起請求時，需將 AppID 和 AppSecret 搭配上前文提到的安全方案，一并簽名提交給提供方驗證。
現在，讓我們再來梳理一下完整的簽名方案。
1、服務方提供一組 AppId 和 AppSecret，并由客戶端保存。
2、將timestamp、nonce、AppId 與請求參數一起并按照字典排序，使用URL鍵值對(key1=value1&key2=value2…)的格式拼接形成字符串StringA。
3、在StringA的最后拼接上AppSecret，得到字符串StringB。
4、使用摘要算法對 StringB 進行加密，并將得到的字符串轉為大寫，得到簽名值 sign，將其與參數一起發送給服務端。
5、服務端接收請求后，對接口進行校驗（時間、隨機字符串、身份驗證、簽名）。
在這個流程中，AppID 參與本地加密和網絡傳輸，而 AppSecret 僅作本地加密使用，不參與網絡傳輸。服務端拿到 AppID 后，從存儲介質中獲取對應的 AppSecret，然后采用與客戶端相同的簽名規則生成服務端簽名，最后比較客戶端簽名和服務端簽名是否一致。
3. 代碼實現
"Talk is cheap. Show me the code." 說了這么久，現在讓我們從代碼的角度來看看如何在 DailyMart 中將上面的理論知識串聯起來，安全地對外提供接口。
本文涉及到的所有代碼都已上傳至github，如果需要請參考文末方式進行獲取。
3.1 AppId 和 AppSecret的生成
在生成 AppId 和 AppSecret 時，只需確保 AppId 的全局唯一性，然后將生成的 AppId 和 AppSecret 進行綁定。在 DailyMart 中，我們使用短鏈的生成算法來生成 AppId，再對 AppId 進行 SHA 加密后得到對應的 AppSecret。
private static String getAppKey() {
long num = IdUtils.nextId();
StringBuilder sb = new StringBuilder();
do {
int remainder = (int) (num % 62);
sb.insert(0, BASE62_CHARACTERS.charAt(remainder));
num /= 62;
} while (num != 0);
return sb.toString();
}通過這個算法生成的 AppId 和 AppSecret 形如：
appKey=6iYWoL2hBk9, appSecret=5de8bc4d8278ed4f14a3490c0bdd5cbe369e8ec93.2 API校驗器
在一個系統中可能存在多種認證邏輯，比如既要支持今天所講的開放接口校驗邏輯，還需要支持內部服務的 JWT 認證邏輯。為了方便處理，我們抽象一個 API 認證接口，各種認證邏輯獨立到自己的實現中，對于今天所講的開放接口認證，主要關注 ProtectedApiAuthenticator。
圖片
//認證接口
public interface ApiAuthenticator {
AuthenticatorResult auth(ServerWebExchange request);
}
//具體實現
@Slf4j
public class ProtectedApiAuthenticator implements ApiAuthenticator {
...
}3.2 網關過濾器
接口的安全校驗很適合放在網關層實現，因此我們需要在網關服務中創建一個過濾器 ApiAuthenticatorFilter。
@Component
@Slf4j
public class ApiAuthenticatorFilter implements GlobalFilter, Ordered {
...
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
// 獲取認證邏輯
ApiAuthenticator apiAuthenticator = getApiAuthenticator(rawPath);
AuthenticatorResult authenticatorResult = apiAuthenticator.auth(exchange);
if (!authenticatorResult.isResult()) {
return Mono.error(new HttpServerErrorException(
HttpStatus.METHOD_NOT_ALLOWED, authenticatorResult.getMessage()));
}
return chain.filter(exchange);
}
/**
* 確定認證策略
* @param rawPath 請求路徑
*/
private ApiAuthenticator getApiAuthenticator(String rawPath) {
String[] parts = rawPath.split("/");
if (parts.length >= 4) {
String parameter = parts[3];
return switch (parameter) {
case PROTECT_PATH -> new ProtectedApiAuthenticator();
case PRIVATE_PATH -> new PrivateApiAuthenticator();
case PUBLIC_PATH -> new PublicApiAuthenticator();
case DEFAULT_PATH -> new DefaultApiAuthenticator();
default -> throw new IllegalStateException("Unexpected value: " + parameter);
};
}
return new DefaultApiAuthenticator();
}
}上面提到過，不同類型的服務其接口認證不一樣，為了便于區分，可以規定對于外部請求都增加一個特定的請求前綴 /pt/，如 apigw.xxx.com/order-service/api/pt/creadeOrder。這樣在過濾器內部就需要通過 getApiAuthenticator() 方法確定認證邏輯。
3.3 接口安全認證
正如上文所說，服務端獲取到請求參數以后需要檢查請求時間是否過期，nonce是否已經被使用，簽名是否正確。
圖片
按照這個邏輯我們很容易在ProtectedApiAuthenticator認證器中寫出這樣的代碼。
@Slf4j
public class ProtectedApiAuthenticator implements ApiAuthenticator {
@Override
public AuthenticatorResult auth(ServerWebExchange exchange) {
// 1. 校驗參數
boolean checked = preAuthenticationCheck(requestHeader);
if (!checked) {
return new AuthenticatorResult(false, "請攜帶正確參數訪問");
}
// 2 . 重放校驗
// 判斷timestamp時間戳與當前時間是否操過60s（過期時間根據業務情況設置）,如果超過了就提示簽名過期。
long now = System.currentTimeMillis() ;
if (now - Long.parseLong(requestHeader.getTimestamp()) > 60000) {
return new AuthenticatorResult(false, "請求超時，請重新訪問");
}
// 3. 判斷nonce
boolean nonceExists = distributedCache.hasKey(NONCE_KEY + requestHeader.getNonce());
if (nonceExists) {
return new AuthenticatorResult(false, "請勿重復提交請求");
} else {
distributedCache.put(NONCE_KEY + requestHeader.getNonce(), requestHeader.getNonce(), 60000);
}
// 4. 簽名校驗
SortedMap<String, Object> requestBody = CachedRequestUtil.resolveFromBody(exchange);
String sign = buildSign(requestHeader,requestBody);
if(!sign.equals(requestHeader.getSign())){
return new AuthenticatorResult(false, "簽名錯誤");
}
return new AuthenticatorResult(true, "");
}這樣的寫法雖然能夠完成校驗邏輯，但稍顯不夠優雅。在這種場景中，使用設計模式中的責任鏈模式是非常合適的選擇。通過責任鏈模式，將校驗邏輯分解為多個責任鏈節點，每個節點專注于一個方面的校驗，使得代碼更加清晰和易于維護。
責任鏈模式已經在我星球設計模式專欄中有詳細介紹與說明，這里就不再贅述了~
@Slf4j
public class ProtectedApiAuthenticator implements ApiAuthenticator {
@Override
public AuthenticatorResult auth(ServerWebExchange exchange) {
...
//構建校驗對象
ProtectedRequest protectedRequest = ProtectedRequest.builder()
.requestHeader(requestHeader)
.requestBody(requestBody)
.build();
//責任鏈上下文
SecurityVerificationChain securityVerificationChain = SpringBeanUtils.getInstance().getBean(SecurityVerificationChain.class);
return securityVerificationChain.handler(protectedRequest);
}
}3.4 基于責任鏈的認證實現
圖片
3.4.1 創建責任鏈的認證接口
public interface SecurityVerificationHandler extends Ordered {
/**
* 請求校驗
*/
AuthenticatorResult handler(ProtectedRequest protectedRequest);
}3.4.2 實現參數校驗邏輯
@Component
public class RequestParamVerificationHandler implements SecurityVerificationHandler {
@Override
public AuthenticatorResult handler(ProtectedRequest protectedRequest) {
boolean checked = checkedHeader(protectedRequest.getRequestHeader());
if(!checked){
return new AuthenticatorResult(false,"請攜帶正確的請求參數");
}
return new AuthenticatorResult(true,"");
}
private boolean checkedHeader(RequestHeader requestHeader) {
return Objects.nonNull(requestHeader.getAppId()) &&
Objects.nonNull(requestHeader.getSign()) &&
Objects.nonNull(requestHeader.getNonce()) &&
Objects.nonNull(requestHeader.getTimestamp());
}
@Override
public int getOrder() {
return 1;
}
}3.4.3 實現nonce的校驗
@Component
public class NonceVerificationHandler implements SecurityVerificationHandler {
private static final String NONCE_KEY = "x-nonce-";
@Value("${dailymart.sign.timeout:60000}")
private long expireTime ;
@Resource
private DistributedCache distributedCache;
@Override
public AuthenticatorResult handler(ProtectedRequest protectedRequest) {
String nonce = protectedRequest.getRequestHeader().getNonce();
boolean nonceExists = distributedCache.hasKey(NONCE_KEY + nonce);
if (nonceExists) {
return new AuthenticatorResult(false, "請勿重復提交請求");
} else {
distributedCache.put(NONCE_KEY + nonce, nonce, expireTime);
return new AuthenticatorResult(true, "");
}
}
@Override
public int getOrder() {
return 3;
}
}3.4.4 實現簽名認證
@Component
@Slf4j
public class SignatureVerificationHandler implements SecurityVerificationHandler {
@Override
public AuthenticatorResult handler(ProtectedRequest protectedRequest) {
//1. 服務端按照規則重新簽名
String serverSign = sign(protectedRequest);
log.info("服務端簽名結果: {}", serverSign);
String clientSign = protectedRequest.getRequestHeader().getSign();
// 2、獲取客戶端傳遞的簽名
log.info("客戶端簽名: {}", clientSign);
if (!Objects.equals(serverSign,clientSign)) {
return new AuthenticatorResult(false, "請求簽名無效");
}
return new AuthenticatorResult(true, "");
}
/**
* 服務端重建簽名
* @param protectedRequest 請求體
* @return 簽名結果
*/
private String sign(ProtectedRequest protectedRequest) {
RequestHeader requestHeader = protectedRequest.getRequestHeader();
String appId = requestHeader.getAppId();
String appSecret = getAppSecret(appId);
// 1、 按照規則對數據進行簽名
SortedMap<String, Object> requestBody = protectedRequest.getRequestBody();
requestBody.put("app_id",appId);
requestBody.put("nonce_number",requestHeader.getNonce());
requestBody.put("request_time",requestHeader.getTimestamp());
StringBuilder signBuilder = new StringBuilder();
for (Map.Entry<String, Object> entry : requestBody.entrySet()) {
signBuilder.append(entry.getKey()).append("=").append(entry.getValue()).append("&");
}
signBuilder.append("appSecret=").append(appSecret);
return DigestUtils.md5DigestAsHex(signBuilder.toString().getBytes()).toUpperCase();
}
@Override
public int getOrder() {
return 4;
}
}3.4.5 責任鏈上下文
@Component
@Slf4j
public class SecurityVerificationChain {
@Resource
private List<SecurityVerificationHandler> securityVerificationHandlers;
public AuthenticatorResult handler(ProtectedRequest protectedRequest){
AuthenticatorResult authenticatorResult = new AuthenticatorResult(true,"");
for (SecurityVerificationHandler securityVerificationHandler : securityVerificationHandlers) {
AuthenticatorResult result = securityVerificationHandler.handler(protectedRequest);
// 有一個校驗不通過理解返回
if(!result.isResult()){
return result;
}
}
return authenticatorResult;
}
}組合所有的校驗邏輯，任意一個校驗邏輯不通過則直接返回。
小結
在本文中，我們深入研究了微服務架構中對外開放接口的安全性保障機制。我們著重關注了那些暴露在外網的API接口面臨的兩個關鍵安全問題：篡改和重放。為了應對篡改問題，我們引入了雙重手段：采用HTTPS進行加密傳輸，并結合接口參數簽名驗證，以確保數據傳輸的完整性和安全性。對于重放問題，我們采納了基于nonce和timestamp的方案，以保證請求的唯一性和有效性。
在具體的代碼實現中，我們不僅考慮了文章中提到的安全認證邏輯，還充分考慮了其他可能的校驗規則。為了更好地組織和管理這些校驗規則，我們將它們拆分成獨立的模塊，根據請求路徑動態選擇相應的接口校驗器。在第三方接口校驗邏輯中，我們通過責任鏈的設計模式實現了具體的校驗規則，使得代碼邏輯更為模塊化和可擴展。這樣的結構不僅使得每個校驗步驟聚焦于特定的安全性驗證，而且提供了良好的可維護性和可擴展性。
最后給大家一個小建議：對外提供的接口協議盡量簡單，不要使用Restful接口風格，全部使用post+json或post+form風格的接口協議即可，這樣對客戶端和服務端都方便。
