摘要:移動應用開發過程中請求服務端采用在計算機身份認證中是令牌臨時方式請求方式進行,請求方式下直接暴露在請求路徑很容易被別人利用進行篡改進行重復提交等,怎樣保證移動端安全成為后臺開發者所面臨的問題,因為涉及敏感行業數據接口開發過程中安全性成為要求
移動應用開發過程中請求服務端采用token(在計算機身份認證中是令牌(臨時))方式請求方式進行,get請求方式下token直接暴露在請求路徑很容易被別人利用進行篡改進行重復提交等,怎樣保證移動端安全成為后臺開發者所面臨的問題,,因為涉及敏感行業數據APP接口開發過程中安全性成為要求,在網上看了很多資料最后選擇采用token+time+nonce+sign方式在過濾器層進行校驗,APP進行拼接加密,后端Filter進行解密校驗,優點實現簡單,能夠很好保證請求過程中APP端到服務器端安全性,因此此種校驗方式被很多互聯網公司所采用。
一、技術實現原理:token: token為用戶登錄時獲取的臨時令牌
time: APP獲取到的當前時間,形式為long類型,time時間可進行匹配APP獲取時間和服務器時間差如果大于某個時間則失效(如鏈接超過60秒失效,具體可參考源碼),可防止別人截取數據后修改數據內容進行提交
nonce:APP接口通過UUID等形式獲取的隨機不重復內容,可以講nonce存放在session或redis中并設置合適的超時時間,然后下次請求時通過nonce取session或redis中是否存在,如果存在則認為重復提交請求,防止被別人篡改后提交數據
sign: 通過token+time+nonce三個參數加密后的密文(sign加密可使用使用ase,md5等加密方式,需要注意md5加密不可逆,實現過程有所區別),sign主要校驗token、time、nonce有沒有被別人篡改數據
1在過濾層實現SecurityFilter類 public class SecurityFilter extends Filter { private static String secretKey = ApplicationConfig.secretKey; private static String ivParameter = ApplicationConfig.ivParameter ; // 本文采用ase加密 將加密secretKey及ivParameter 的保存在properties文件中,使用公共接口加載,用戶可以選擇其他加密方式 @Override protected void doDestroy() { // TODO Auto-generated method stub } @Override protected void doFilter(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws Throwable { String requestUri = request.getRequestURI(); //登錄接口則直接不適用 if(requestUri.indexOf("applogin")>-1){ chain.doFilter(request, response); } else { MsgEntity msg = new MsgEntity(); // 獲取request的URL,用于判斷該請求是否超時 String time = request.getParameter("time"); // 獲取請求nonce,用于判斷是否用戶重復提交 String nonce = request.getParameter("nonce"); // 獲取token碼,實際傳入token值 String token = request.getParameter("token"); // 獲取sign,通過time,nonce,token合并進行加密后密文,需要注意加密順序,平臺必須與APP一致 String sign = request.getParameter("sign"); // 判斷數據是否存在 if (StringUtils.isEmpty(time) || StringUtils.isEmpty(nonce) || StringUtils.isEmpty(token) || StringUtils.isEmpty(sign)) { msg.setMsg("登錄失敗"); msg.setState(false); HttpRequestUtils.writeResponseJsonString(response, msg); return; } //在實際開發過程中傳入數據發現存在%號無法進行解密,需要進行URLDecoder.decode進行解碼 if (sign.indexOf("%") > -1) { sign = URLDecoder.decode(sign, "UTF-8"); } // 判斷請求是否超過60秒,超過60秒則次請求鏈接失效,返回登錄失敗,可根據網絡情況適當延長或者縮短時間 if (difference(time) > 60) { msg.setMsg("登錄失敗"); msg.setState(false); HttpRequestUtils.writeResponseJsonString(response, msg); return; } // 判斷是否是重復請求,如果請求nonce存在則登錄失敗,不存在則將nonce存在redis中或session中并設置合適超時時間 if (JedisUtils.exists(nonce)) { msg.setState(false); msg.setMsg("登錄失敗"); HttpRequestUtils.writeResponseJsonString(response, msg); return; } else { JedisUtils.set(nonce, "0", 70); } // aes 解密,sign和token + time + nonce進行比較判斷數據數據是否存在篡改 String mingwei = ""; try { mingwei = AesUtils.decrypt(sign); } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } if (!mingwei.equals(token + time + nonce)) { msg.setState(false); msg.setMsg("登錄失敗"); HttpRequestUtils.writeResponseJsonString(response, msg); return; } //如果請求全部驗證通過則放行 chain.doFilter(request, response); }三、使用到的工具方法
//主要用于系統時間-APP發送數據時生成日期得到當前差值(秒) public int difference(String past) { long newTimestamp = new Date().getTime(); return Math.abs((int) (newTimestamp - Long.parseLong(past)) / 1000); } } /** * aes 解密 * * @param sSrc * @return * @throws Exception */ public static String decrypt(String sSrc) throws Exception { try { byte[] raw = secretKey.getBytes("ASCII"); SecretKeySpec skeySpec = new SecretKeySpec(raw, "AES"); Cipher cipher = Cipher.getInstance("AES / CBC / PKCS5Padding"); IvParameterSpec iv = new IvParameterSpec(ivParameter.getBytes()); cipher.init(Cipher.DECRYPT_MODE, skeySpec, iv); byte[] encrypted1 = new BASE64Decoder().decodeBuffer(sSrc);// 先用base64解密 byte[] original = cipher.doFinal(encrypted1); String originalString = new String(original, "UTF-8"); return originalString; } catch (Exception ex) { return null; } }
以上為過濾實現token校驗規則代碼,在開發過程中可以參考此代碼進行適當修改進行使用
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/11340.html
摘要:移動應用開發過程中請求服務端采用在計算機身份認證中是令牌臨時方式請求方式進行,請求方式下直接暴露在請求路徑很容易被別人利用進行篡改進行重復提交等,怎樣保證移動端安全成為后臺開發者所面臨的問題,因為涉及敏感行業數據接口開發過程中安全性成為要求 移動應用開發過程中請求服務端采用token(在計算機身份認證中是令牌(臨時))方式請求方式進行,get請求方式下token直接暴露在請求路徑很容易...
摘要:由服務端生成在請求任何接口之前,都必須先請求一個獲取服務器生成的的接口,獲取之后,才請求其他接口是請求時間型號設備號系統類型加密加密頭部存儲基本參數加密校驗參數必須填必須填以下為選填,可有可無,任由開發者自己定義類型設備號版本型號 傳統API與RESTful API 傳統API 獲取用戶信息 get /api/user/read 更新用戶信息 post /api/user/u...
摘要:登錄注冊安全風險登錄注冊的風險點主要有四個暴力破解撞庫遍歷注冊用戶批量注冊。引入了驗證碼機制同樣引入了額外的安全風險,比如短信驗證碼的短信炸彈風險圖形驗證碼的可繞過可識別等。 概述 很多技術研發不了解安全,也不重視安全,只有在自己的服務器被黑掉、被掛馬、被脫褲才想起關注安全,但是這個時候,技術架構已經成型、代碼已經在線上穩定運行,再亡羊補牢,改代碼、改策略,往往成本巨大、確收效很低。所...
摘要:原文地址支付支付步驟為獲取支付寶的配置信息。將得到的數據請求支付寶客戶端進行支付。端將拼接好的字符串拿去請求支付寶客戶端即可調起支付寶進行支付。向支付寶申請新訂單,獲取支付。成功請求回來后,就可以向支付寶發出一次支付請求。 支付寶在所有支付方式中最好開發的了,因為文檔比較清晰,而且開發起來也比較簡單。因此,支付寶的坑是相對較少的。原文地址 APP支付 APP支付步驟為: 獲取支付寶的...
摘要:本文則主要總結了心悅俱樂部的接入層從文本協議到二進制協議迭代過程中的技術方案,包括協議規范安全性等方面的內容。在心悅的文本協議方案中,采用的是對請求數據進行模式的加密。包括明文的協議包頭和密文的二進制流。 歡迎大家前往騰訊云+社區,獲取更多騰訊海量技術實踐干貨哦~。 作者:羅廣鎮 | 騰訊移動開發工程師 App與后臺通信通常有采用json等文本協議或者采用二進制協議,本文則主要總結了心...
閱讀 1481·2021-11-17 09:33
閱讀 1260·2021-10-11 10:59
閱讀 2892·2021-09-30 09:48
閱讀 1905·2021-09-30 09:47
閱讀 3024·2019-08-30 15:55
閱讀 2337·2019-08-30 15:54
閱讀 1493·2019-08-29 15:25
閱讀 1645·2019-08-29 10:57