一種針對接口的調用請求的處理方法及裝置的制造方法
【專利摘要】本發(fā)明實施例公開了一種針對接口的調用請求的處理方法及裝置，預先建立針對用戶的黑名單庫和白名單庫；所述方法包括：接收用戶針對目標接口的調用請求，所述調用請求中至少包括請求地址；獲得至少包含用于校驗所述請求地址合法性的參數(shù)的令牌和用于生成針對所述請求地址的地址簽名的第一算法組；根據(jù)所述第一算法組以及所述請求地址，生成針對所述請求地址的第一地址簽名；根據(jù)所述黑名單庫、所述白名單庫、所述令牌和所述第一地址簽名，判斷所述調用請求是否為惡意請求；如果是，攔截所述調用請求。利用本發(fā)明實施例，提高了接口防刷的精確性。
【專利說明】
一種針對接口的調用請求的處理方法及裝置
技術領域
[0001]本發(fā)明涉及接口防刷技術領域，特別涉及一種針對接口的調用請求的處理方法及
目.0
【背景技術】
[0002]互聯(lián)網(wǎng)技術的快速發(fā)展，使得人們更加關注互聯(lián)網(wǎng)信息安全以及互聯(lián)網(wǎng)公司自身的業(yè)務安全。在公司的用戶登錄、注冊、激活碼、活動鏈接等重要業(yè)務領域，安全防刷技術顯得尤為重要。
[0003]現(xiàn)有的接口防刷技術多以異步數(shù)據(jù)分析為基礎，建立黑白名單等方式再應用到接口層防止惡意請求和調用。由于需要積累一定的數(shù)據(jù)基礎，所以對于數(shù)據(jù)基礎不強的接口防刷技術來說，其黑白名單庫中的用戶數(shù)據(jù)基礎不強，容易造成無法識別并攔截惡意請求，從而導致防刷的精確性不高。

【發(fā)明內(nèi)容】

