傳統(tǒng)進(jìn)行防釣魚的措施有3種：白名單校驗(yàn)， 時(shí)間戳校驗(yàn)， IP檢查

1. 白名單檢查
商戶調(diào)用支付公司系統(tǒng)，其http請(qǐng)求的Referer字段應(yīng)該是支付公司合作伙伴的某個(gè)URL鏈接。支付公司會(huì)收集合作伙伴的網(wǎng)站域名做成一個(gè)集合叫做“白名單”
邏輯：
1、refer為空，交易直接失敗。
2、refer不為空，refer域名不屬于白名單列表時(shí)，失敗交易
2. 時(shí)間戳檢查
商戶在發(fā)出http請(qǐng)求前先調(diào)用支付公司提供的一個(gè)接口來拿到支付公司服務(wù)器上的當(dāng)前時(shí)間T1，把時(shí)間T1作為支付請(qǐng)求鏈接的一個(gè)參數(shù)加在url中傳遞給支付公司服務(wù)器，支付公司服務(wù)器接收到請(qǐng)求后先取出url中的時(shí)間參數(shù)T1，然后再取一下支付寶服務(wù)器當(dāng)前的系統(tǒng)時(shí)間T2，計(jì)算兩個(gè)時(shí)間的間隔，如果時(shí)間差超過一定范圍，則時(shí)間戳檢查失敗，拒絕服務(wù)，可以跳轉(zhuǎn)到error頁(yè)面。時(shí)間間隔的設(shè)定默認(rèn)是60秒，可以根據(jù)配置靈活的調(diào)整
3. IP檢查
商戶首先在商戶平臺(tái)內(nèi)獲取用戶客戶端的IP地址，然后將該IP地址作為支付接口的參數(shù)加到URL中。支付公司服務(wù)器在接受到支付請(qǐng)求后先取出URL中的IP值，然后再重新獲取當(dāng)前操作用戶的客戶端IP地址，比對(duì)兩者是否一致，如果不一致，則IP檢查失敗，然后提醒風(fēng)險(xiǎn)（這里是提示風(fēng)險(xiǎn)，由用戶決定是否下一步操作，因?yàn)镮P可能獲取不同，比如某公司有雙網(wǎng)絡(luò)出口）

?

Basic認(rèn)證及其安全問題

Basic認(rèn)證是一個(gè)流程比較簡(jiǎn)單的協(xié)議，整個(gè)過程可以分為以下三個(gè)步驟：

a）?客戶端使用GET方法向服務(wù)器請(qǐng)求資源。

b）?服務(wù)器返回401響應(yīng)碼和WWW-Authentication：Basic realm=”Family”響應(yīng)頭要求客戶端進(jìn)行身份驗(yàn)證。其中realm聲明了資源所在的域。

c）?瀏覽器接收到以上HTTP響應(yīng)頭后，彈出登錄框要求用戶輸入用戶名和密碼；用戶提交的用戶名和密碼通過冒號(hào)串聯(lián)起來并對(duì)其進(jìn)行BASE64編碼后再提交到服務(wù)器；服務(wù)器對(duì)提交上來的BASE64字符串進(jìn)行驗(yàn)證，如果驗(yàn)證通過則返回200響應(yīng)碼。

Basic認(rèn)證雖然簡(jiǎn)單、方便，但它只能作為對(duì)非敏感資源的訪問認(rèn)證，因?yàn)樗⒉话踩?#xff0c;主要表現(xiàn)在以下幾個(gè)方面：

1、?客戶端提交的用戶名和密碼只經(jīng)過簡(jiǎn)單的編碼，攻擊者只要竊聽到該數(shù)據(jù)包，便可很容易的將其反編碼為原始用戶名和密碼。

2、?即使客戶端使用了一種比BASE64更復(fù)雜的編碼方式使得攻擊者無法對(duì)其反編碼，攻擊者也可以使用fiddler等工具將攔截到的HTTP報(bào)文重新提交給服務(wù)器，服務(wù)器只對(duì)編碼的字符串進(jìn)行驗(yàn)證，所以驗(yàn)證同樣能通過。這種攻擊方法稱之為重放攻擊（Replay-Attack）。

以上兩個(gè)問題也是各種身份認(rèn)證協(xié)議需要考慮到的安全問題，包括OAuth、Digest認(rèn)證、NTLM認(rèn)證等等認(rèn)證機(jī)制都使用了nonce和timestamp來解決這些問題。

?

Nonce、Timestamp——解決Replay-Attack問題

Nonce是由服務(wù)器生成的一個(gè)隨機(jī)數(shù)，在客戶端第一次請(qǐng)求頁(yè)面時(shí)將其發(fā)回客戶端；客戶端拿到這個(gè)Nonce，將其與用戶密碼串聯(lián)在一起并進(jìn)行非可逆加密（MD5、SHA1等等），然后將這個(gè)加密后的字符串和用戶名、Nonce、加密算法名稱一起發(fā)回服務(wù)器；服務(wù)器使用接收到的用戶名到數(shù)據(jù)庫(kù)搜索密碼，然后跟客戶端使用同樣的算法對(duì)其進(jìn)行加密，接著將其與客戶端提交上來的加密字符串進(jìn)行比較，如果兩個(gè)字符串一致就表示用戶身份有效。這樣就解決了用戶密碼明文被竊取的問題，攻擊者就算知道了算法名和nonce也無法解密出密碼。?

