摘要:移動(dòng)應(yīng)用開發(fā)過程中請(qǐng)求服務(wù)端采用在計(jì)算機(jī)身份認(rèn)證中是令牌臨時(shí)方式請(qǐng)求方式進(jìn)行,請(qǐng)求方式下直接暴露在請(qǐng)求路徑很容易被別人利用進(jìn)行篡改進(jìn)行重復(fù)提交等,怎樣保證移動(dòng)端安全成為后臺(tái)開發(fā)者所面臨的問題,因?yàn)樯婕懊舾行袠I(yè)數(shù)據(jù)接口開發(fā)過程中安全性成為要求
移動(dòng)應(yīng)用開發(fā)過程中請(qǐng)求服務(wù)端采用token(在計(jì)算機(jī)身份認(rèn)證中是令牌(臨時(shí)))方式請(qǐng)求方式進(jìn)行,get請(qǐng)求方式下token直接暴露在請(qǐng)求路徑很容易被別人利用進(jìn)行篡改進(jìn)行重復(fù)提交等,怎樣保證移動(dòng)端安全成為后臺(tái)開發(fā)者所面臨的問題,,因?yàn)樯婕懊舾行袠I(yè)數(shù)據(jù)APP接口開發(fā)過程中安全性成為要求,在網(wǎng)上看了很多資料最后選擇采用token+time+nonce+sign方式在過濾器層進(jìn)行校驗(yàn),APP進(jìn)行拼接加密,后端Filter進(jìn)行解密校驗(yàn),優(yōu)點(diǎn)實(shí)現(xiàn)簡(jiǎn)單,能夠很好保證請(qǐng)求過程中APP端到服務(wù)器端安全性,因此此種校驗(yàn)方式被很多互聯(lián)網(wǎng)公司所采用。
一、技術(shù)實(shí)現(xiàn)原理:token: token為用戶登錄時(shí)獲取的臨時(shí)令牌
time: APP獲取到的當(dāng)前時(shí)間,形式為long類型,time時(shí)間可進(jìn)行匹配APP獲取時(shí)間和服務(wù)器時(shí)間差如果大于某個(gè)時(shí)間則失效(如鏈接超過60秒失效,具體可參考源碼),可防止別人截取數(shù)據(jù)后修改數(shù)據(jù)內(nèi)容進(jìn)行提交
nonce:APP接口通過UUID等形式獲取的隨機(jī)不重復(fù)內(nèi)容,可以講nonce存放在session或redis中并設(shè)置合適的超時(shí)時(shí)間,然后下次請(qǐng)求時(shí)通過nonce取session或redis中是否存在,如果存在則認(rèn)為重復(fù)提交請(qǐng)求,防止被別人篡改后提交數(shù)據(jù)
sign: 通過token+time+nonce三個(gè)參數(shù)加密后的密文(sign加密可使用使用ase,md5等加密方式,需要注意md5加密不可逆,實(shí)現(xiàn)過程有所區(qū)別),sign主要校驗(yàn)token、time、nonce有沒有被別人篡改數(shù)據(jù)
1在過濾層實(shí)現(xiàn)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,用于判斷該請(qǐng)求是否超時(shí) String time = request.getParameter("time"); // 獲取請(qǐng)求nonce,用于判斷是否用戶重復(fù)提交 String nonce = request.getParameter("nonce"); // 獲取token碼,實(shí)際傳入token值 String token = request.getParameter("token"); // 獲取sign,通過time,nonce,token合并進(jìn)行加密后密文,需要注意加密順序,平臺(tái)必須與APP一致 String sign = request.getParameter("sign"); // 判斷數(shù)據(jù)是否存在 if (StringUtils.isEmpty(time) || StringUtils.isEmpty(nonce) || StringUtils.isEmpty(token) || StringUtils.isEmpty(sign)) { msg.setMsg("登錄失敗"); msg.setState(false); HttpRequestUtils.writeResponseJsonString(response, msg); return; } //在實(shí)際開發(fā)過程中傳入數(shù)據(jù)發(fā)現(xiàn)存在%號(hào)無法進(jìn)行解密,需要進(jìn)行URLDecoder.decode進(jìn)行解碼 if (sign.indexOf("%") > -1) { sign = URLDecoder.decode(sign, "UTF-8"); } // 判斷請(qǐng)求是否超過60秒,超過60秒則次請(qǐng)求鏈接失效,返回登錄失敗,可根據(jù)網(wǎng)絡(luò)情況適當(dāng)延長(zhǎng)或者縮短時(shí)間 if (difference(time) > 60) { msg.setMsg("登錄失敗"); msg.setState(false); HttpRequestUtils.writeResponseJsonString(response, msg); return; } // 判斷是否是重復(fù)請(qǐng)求,如果請(qǐng)求nonce存在則登錄失敗,不存在則將nonce存在redis中或session中并設(shè)置合適超時(shí)時(shí)間 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進(jìn)行比較判斷數(shù)據(jù)數(shù)據(jù)是否存在篡改 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; } //如果請(qǐng)求全部驗(yàn)證通過則放行 chain.doFilter(request, response); }三、使用到的工具方法
//主要用于系統(tǒng)時(shí)間-APP發(fā)送數(shù)據(jù)時(shí)生成日期得到當(dāng)前差值(秒) 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; } }
以上為過濾實(shí)現(xiàn)token校驗(yàn)規(guī)則代碼,在開發(fā)過程中可以參考此代碼進(jìn)行適當(dāng)修改進(jìn)行使用
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://www.ezyhdfw.cn/yun/11340.html
摘要:移動(dòng)應(yīng)用開發(fā)過程中請(qǐng)求服務(wù)端采用在計(jì)算機(jī)身份認(rèn)證中是令牌臨時(shí)方式請(qǐng)求方式進(jìn)行,請(qǐng)求方式下直接暴露在請(qǐng)求路徑很容易被別人利用進(jìn)行篡改進(jìn)行重復(fù)提交等,怎樣保證移動(dòng)端安全成為后臺(tái)開發(fā)者所面臨的問題,因?yàn)樯婕懊舾行袠I(yè)數(shù)據(jù)接口開發(fā)過程中安全性成為要求 移動(dòng)應(yīng)用開發(fā)過程中請(qǐng)求服務(wù)端采用token(在計(jì)算機(jī)身份認(rèn)證中是令牌(臨時(shí)))方式請(qǐng)求方式進(jìn)行,get請(qǐng)求方式下token直接暴露在請(qǐng)求路徑很容易...
摘要:由服務(wù)端生成在請(qǐng)求任何接口之前,都必須先請(qǐng)求一個(gè)獲取服務(wù)器生成的的接口,獲取之后,才請(qǐng)求其他接口是請(qǐng)求時(shí)間型號(hào)設(shè)備號(hào)系統(tǒng)類型加密加密頭部存儲(chǔ)基本參數(shù)加密校驗(yàn)參數(shù)必須填必須填以下為選填,可有可無,任由開發(fā)者自己定義類型設(shè)備號(hào)版本型號(hào) 傳統(tǒng)API與RESTful API 傳統(tǒng)API 獲取用戶信息 get /api/user/read 更新用戶信息 post /api/user/u...
摘要:登錄注冊(cè)安全風(fēng)險(xiǎn)登錄注冊(cè)的風(fēng)險(xiǎn)點(diǎn)主要有四個(gè)暴力破解撞庫(kù)遍歷注冊(cè)用戶批量注冊(cè)。引入了驗(yàn)證碼機(jī)制同樣引入了額外的安全風(fēng)險(xiǎn),比如短信驗(yàn)證碼的短信炸彈風(fēng)險(xiǎn)圖形驗(yàn)證碼的可繞過可識(shí)別等。 概述 很多技術(shù)研發(fā)不了解安全,也不重視安全,只有在自己的服務(wù)器被黑掉、被掛馬、被脫褲才想起關(guān)注安全,但是這個(gè)時(shí)候,技術(shù)架構(gòu)已經(jīng)成型、代碼已經(jīng)在線上穩(wěn)定運(yùn)行,再亡羊補(bǔ)牢,改代碼、改策略,往往成本巨大、確收效很低。所...
摘要:原文地址支付支付步驟為獲取支付寶的配置信息。將得到的數(shù)據(jù)請(qǐng)求支付寶客戶端進(jìn)行支付。端將拼接好的字符串拿去請(qǐng)求支付寶客戶端即可調(diào)起支付寶進(jìn)行支付。向支付寶申請(qǐng)新訂單,獲取支付。成功請(qǐng)求回來后,就可以向支付寶發(fā)出一次支付請(qǐng)求。 支付寶在所有支付方式中最好開發(fā)的了,因?yàn)槲臋n比較清晰,而且開發(fā)起來也比較簡(jiǎn)單。因此,支付寶的坑是相對(duì)較少的。原文地址 APP支付 APP支付步驟為: 獲取支付寶的...
摘要:本文則主要總結(jié)了心悅俱樂部的接入層從文本協(xié)議到二進(jìn)制協(xié)議迭代過程中的技術(shù)方案,包括協(xié)議規(guī)范安全性等方面的內(nèi)容。在心悅的文本協(xié)議方案中,采用的是對(duì)請(qǐng)求數(shù)據(jù)進(jìn)行模式的加密。包括明文的協(xié)議包頭和密文的二進(jìn)制流。 歡迎大家前往騰訊云+社區(qū),獲取更多騰訊海量技術(shù)實(shí)踐干貨哦~。 作者:羅廣鎮(zhèn) | 騰訊移動(dòng)開發(fā)工程師 App與后臺(tái)通信通常有采用json等文本協(xié)議或者采用二進(jìn)制協(xié)議,本文則主要總結(jié)了心...
閱讀 1618·2021-11-17 09:33
閱讀 1328·2021-10-11 10:59
閱讀 2970·2021-09-30 09:48
閱讀 1972·2021-09-30 09:47
閱讀 3095·2019-08-30 15:55
閱讀 2397·2019-08-30 15:54
閱讀 1549·2019-08-29 15:25
閱讀 1709·2019-08-29 10:57