傳統進行防釣魚的措施有3種：白名單校驗， 時間戳校驗， IP檢查

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

?

Basic認證及其安全問題

Basic認證是一個流程比較簡單的協議，整個過程可以分為以下三個步驟：

a）?客戶端使用GET方法向服務器請求資源。

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

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

Basic認證雖然簡單、方便，但它只能作為對非敏感資源的訪問認證，因為它并不安全，主要表現在以下幾個方面：

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

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

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

?

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

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

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

Timestamp是根據服務器當前時間生成的一個字符串，與nonce放在一起，可以表示服務器在某個時間點生成的隨機數。這樣就算生成的隨機數相同，但因為它們生成的時間點不一樣，所以也算有效的隨機數。?

問題又來了，隨著用戶訪問的增加，數據庫中保存的nonce/timestamp/username數據量會變得非常大。對于這個問題，可選的解決方案是對數據設定一個“過期時間”，比如說在數據庫中保存超過一天的數據將會被清除。如果是這樣的，攻擊者可以等待一天后，再將攔截到的HTTP報文提交到服務器，這時候因為nonce/timestamp/username數據已被服務器清除，請求將會被認為是有效的。要解決這個問題，就需要給時間戳設置一個超時時間，比如說將時間戳與服務器當前時間比較，如果相差一天則認為該時間戳是無效的。

?

HTTPS消息體的加密

?????????很不幸的是，經過上面這些復雜的處理后，我們的數據傳輸仍然是不安全的。我們都知道，http報文是以明文的方式在網絡中傳輸的，包括Basic認證、Digest認證、OAuth、NTLM等等驗證這一些認證機制都只是對HTTP頭的信息作保護，而對于Http消息體的數據卻沒有作加密。以新浪首頁的登錄為例，它的賬號就是以明文的方式傳送的，

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

?????????當然，在條件允許的情況下，可以使用SSL來實現HTTP報文的加密，這種方案是在應用層和傳輸層中間添加一個SSL層，該層使用對稱加密的方法將HTTP報文加密后再傳遞到傳輸層，

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

正因為在正式數據傳輸之前需要在服務器跟客戶端之間進行幾輪的協商，所以HTTPS相比HTTP來說安全性會高些、而性能會差些。

轉載于:https://www.cnblogs.com/taiyonghai/p/5760716.html

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。