每個(gè)nonce只能供一個(gè)用戶使用一次，這樣就可以防止攻擊者使用重放攻擊，因?yàn)樵揌ttp報(bào)文已經(jīng)無效。可選的實(shí)現(xiàn)方式是把每一次請(qǐng)求的Nonce保存到數(shù)據(jù)庫(kù)，客戶端再一次提交請(qǐng)求時(shí)將請(qǐng)求頭中得Nonce與數(shù)據(jù)庫(kù)中得數(shù)據(jù)作比較，如果已存在該Nonce，則證明該請(qǐng)求有可能是惡意的。然而這種解決方案也有個(gè)問題，很有可能在兩次正常的資源請(qǐng)求中，產(chǎn)生的隨機(jī)數(shù)是一樣的，這樣就造成正常的請(qǐng)求也被當(dāng)成了攻擊，隨著數(shù)據(jù)庫(kù)中保存的隨機(jī)數(shù)不斷增多，這個(gè)問題就會(huì)變得很明顯。所以，還需要加上另外一個(gè)參數(shù)Timestamp（時(shí)間戳）。?

Timestamp是根據(jù)服務(wù)器當(dāng)前時(shí)間生成的一個(gè)字符串，與nonce放在一起，可以表示服務(wù)器在某個(gè)時(shí)間點(diǎn)生成的隨機(jī)數(shù)。這樣就算生成的隨機(jī)數(shù)相同，但因?yàn)樗鼈兩傻臅r(shí)間點(diǎn)不一樣，所以也算有效的隨機(jī)數(shù)。?

問題又來了，隨著用戶訪問的增加，數(shù)據(jù)庫(kù)中保存的nonce/timestamp/username數(shù)據(jù)量會(huì)變得非常大。對(duì)于這個(gè)問題，可選的解決方案是對(duì)數(shù)據(jù)設(shè)定一個(gè)“過期時(shí)間”，比如說在數(shù)據(jù)庫(kù)中保存超過一天的數(shù)據(jù)將會(huì)被清除。如果是這樣的，攻擊者可以等待一天后，再將攔截到的HTTP報(bào)文提交到服務(wù)器，這時(shí)候因?yàn)閚once/timestamp/username數(shù)據(jù)已被服務(wù)器清除，請(qǐng)求將會(huì)被認(rèn)為是有效的。要解決這個(gè)問題，就需要給時(shí)間戳設(shè)置一個(gè)超時(shí)時(shí)間，比如說將時(shí)間戳與服務(wù)器當(dāng)前時(shí)間比較，如果相差一天則認(rèn)為該時(shí)間戳是無效的。

?

HTTPS消息體的加密

?????????很不幸的是，經(jīng)過上面這些復(fù)雜的處理后，我們的數(shù)據(jù)傳輸仍然是不安全的。我們都知道，http報(bào)文是以明文的方式在網(wǎng)絡(luò)中傳輸?shù)?#xff0c;包括Basic認(rèn)證、Digest認(rèn)證、OAuth、NTLM等等驗(yàn)證這一些認(rèn)證機(jī)制都只是對(duì)HTTP頭的信息作保護(hù)，而對(duì)于Http消息體的數(shù)據(jù)卻沒有作加密。以新浪首頁(yè)的登錄為例，它的賬號(hào)就是以明文的方式傳送的，

這樣的方式是很不安全的，用戶名和密碼完全以明文的方式提交了。同樣是新浪的網(wǎng)站——新浪微博就在登錄前作了加密過的，加密的方法可以參考前面講到的nonce+timestamp的方案。不過這只解決了登錄的問題，在注冊(cè)時(shí)就不能提交使用nonce和timestamp非可逆加密了，這個(gè)時(shí)候要使用非對(duì)稱加密。在用戶打開注冊(cè)頁(yè)時(shí)，服務(wù)器生成一個(gè)公鑰/私鑰對(duì)并將公鑰返回給客戶端，客戶端使用該公鑰將密碼加密后提交到服務(wù)器，服務(wù)器使用私鑰解密后再保存到數(shù)據(jù)庫(kù)。非對(duì)稱加密算法的特點(diǎn)是每一個(gè)公鑰和私鑰都是一一對(duì)應(yīng)的，使用公鑰加密后只有擁有私鑰的人才能進(jìn)行解密，所以攻擊者截取到http報(bào)文也毫無用處。

?????????當(dāng)然，在條件允許的情況下，可以使用SSL來實(shí)現(xiàn)HTTP報(bào)文的加密，這種方案是在應(yīng)用層和傳輸層中間添加一個(gè)SSL層，該層使用對(duì)稱加密的方法將HTTP報(bào)文加密后再傳遞到傳輸層，

在這之前，客戶端與服務(wù)器需要使用非對(duì)稱加密的方法來協(xié)商用于對(duì)稱加密的公鑰，對(duì)稱加密要求加密者和解密者擁有同一個(gè)密鑰（即公鑰）。當(dāng)客戶端首次訪問頁(yè)面時(shí)，需要生成一個(gè)公鑰給服務(wù)器，而這個(gè)公鑰不是不可以給第三方知道的（知道了這個(gè)公鑰就可對(duì)數(shù)據(jù)進(jìn)行解密了），所以需要服務(wù)器首先生成一個(gè)公鑰/密鑰對(duì)，并使用生成的公鑰加密客戶端生成的公鑰（非對(duì)稱加密），這一個(gè)過程與前面講到的注冊(cè)密碼加密的方式類似。

正因?yàn)樵谡綌?shù)據(jù)傳輸之前需要在服務(wù)器跟客戶端之間進(jìn)行幾輪的協(xié)商，所以HTTPS相比HTTP來說安全性會(huì)高些、而性能會(huì)差些。

轉(zhuǎn)載于:https://www.cnblogs.com/taiyonghai/p/5760716.html

與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的支付接口 随机串 时间戳 防钓鱼效验方式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。