眾所周知，APP都是基于介面傳輸資料的，因為它的原始碼不可得，反編譯。所以在APP客戶端保存一個秘鑰，然后呼叫后臺介面時，將秘鑰和post的欄位一起加密作為sign傳給后臺，秘鑰本身不傳的。
后臺根據APP傳的欄位和之前約定好的秘鑰加密，比對sign是否一致，從而保證資料一致性。
那么問題來了，在h5網頁上，加密方法所有原始碼都是可見。都能被抓包篡改，如何保證資料安全。HTTPS可以解決，但費用貴。
另外有人說在header里面放token，都是可見的照樣改，或者每次請求后臺動態獲得秘鑰在參照APP方案簽名，也是可見的。
一般傳統都是后臺加載視圖，只在少數頁面用Ajax從后臺取資料，頁面是后臺輸出的。
如果h5網站完全采用APP一樣前后端分離，介面簽名上，有沒有好的建議。。
uj5u.com熱心網友回復：
用token的話，篡改了沒用，解密驗證都在服務器端完成的，密鑰在服務器端，不涉及到傳遞。token一般只用來做授權驗證。如果是傳遞加密資料的話，可以考慮用對稱加密加密資料，用非對稱加密傳遞對稱加密的密鑰。
客戶端用js動態生成一對密鑰，把客戶端公鑰傳遞給服務器。
服務器端拿客戶端公鑰加密隨機生成的對稱加密密鑰，并把服務器端公鑰傳給客戶端。
客戶端拿自己的私鑰解出對稱加密密鑰，加密資料，然后用服務器端公鑰加密隨機對稱加密密鑰。
服務器端拿自己的私鑰解出對稱加密密鑰，再解出資料。
以上資料可再加非對稱方式的上簽名。
uj5u.com熱心網友回復：
謝謝回復。
登陸后回傳客戶端一個加密的token，客戶端每次發起請求攜帶token，服務器解密token或者從快取或資料庫查找token的資訊，如果沒記錄則授權失敗。token改了沒用，但如果抓包改了其他傳遞的欄位呢，因為其他欄位沒有參與簽名，改沒改后臺無法感知。
第二種方法采用了對稱加密和非對稱加密，增加了篡改的復雜度。參照這邊文章https://blog.csdn.net/qq812858143/article/details/81035497
首先客戶端生成一對客戶端秘鑰，私鑰存入快取，然后請求服務器，服務器生成一對服務端秘鑰，并回傳公鑰，客戶端用服務器的公鑰加密
自己的客戶端公鑰以及登陸資訊 請求服務器，服務器根據服務器私鑰 解密資料 得到 登陸資訊 以及 客戶端公鑰，并用客戶端公鑰加密 aes對稱加密的key值回傳給客戶端。
客戶端再用自己的客戶端私鑰解密資料，得到aes加密的key以及其他token值，然后在簽名。
關鍵就是這里，客戶端的私鑰存在哪里，如果是在快取或本地存盤還是可見的。可以竊取客戶端私鑰，然后解密服務器回傳的值。
如果是介面一次性驗證沒問題，通過介面來回傳遞，不存在存盤。但是token每個介面都要用到，簽名時無法做到防纂改。
所以個人認為，這種方法只適合一次性授權。或者增加纂改抓包的難度。
uj5u.com熱心網友回復：
token 的作用相當于 短期的密碼，如果密碼泄露了，自然啥防護都沒用啊。uj5u.com熱心網友回復：
我們現在做的是，引數加簽名+時間限制，增加破解難度，改引數就要改簽名，時間戳就得跟著改，并且時間戳還要跟向后端發送請求的真實時間戳一致，請求間隔超過1秒就pass掉，這樣的話手動基本無法破解了，因為手動的話1秒絕對做不完這些動作的。演算法啥的無所謂，寫在js里都能看到。沒有絕對的安全，只要被大佬盯上，支付寶也進得去，我們盡可能增加破解難度，把那些小魚小蝦過濾掉就行了，大佬看不上我們的系統。
uj5u.com熱心網友回復：
如果并發上來呢,怎么考慮這些點
uj5u.com熱心網友回復：
如果你要用對稱加密,就不能前后端寫死做加密. 加密的key 要去請求后端,后端給你key 你在加密uj5u.com熱心網友回復：
上面的那個回復 請忽略, 首先你要解決什么問題,你是什么場景 害怕別人看到你的資料uj5u.com熱心網友回復：
如果是你想解決 資料在傳輸程序中不被修改 或者破解,你就只能用https(這表示第三方攔截). 如果只是想用戶不分析你的資料,你只能動態獲取key,但是你都說了 別人都決議到你的原始碼了,其實這個key 也沒什么用.uj5u.com熱心網友回復：
拿java來說JAX-WS和JAX-RS規范的實作都有認證和安全部分的實作.轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/45490.html
標籤：其他
上一篇：用jwt生成token?