只列舉一種安全性較高的思路且走HTTP
1: 客戶端登錄，服務端返回api-key和securekey。 ----> api-key一般與用戶id關聯唯一性，同時自定義生成securekey放入緩存中且返回給客戶端（客戶端需保存）
2: 客戶端發起請求，參數包括：
1)
api-key 2)
請求參數 3)
時間戳， 這個參數的目的是防止請求被人攔截模擬再次發送，也即過濾使用相同的連接和參數進行重復請求
4)
請求參數的sign簽名(就是把參數和參數值，結合securekey、時間戳進行加密且返回全大寫的字符串，實際傳輸中并不傳遞securekey) -->加密方式需和服務端協商保持一致
示例: GET請求鏈接: http://192.168.1.22:8080/v1/info/list?apiKey=api-key&id=2&name=xx&sign=EFSDKJXNDSF×tamp=15909090213989
3：服務端接收后：
1) 根據api-key獲取securekey取得參數；這里可判斷securekey的失效時間，若失效，直接攔截請求提示用戶重新登錄。
2) 根據時間戳與當前服務端時間比較，可自定義判斷，比如大于2分鐘就判斷是惡意重復請求，直接攔截不進入業務處理，若在2分鐘內，表示可以重復發起相同的請求。
3) 按照客戶端的請求參數結合securekey、時間戳進行加密(方式與客戶端一致) 。
4) 然后與sign簽名進行比較，如果一致，表示是安全的用戶請求，如果不一致，表示被攔截那么禁止進入業務。
時間戳的再次說明：時間戳的目的就是如果被人惡意攔截模擬重復發起請求，比如上面的完整GET請求鏈接，這里被攔截后只能進行惡意的重復請求。因為若修改參數在發送，那么服務端根據參數加密生成的簽名肯定與客戶端簽名不一致，是無法通過認證的，只能利用原有參數重復發送，那么時間戳就能保護系統不被惡意大量的重復攻擊。服務端獲取時間戳可加入判斷規則，與當前系統時間比較，若大于多少分鐘，就判定為重復請求，進行攔截，若小于多少分鐘，那么仍然可以請求。
完！
posted on 2018-01-19 16:04
朔望魔刃 閱讀(430)
評論(0) 編輯 收藏 所屬分類:
java