[0004]本發(fā)明實施例的目的在于提供一種針對接口的調用請求的處理方法及裝置，以提高接口防刷的精確性。
[0005]為達到上述目的，本發(fā)明實施例公開了一種針對接口的調用請求的處理方法，預先建立針對用戶的黑名單庫和白名單庫;方法包括:
[0006]接收用戶針對目標接口的調用請求，所述調用請求中至少包括請求地址；
[0007]獲得至少包含用于校驗所述請求地址合法性的參數(shù)的令牌和用于生成針對所述請求地址的地址簽名的第一算法組；
[0008]根據(jù)所述第一算法組以及所述請求地址，生成針對所述請求地址的第一地址簽名；
[0009]根據(jù)所述黑名單庫、所述白名單庫、所述令牌和所述第一地址簽名，判斷所述調用請求是否為惡意請求；
[0010]如果是，攔截所述調用請求。
[0011]較佳的，所述根據(jù)所述黑名單庫、所述令牌和所述第一地址簽名，判斷所述調用請求是否為惡意請求，包括:
[0012]根據(jù)所述黑名單庫，判斷所述黑名單庫中是否存在所述用戶對應的標識信息；
[0013]如果存在，確定所述調用請求為惡意請求；
[0014]如果不存在，根據(jù)所述白名單庫，判斷所述白名單庫中是否存在所述用戶對應的標識信息；
[0015]如果否，根據(jù)所述令牌中包含的參數(shù)，校驗所述請求地址是否合法；
[0016]如果不合法，確定所述調用請求為惡意請求；
[0017]如果合法，根據(jù)所述請求地址、所述令牌包含的用于生成簽名的參數(shù)以及所述第一算法組對應的第二算法組，生成第二地址簽名；
[0018]判斷所述第二地址簽名和所述第一地址簽名是否相同；
[0019]如果不相同，確定所述調用請求為惡意請求。
[0020]較佳的，所述方法還包括:
[0021]在將所述調用請求確定為惡意請求的次數(shù)到達預設第一次數(shù)的情況下，將所述用戶對應的標識信息添加到所述黑名單庫中。
[0022]較佳的，所述方法還包括:
[0023]在將所述調用請求確定為非惡意請求的次數(shù)到達預設第二次數(shù)、且所述白名單庫中不存在所述用戶對應的標識信息的情況下，將所述用戶對應的標識信息添加到所述白名單庫中。
[0024]為達到上述目的，本發(fā)明實施例公開了一種針對接口的調用請求的處理裝置，預先建立針對用戶的黑名單庫和白名單庫;所述裝置包括:
[0025]接收模塊，用于接收用戶針對目標接口的調用請求，所述調用請求中至少包括請求地址；
[0026]獲得模塊，用于獲得至少包含用于校驗所述請求地址合法性的參數(shù)的令牌和用于生成針對所述請求地址的地址簽名的第一算法組；
[0027]生成模塊，用于根據(jù)所述第一算法組以及所述請求地址，生成針對所述請求地址的第一地址簽名；
[0028]判斷模塊，用于根據(jù)所述黑名單庫、所述白名單庫、所述令牌和所述第一地址簽名，判斷所述調用請求是否為惡意請求；
[0029]攔截模塊，用于在判斷所述調用請求為惡意請求的情況下，攔截所述調用請求。
[0030]較佳的，所述判斷裝置，具體用于:
[0031]根據(jù)所述黑名單庫，判斷所述黑名單庫中是否存在所述用戶對應的標識信息；
[0032]如果存在，確定所述調用請求為惡意請求；
[0033]如果不存在，根據(jù)所述白名單庫，判斷所述白名單庫中是否存在所述用戶對應的標識信息；
[0034]如果否，根據(jù)所述令牌中包含的參數(shù)，校驗所述請求地址是否合法；
[0035]如果不合法，確定所述調用請求為惡意請求；
[0036]如果合法，根據(jù)所述請求地址、所述令牌包含的用于生成簽名的參數(shù)以及所述第一算法組對應的第二算法組，生成第二地址簽名；
[0037]判斷所述第二地址簽名和所述第一地址簽名是否相同；
[0038]如果不相同，確定所述調用請求為惡意請求。
[0039]較佳的，所述裝置還包括:
[0040]第一添加模塊，用于在將所述調用請求確定為惡意請求的次數(shù)到達預設第一次數(shù)的情況下，將所述用戶對應的標識信息添加到所述黑名單庫中。
[0041 ]較佳的，所述裝置還包括:
[0042]第二添加模塊，用于在將所述調用請求確定為非惡意請求的次數(shù)到達預設第二次數(shù)、且所述白名單庫中不存在所述用戶對應的標識信息的情況下，將所述用戶對應的標識信息添加到所述白名單庫中。
[0043]由上述的技術方案可見，本發(fā)明實施例提供的一種針對接口的調用請求的處理方法及裝置，預先建立針對用戶的黑名單庫和白名單庫;接收用戶針對目標接口的調用請求，所述調用請求中至少包括請求地址;獲得至少包含用于校驗所述請求地址合法性的參數(shù)的令牌和用于生成針對所述請求地址的地址簽名的第一算法組;根據(jù)所述第一算法組以及所述請求地址，生成針對所述請求地址的第一地址簽名；根據(jù)所述黑名單庫、所述白名單庫、所述令牌和所述第一地址簽名，判斷所述調用請求是否為惡意請求;如果是，攔截所述調用請求。
[0044]可見，在數(shù)據(jù)基礎不強時，在黑白名單庫無法識別并攔截惡意請求的情況下，可以繼續(xù)通過令牌參數(shù)校驗和簽名校驗，快速識別并攔截惡意請求，并且可以將用戶信息添加進黑名單或白名單庫中，從而使得接口防刷更為精準。
[0045]當然，實施本發(fā)明的任一產(chǎn)品或方法必不一定需要同時達到以上所述的所有優(yōu)點。
【附圖說明】
[0046]為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。
[0047]圖1為本發(fā)明實施例提供的一種針對接口的調用請求的處理方法的流程示意圖；
[0048]圖2為本發(fā)明實施例提供的一種針對接口的調用請求的處理裝置的結構示意圖。
【具體實施方式】
[0049]下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。
[0050]下面首先對本發(fā)明實施例提供的一種針對接口的調用請求的處理方法進行詳細說明。
[0051 ]參見圖1，圖1為本發(fā)明實施例提供的一種針對接口的調用請求的處理方法的流程示意圖，預先建立針對用戶的黑名單庫和白名單庫;可以包括如下步驟:
[0052]SlOl，接收用戶針對目標接口的調用請求，所述調用請求中至少包括請求地址；
[0053]具體的，用戶針對目標接口的調用請求可以為人工的調用請求，例如登錄12306網(wǎng)站、注冊微博賬號、獲取激活碼、點擊活動鏈接等等，也可以為“機器”的調用請求，例如軟件發(fā)起的惡意請求、撞庫等等。撞庫是一種針對數(shù)據(jù)庫的攻擊方式，方法是通過攻擊者所擁有的數(shù)據(jù)庫的數(shù)據(jù)，生成對應的字典表，攻擊目標數(shù)據(jù)庫，可以理解為用戶在A網(wǎng)站被盜的賬戶密碼來登陸B(tài)網(wǎng)站。由于很多用戶在不同網(wǎng)站使用的是相同的賬號密碼，因此可以獲取用戶在B網(wǎng)站的用戶賬戶從而達到目的。
[0054]具體的，調用請求中包含有請求地址。請求地址可以為URL地址，例如為:http: //baike.baidu.com/1i n k ? u r I = Q4GDs7P4zNqNSt78J8nnzA9HS5Ue_4xvatd2rzU2CH2XiLZDIbHpyV3IgJ102RMPdpqkXaffHffx7jllsTNjaUTklR_qqDHeAblYcL0tVSPAi ο
[0055]S102，獲得至少包含用于校驗所述請求地址合法性的參數(shù)的令牌和用于生成針對所述請求地址的地址簽名的第一算法組；
[0056]具體的，令牌可以為token，第一算法組可以為JSSDK。前端向后臺服務器請求token以及用于生成URL簽名的JS SDK。通過后臺的算法庫隨機獲取多個簽名算法的排列，得到第一算法組JS SDKdoken中攜帶后臺需要驗證的部分信息，是URL合法性校驗的一部分。算法庫里算法越多，用戶破解難度越大。
[0057]具體的，算法庫主要追求算法數(shù)量，不需要過于復雜的加密算法，也可以節(jié)省機器的CPU消耗。比如不同鹽值的MD5算法，可針對調用請求的各個因素做加密處理，比如接口名，參數(shù)列表等。輸入是整個接口調用請求(URL)的所有信息。算法庫可以包含JS SDK和對應的后端算法。
[0058]S103，根據(jù)所述第一算法組以及所述請求地址，生成針對所述請求地址的第一地址簽名；
[0059]具體的，前端通過JSSDK和請求地址URL生成第一地址簽名，并調用防刷后臺，第一地址簽名以及token作為參數(shù)同時傳到防刷后臺。
[0060]S104，根據(jù)所述黑名單庫、所述白名單庫、所述令牌和所述第一地址簽名，判斷所述調用請求是否為惡意請求；
[0061]具體的，該步驟可以包括:根據(jù)所述黑名單庫，判斷所述黑名單庫中是否存在所述用戶對應的標識信息；如果存在，確定所述調用請求為惡意請求;如果不存在，根據(jù)所述白名單庫，判斷所述白名單庫中是否存在所述用戶對應的標識信息;如果否，根據(jù)所述令牌中包含的參數(shù)，校驗所述請求地址是否合法;如果不合法，確定所述調用請求為惡意請求;如果合法，根據(jù)所述請求地址、所述令牌包含的用于生成簽名的參數(shù)以及所述第一算法組對應的第二算法組，生成第二地址簽名；判斷所述第二地址簽名和所述第一地址簽名是否相同；如果不相同，確定所述調用請求為惡意請求。
[0062]其中，后臺可以根據(jù)用戶是否在黑白名單庫對調用請求做不同處理，比如白名單里的用戶直接代理到業(yè)務接口，黑名單庫用戶直接返回錯誤信息等等。黑白名單庫可以通過例如防刷平臺訪問日志、防刷系統(tǒng)攔截日志以及其他業(yè)務日志等逐步建立與完善，隨著黑白名單庫中數(shù)據(jù)的積累也可以發(fā)揮越來越大的作用。
[0063]其中，可以選取可逆的加密算法生成token。算法可以破解難度較高為好，同時需兼顧服務器CHJ使用問題，例如AES(高級加密標準)加密算法。token里可攜帶接口請求的部分信息，比如時間戳(t ime s tamp)等。
[0064]其中，后端可以通過算法庫中和JS SDK對應的后端算法、token以及URL生成第二地址簽名，判斷校驗前端通過JS SDK生成的第一地址簽名和第二地址簽名是否相同，如果不同，說明調用請求為惡意請求，則會被攔截。例如第二地址簽名為a:0f9de62fce790f9a083d5c99e95740ceb90c27ed，第一地址簽名為 b:0f9de62fce790f9a083d5c99e95740ceb90c06ab，兩者不同，說明前端使用無效的簽名，調用請求為惡意請求，則會被攔截。
[0065]具體的，在實際應用中，在將所述調用請求確定為惡意請求的次數(shù)到達預設第一次數(shù)的情況下，將所述用戶對應的標識信息添加到所述黑名單庫中。其中，第一預設次數(shù)可以為10次。
[0066]具體的，在實際應用中，在將所述調用請求確定為非惡意請求的次數(shù)到達預設第二次數(shù)、且所述白名單庫中不存在所述用戶對應的標識信息的情況下，將所述用戶對應的標識信息添加到所述白名單庫中。其中，第二預設次數(shù)可以為10次。
[0067]S105，如果是，攔截所述調用請求。
[0068]具體的，在判斷調用請求為惡意請求的情況下，防刷后臺可以攔截該調用請求。其中，攔截用戶針對接口的調用請求屬于現(xiàn)有技術，例如可以直接返回錯誤信息等，本發(fā)明實施例在此不對其進行贅述。
[0069]示例性的，防刷后臺可以為安全防刷防盜鏈平臺。其中，安全防刷防盜鏈平臺搭建流程可以為:
[0070]建立算法庫:算法庫主要追求算法數(shù)量，不需要過于復雜的加密算法，也節(jié)省機器的CPU消耗。比如不同鹽值的MD5(信息一摘要算法5)算法，可針對請求的各個因素做加密處理，比如接口名，參數(shù)列表等。輸入是整個接口調用(url請求)的所有信息。算法庫包含JSSDK和對應的后端算法；
[0071]建立反向代理流程:選擇一個反向代理服務器，比如nginx服務器，選擇一個適用于該服務器的語言，比如Iua語言。對所需防刷的接口，可以通過nginx代理，在nginx轉發(fā)之前利用Iua做對應的防刷校驗；
[0072]獲得token:可以選取可逆的加密算法生成token，如AES(Ri jndaeI加密算法)。算法以破解難度較高為好，同時需兼顧服務器CPU的使用問題。token里可攜帶接口請求的部分參數(shù)，比如時間戳等。
[0073]示例性的，在搭建完防刷后臺后，可以使用該后臺進行接口防刷。接口調用請求的防刷流程可以為:
[0074]需要請求的最終接口以及參數(shù)組成URL，防刷服務器域名為C，防刷接口為D。首先客戶端向服務端請求token以及JS SDK，服務端返回的JS SDK將用于客戶端生成URL簽名，token需要客戶端透傳給服務端。可以向服務端請求C/D?url =A&token = token&sign =0f9de62fce790f9a083d5c99e95740ceb90c27ed。服務端先判斷 token 針對當次請求是否有效，比如是否還有時效。如果惡意刷接口的行為多次使用同一個token，這一步可以對惡意請求進行攔截。
[0075]如果客戶端每次請求都使用實時token ,token驗證通過將進行JS SDK校驗。JSSDK可以配合網(wǎng)站的相關插件使用，如果沒有將不能被正確執(zhí)行;如果惡意的接口調用請求沒有破解JS SDK，那么惡意請求在該步驟將被攔截;如果破解JS SDK，那么本次請求成功，但是下次請求將重新計算JS SDK，由于JS SDK算法各不相同，客戶端接口的惡意調用請求又需要重新破解，這種破解難度很大，每次破解所花時間也很客觀，比正常流程的接口調用請求甚至要慢很多。
[0076]針對防刷接口的數(shù)據(jù)以及網(wǎng)站其他業(yè)務方的數(shù)據(jù)，可以根據(jù)用戶的客戶端ip信息、設備號等建立并更新黑白名單庫，在黑名單中的用戶可以直接被攔截，有些已知的重點用戶為避免誤傷，可以人工添加到白名單庫中。
[0077]可見，在數(shù)據(jù)基礎不強時，在黑白名單庫無法識別并攔截惡意請求的情況下，可以繼續(xù)通過令牌參數(shù)校驗和簽名校驗，快速識別并攔截惡意請求，并且可以將用戶信息添加進黑名單或白名單庫中，從而使得接口防刷更為精準。
[0078]參見圖2，圖2為本發(fā)明實施例提供的一種針對接口的調用請求的處理裝置的結構示意圖，與圖1所示的流程相對應，預先建立針對用戶的黑名單庫和白名單庫;該處理裝置可以包括:接收模塊201、獲得模塊202、生成模塊203、判斷模塊204、攔截模塊205。
[0079]其中，接收模塊201，用于接收用戶針對目標接口的調用請求，所述調用請求中至少包括請求地址；
[0080]獲得模塊202，用于獲得至少包含用于校驗所述請求地址合法性的參數(shù)的令牌和用于生成針對所述請求地址的地址簽名的第一算法組；
[0081]生成模塊203，用于根據(jù)所述第一算法組以及所述請求地址，生成針對所述請求地址的第一地址簽名；
[0082]判斷模塊204，用于根據(jù)所述黑名單庫、所述白名單庫、所述令牌和所述第一地址簽名，判斷所述調用請求是否為惡意請求；
[0083]具體的，判斷模塊204，具體可以用于:
[0084]根據(jù)所述黑名單庫，判斷所述黑名單庫中是否存在所述用戶對應的標識信息；
[0085]如果存在，確定所述調用請求為惡意請求；
[0086]如果不存在，根據(jù)所述白名單庫，判斷所述白名單庫中是否存在所述用戶對應的標識信息；
[0087]如果否，根據(jù)所述令牌中包含的參數(shù)，校驗所述請求地址是否合法；
[0088]如果不合法，確定所述調用請求為惡意請求；
[0089]如果合法，根據(jù)所述請求地址、所述令牌包含的用于生成簽名的參數(shù)以及所述第一算法組對應的第二算法組，生成第二地址簽名；
[0090]判斷所述第二地址簽名和所述第一地址簽名是否相同；
[0091 ]如果不相同，確定所述調用請求為惡意請求。
[0092]攔截模塊205，用于在判斷所述調用請求為惡意請求的情況下，攔截所述調用請求。
[0093]具體的，針對接口的調用請求的處理裝置，還可以包括第一添加模塊(圖中未示出)。
[0094]其中，第一添加模塊，可以用于在將所述調用請求確定為惡意請求的次數(shù)到達預設第一次數(shù)的情況下，將所述用戶對應的標識信息添加到所述黑名單庫中。
[0095]具體的，針對接口的調用請求的處理裝置，還可以包括第二添加模塊(圖中未示出)。
[0096]其中，第二添加模塊，可以用于在將所述調用請求確定為非惡意請求的次數(shù)到達預設第二次數(shù)、且所述白名單庫中不存在所述用戶對應的標識信息的情況下，將所述用戶對應的標識信息添加到所述白名單庫中。
[0097]可見，在數(shù)據(jù)基礎不強時，在黑白名單庫無法識別并攔截惡意請求的情況下，可以繼續(xù)通過令牌參數(shù)校驗和簽名校驗，快速識別并攔截惡意請求，并且可以將用戶信息添加進黑名單或白名單庫中，從而使得接口防刷更為精準。
[0098]需要說明的是，在本文中，諸如第一和第二等之類的關系術語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關系或者順序。而且，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同要素。
[0099]本說明書中的各個實施例均采用相關的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對于裝置實施例而言，由于其基本相似于方法實施例，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。
[0100]本領域普通技術人員可以理解實現(xiàn)上述方法實施方式中的全部或部分步驟是可以通過程序來指令相關的硬件來完成，所述的程序可以存儲于計算機可讀取存儲介質中，這里所稱得的存儲介質，如:R0M/RAM、磁碟、光盤等。
[0101]以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。凡在本發(fā)明的精神和原則之內(nèi)所作的任何修改、等同替換、改進等，均包含在本發(fā)明的保護范圍內(nèi)。
【主權項】
1.一種針對接口的調用請求的處理方法，其特征在于，預先建立針對用戶的黑名單庫和白名單庫;所述方法包括: 接收用戶針對目標接口的調用請求，所述調用請求中至少包括請求地址； 獲得至少包含用于校驗所述請求地址合法性的參數(shù)的令牌和用于生成針對所述請求地址的地址簽名的第一算法組； 根據(jù)所述第一算法組以及所述請求地址，生成針對所述請求地址的第一地址簽名；根據(jù)所述黑名單庫、所述白名單庫、所述令牌和所述第一地址簽名，判斷所述調用請求是否為惡意請求； 如果是，攔截所述調用請求。2.根據(jù)權利要求1所述的方法，其特征在于，所述根據(jù)所述黑名單庫、所述令牌和所述第一地址簽名，判斷所述調用請求是否為惡意請求，包括: 根據(jù)所述黑名單庫，判斷所述黑名單庫中是否存在所述用戶對應的標識信息； 如果存在，確定所述調用請求為惡意請求； 如果不存在，根據(jù)所述白名單庫，判斷所述白名單庫中是否存在所述用戶對應的標識信息； 如果否，根據(jù)所述令牌中包含的參數(shù)，校驗所述請求地址是否合法； 如果不合法，確定所述調用請求為惡意請求； 如果合法，根據(jù)所述請求地址、所述令牌包含的用于生成簽名的參數(shù)以及所述第一算法組對應的第二算法組，生成第二地址簽名； 判斷所述第二地址簽名和所述第一地址簽名是否相同； 如果不相同，確定所述調用請求為惡意請求。3.根據(jù)權利要求2所述的方法，其特征在于，所述方法還包括: 在將所述調用請求確定為惡意請求的次數(shù)到達預設第一次數(shù)的情況下，將所述用戶對應的標識信息添加到所述黑名單庫中。4.根據(jù)權利要求2所述的方法，其特征在于，所述方法還包括: 在將所述調用請求確定為非惡意請求的次數(shù)到達預設第二次數(shù)、且所述白名單庫中不存在所述用戶對應的標識信息的情況下，將所述用戶對應的標識信息添加到所述白名單庫中。5.—種針對接口的調用請求的處理裝置，其特征在于，預先建立針對用戶的黑名單庫和白名單庫;所述裝置包括: 接收模塊，用于接收用戶針對目標接口的調用請求，所述調用請求中至少包括請求地址； 獲得模塊，用于獲得至少包含用于校驗所述請求地址合法性的參數(shù)的令牌和用于生成針對所述請求地址的地址簽名的第一算法組； 生成模塊，用于根據(jù)所述第一算法組以及所述請求地址，生成針對所述請求地址的第一地址簽名； 判斷模塊，用于根據(jù)所述黑名單庫、所述白名單庫、所述令牌和所述第一地址簽名，判斷所述調用請求是否為惡意請求； 攔截模塊，用于在判斷所述調用請求為惡意請求的情況下，攔截所述調用請求。6.根據(jù)權利要求5所述的裝置，其特征在于，所述判斷裝置，具體用于: 根據(jù)所述黑名單庫，判斷所述黑名單庫中是否存在所述用戶對應的標識信息； 如果存在，確定所述調用請求為惡意請求； 如果不存在，根據(jù)所述白名單庫，判斷所述白名單庫中是否存在所述用戶對應的標識信息； 如果否，根據(jù)所述令牌中包含的參數(shù)，校驗所述請求地址是否合法； 如果不合法，確定所述調用請求為惡意請求； 如果合法，根據(jù)所述請求地址、所述令牌包含的用于生成簽名的參數(shù)以及所述第一算法組對應的第二算法組，生成第二地址簽名； 判斷所述第二地址簽名和所述第一地址簽名是否相同； 如果不相同，確定所述調用請求為惡意請求。7.根據(jù)權利要求6所述的裝置，其特征在于，所述裝置還包括: 第一添加模塊，用于在將所述調用請求確定為惡意請求的次數(shù)到達預設第一次數(shù)的情況下，將所述用戶對應的標識信息添加到所述黑名單庫中。8.根據(jù)權利要求6所述的裝置，其特征在于，所述裝置還包括: 第二添加模塊，用于在將所述調用請求確定為非惡意請求的次數(shù)到達預設第二次數(shù)、且所述白名單庫中不存在所述用戶對應的標識信息的情況下，將所述用戶對應的標識信息添加到所述白名單庫中。
【文檔編號】H04L29/06GK105897782SQ201610510791
【公開日】2016年8月24日
【申請日】2016年6月30日
【發(fā)明人】劉凱, 梁昆, 孫闊, 尚德重, 張海艷, 汪強, 余文秋
【申請人】北京奇藝世紀科技有限公司