本發(fā)明涉及信息加密領(lǐng)域，尤其涉及一種客戶端發(fā)送加密URL請求的方法和系統(tǒng)。

背景技術(shù)：

隨著移動設(shè)備的普及，移動客戶端基本覆蓋了人們生活的各個方面，其占據(jù)人們生活的時間大幅增加，人們可以通過安裝在移動設(shè)備上的各個軟件客戶端與外界交流、消費，完成一些涉及隱私的活動，因此，在很多應(yīng)用場景下，客戶端軟件也需要很高安全系數(shù)的接口，這些個接口跟用戶的個人信息，隱私行為數(shù)據(jù)以及與用戶和企業(yè)的金錢財富相關(guān)聯(lián)。

當(dāng)前的移動客戶端使用http協(xié)議或https協(xié)議，其中http協(xié)議安全性不高，URL請求被截取后，可以輕易篡改參數(shù)并模擬請求；而按照https協(xié)議部署則過于麻煩，代價較高。

技術(shù)實現(xiàn)要素：

本發(fā)明所要解決的技術(shù)問題是，提供一種客戶端發(fā)送加密URL請求的方法和系統(tǒng)，以解決http協(xié)議安全性不高，請求易被抓包，被截取后，可以輕易篡改參數(shù)并模擬請求和https協(xié)議部署則過于麻煩，代價較高的問題。

本發(fā)明解決上述技術(shù)問題所采用的技術(shù)方案是提供一種客戶端發(fā)送加密URL請求的方法，該方法包括步驟：

S1、客戶端根據(jù)與服務(wù)端預(yù)先約定的密鑰生成并存儲私鑰碎片；

S2、當(dāng)所述客戶端發(fā)送URL請求時，通過所述私鑰碎片生成所述私鑰；

S3、所述客戶端根據(jù)所述私鑰對待發(fā)送的URL請求進(jìn)行加密、拼接，發(fā)送加密后的URL請求。

優(yōu)選地，所述客戶端生成并存儲所述私鑰碎片包括步驟：

S101、所述客戶端將所述私鑰拆解為頭部head、中部body和尾部tail三部分；

S102、在所述頭部head、中部body和尾部tail中分別加入冗余干擾串并進(jìn)行加密；

S103、生成三個所述私鑰碎片并存儲。

優(yōu)選地，通過所述私鑰碎片生成所述私鑰包括步驟：

S201、將三個所述私鑰碎片解密，排除冗余干擾串；

S202、得到所述頭部head、中部body、尾部tail三部分；

S203、通過逆向拼接得到所述私鑰。

優(yōu)選地，所述客戶端根據(jù)所述私鑰對所述待發(fā)送的URL請求進(jìn)行加密包括步驟：

S301、在所述待發(fā)送的URL請求中加入時間戳和IMEI參數(shù)；

S302、對所述私鑰和加入時間戳和IMEI參數(shù)的待發(fā)送的URL請求計算sign值，將sign值拼接加入時間戳和IMEI參數(shù)的待發(fā)送的URL請求中，生成加密后的URL請求。

優(yōu)選地，所述客戶端根據(jù)所述私鑰對所述待發(fā)送的URL請求進(jìn)行加密包括對所述私鑰和待發(fā)送的URL請求計算sign值，將sign值拼接待發(fā)送的URL請求中，生成加密后的URL請求。

優(yōu)選地，所述方法還包括服務(wù)端接收所述加密后的URL請求，并剔除所述sign值，獲取發(fā)送的URL請求，對所述私鑰和獲取發(fā)送的URL請求計算新的sign值，當(dāng)所述新的sign值與所述剔除的sign值相同時，則驗證URL請求合法。

另一方面，本發(fā)明提供一種客戶端發(fā)送加密URL請求的系統(tǒng)，其特征在于，所述系統(tǒng)包括：

私鑰碎片生成單元，用于根據(jù)客戶端與服務(wù)端預(yù)先約定的密鑰生成并存儲私鑰碎片；

私鑰生成單元，用于在所述客戶端發(fā)送URL請求時，通過所述私鑰碎片生成所述私鑰；

URL請求單元，用于根據(jù)所述私鑰對待發(fā)送的URL請求進(jìn)行加密、拼接，發(fā)送加密后的URL請求。

優(yōu)選地，所述私鑰碎片生成單元包括：

拆分單元，用于將所述私鑰拆解為頭部head、中部body和尾部tail三部分；

加密單元，用于在所述頭部head、中部body和尾部tail中分別加入冗余干擾串并進(jìn)行加密；

存儲單元，用于生成三個所述私鑰碎片并存儲。

優(yōu)選地，所述私鑰生成單元包括：

解密單元，用于將三個所述私鑰碎片解密，排除冗余干擾串，得到所述頭部head、中部body、尾部tail三部分；

拼接單元，用于通過逆向拼接得到所述私鑰。

優(yōu)選地，所述URL請求單元包括：

參數(shù)添加單元，用于在所述待發(fā)送的URL請求中加入時間戳和IMEI參數(shù)；

URL加密單元，用于對所述私鑰和加入時間戳和IMEI參數(shù)的待發(fā)送的URL請求或所述待發(fā)送URL請求計算sign值，將sign值拼接加入時間戳和IMEI參數(shù)的待發(fā)送的URL請求或所述待發(fā)送URL請求中，生成加密后的URL請求；

URL接收驗證單元，用于服務(wù)端接收所述加密后的URL請求，并剔除所述sign值，獲取發(fā)送的URL請求，對所述私鑰和獲取發(fā)送的URL請求計算新的sign值，當(dāng)所述新的sign值與所述剔除的sign值相同時，則驗證URL請求合法。

本發(fā)明中，所述客戶端以所述私鑰碎片的形式存儲與所述服務(wù)端約定的私鑰，保證所述私鑰在所述客戶端保存的安全性；在向所述服務(wù)端發(fā)送URL請求時，將所述私鑰碎片合成所述私鑰，并通過時間戳、IMEI等參數(shù)和sign值對請求進(jìn)行加密，通過MD5和SHA等方式對請求數(shù)據(jù)進(jìn)行加密，以保證傳輸請求數(shù)據(jù)的安全性，增加了http協(xié)議請求的安全性，避免了現(xiàn)有技術(shù)中http協(xié)議請求傳輸過程中參數(shù)易被攔截、篡改和模擬請求等問題，同時，避免了https協(xié)議雖然安全性高，但過于麻煩的情況；同時，所述服務(wù)器端對所述URL請求進(jìn)行解密，經(jīng)過判斷所述時間戳和IMEI的合法性以及所述sign值的正確性，來判斷請求是否合法，保證接收到的URL請求時未經(jīng)攔截、篡改和模擬請求的。

附圖說明

圖1是本發(fā)明的服務(wù)端與客戶端交互的加密方法的流程圖；

圖2是本發(fā)明的服務(wù)端與客戶端交互的加密系統(tǒng)的結(jié)構(gòu)圖。

具體實施方式

以下實施例僅用于更加清楚地說明本發(fā)明的技術(shù)方案，而不能以此來限制本發(fā)明的保護(hù)范圍。說明書后續(xù)描述為實施本發(fā)明的較佳實施方式，然所述描述乃以說明本發(fā)明的一般原則為目的，并非用以限定本發(fā)明的范圍。本發(fā)明的保護(hù)范圍當(dāng)視所附權(quán)利要求所界定者為準(zhǔn)。

下面結(jié)合附圖和具體實施例對本發(fā)明做進(jìn)一步詳細(xì)說明。

如圖1所示，為本發(fā)明的一個優(yōu)選實施例，公開了一一種客戶端發(fā)送加密URL請求的方法，該方法包含步驟：

S1、客戶端根據(jù)與服務(wù)端預(yù)先約定的密鑰生成并存儲私鑰碎片；

S2、當(dāng)客戶端發(fā)送URL請求時，通過私鑰碎片生成私鑰；

S3、客戶端根據(jù)私鑰對待發(fā)送的URL請求進(jìn)行加密、拼接，發(fā)送加密后的URL請求。

本實施例中，客戶端利用私鑰碎片合成私鑰，對客戶端的URL請求進(jìn)行加密，增加了http協(xié)議請求的安全性，避免了現(xiàn)有技術(shù)中http協(xié)議請求傳輸過程中參數(shù)易被攔截、篡改和模擬請求等問題，同時，避免了https協(xié)議雖然安全性高，但過于麻煩的情況。

進(jìn)一步地，客戶端生成并存儲私鑰碎片包括步驟：

S101、客戶端將私鑰拆解為頭部head、中部body和尾部tail三部分；

S102、在頭部head、中部body和尾部tail中分別加入冗余干擾串并進(jìn)行加密；

S103、生成三個私鑰碎片并存儲。

本實施例中，客戶端以私鑰碎片的形式存儲私鑰，將私鑰分為三個私鑰碎片，以確保客戶端私鑰存儲的安全性和隱蔽性，不易被仿造和獲取。

進(jìn)一步地，通過私鑰碎片生成私鑰包括步驟：

S201、將三個私鑰碎片解密，排除冗余干擾串；

S202、得到頭部head、中部body、尾部tail三部分；

S203、通過逆向拼接得到私鑰。

本實施例中，每次客戶端發(fā)送URL請求時，將三個私鑰碎片進(jìn)行拆解和逆向拼接，重新得到私鑰，確保每次使用的私鑰都是新生成的，防止使用生成的私鑰被篡改導(dǎo)致的安全問題。

進(jìn)一步地，客戶端根據(jù)私鑰對待發(fā)送的URL請求進(jìn)行加密包括步驟：

S301、在待發(fā)送的URL請求中加入時間戳和IMEI參數(shù)；

S302、對私鑰和加入時間戳和IMEI參數(shù)的待發(fā)送的URL請求計算sign值，將sign值拼接加入時間戳和IMEI參數(shù)的待發(fā)送的URL請求中，生成加密后的URL請求。

本實施例中，通過在URL請求中加入?yún)?shù)，例如，時間戳，IMEI等，并將sign至拼接到URL請求中來加密待發(fā)送的URL請求，確保URL請求的安全性。

進(jìn)一步地，客戶端根據(jù)私鑰對待發(fā)送的URL請求進(jìn)行加密包括對私鑰和待發(fā)送的URL請求計算sign值，將sign值拼接待發(fā)送的URL請求中，生成加密后的URL請求。

本實施例中，將sign算法計算待發(fā)送的URL的sign值并拼接到待發(fā)送URL中，對URL請求進(jìn)行加密，同時，使用MD5加密算法和SHA加密算法對請求數(shù)據(jù)進(jìn)行加密，確保URL請求的安全性。

進(jìn)一步地，本方法還包括服務(wù)端接收加密后的URL請求，并剔除sign值，獲取發(fā)送的URL請求，對私鑰和獲取發(fā)送的URL請求計算新的sign值，當(dāng)新的sign值與剔除的sign值相同時，則驗證URL請求合法。

本實施例中，服務(wù)端通過sign值的正確性確定URL請求的正確性和安全性，以確保服務(wù)端響應(yīng)的URL請求合法，并記錄不合法請求的信息。

本領(lǐng)域普通技術(shù)人員可以理解，實現(xiàn)上述實施例方法中的全部或部分步驟是可以通過程序來指令相關(guān)的硬件來完成，所述的程序可以存儲于計算機可讀取存儲介質(zhì)中，該程序在執(zhí)行時，包括上述實施例方法的各步驟，而所述的存儲介質(zhì)可以是：ROM/RAM、磁碟、光盤、存儲卡等。因此，本領(lǐng)域相關(guān)技術(shù)人員應(yīng)能理解，與本發(fā)明的方法相對應(yīng)的，本發(fā)明還同時包括一種客戶端發(fā)送加密URL請求的系統(tǒng)，參見圖2，與上述方法步驟一一對應(yīng)地，該系統(tǒng)包括：

私鑰碎片生成單元，用于根據(jù)客戶端與服務(wù)端預(yù)先約定的密鑰生成并存儲私鑰碎片；

私鑰生成單元，用于在客戶端發(fā)送URL請求時，通過私鑰碎片生成私鑰；

URL請求單元，用于根據(jù)私鑰對待發(fā)送的URL請求進(jìn)行加密、拼接，發(fā)送加密后的URL請求。

本實施例中，通過私鑰碎片生成單元將私鑰以碎片形式存儲，確保私鑰存儲的安全性和隱蔽性，不易被仿造和獲?。煌ㄟ^私鑰生成單元在發(fā)送URL請求時生成私鑰，確保每次使用的私鑰都是新生成的，防止使用生成的私鑰被篡改導(dǎo)致的安全問題；通過URL請求單元對URL請求進(jìn)行加密、拼接并發(fā)送，增加了http協(xié)議請求的安全性，避免了現(xiàn)有技術(shù)中http協(xié)議請求傳輸過程中參數(shù)易被攔截、篡改和模擬請求等問題。

進(jìn)一步地，私鑰碎片生成單元包括：

拆分單元，用于將私鑰拆解為頭部head、中部body和尾部tail三部分；

加密單元，用于在頭部head、中部body和尾部tail中分別加入冗余干擾串并進(jìn)行加密；

存儲單元，用于生成三個私鑰碎片并存儲。

本實施例中，私鑰碎片生成單元包括拆分單元、加密單元和存儲單元，將私鑰拆分成三部分，加入冗余干擾串并加密，形成私鑰碎片，并以碎片的形式存儲，以確保私鑰存儲的安全性和隱蔽性，不易被仿造和獲取。

進(jìn)一步地，私鑰生成單元包括：

解密單元，用于將三個私鑰碎片解密，排除冗余干擾串，得到頭部head、中部body、尾部tail三部分；

拼接單元，用于通過逆向拼接得到私鑰。

本實施例中，私鑰生成單元通過解密單元和拼接單元對私鑰碎片進(jìn)行解密和拼接，形成私鑰，確保每次使用的私鑰都是新生成的，防止使用生成的私鑰被篡改導(dǎo)致的安全問題。

進(jìn)一步地，URL請求單元包括：

參數(shù)添加單元，用于在待發(fā)送的URL請求中加入時間戳和IMEI參數(shù)；

URL加密單元，用于對私鑰和加入時間戳和IMEI參數(shù)的待發(fā)送的URL請求或待發(fā)送URL請求計算sign值，將sign值拼接加入時間戳和IMEI參數(shù)的待發(fā)送的URL請求或待發(fā)送URL請求中，生成加密后的URL請求；

URL接收驗證單元，用于服務(wù)端接收加密后的URL請求，并剔除sign值，獲取發(fā)送的URL請求，對私鑰和獲取發(fā)送的URL請求計算新的sign值，當(dāng)新的sign值與剔除的sign值相同時，則驗證URL請求合法。

本實施例中，參數(shù)添加單元可以但不限于添加時間戳和IMEI參數(shù)，URL加密單元通過sign值對待發(fā)送的URL進(jìn)行加密，通過URL接收驗證單元接收URL請求并驗證請求和合法性，及時響應(yīng)，若請求出現(xiàn)錯誤，及時記錄。

與現(xiàn)有技術(shù)相比，本發(fā)明通過MD5、SHA、BASE64、sign算法等多種加密方式對http協(xié)議進(jìn)行加密，客戶端通過私鑰碎片的形式存儲與服務(wù)端約定的私鑰，確保私鑰的安全性和客戶端URL請求傳遞的安全性，服務(wù)端通過判斷sign值和IMEI以及時間戳的正確和合法性確保服務(wù)端跳轉(zhuǎn)的URL請求合法，本方法實現(xiàn)了http請求參數(shù)的加密與驗證，增加了破解難度，同時，解決了現(xiàn)有技術(shù)http安全性不高，傳輸過程中參數(shù)易被攔截、篡改和模擬請求的問題，此外，也避免了選擇https協(xié)議確保安全性而導(dǎo)致的部署過于麻煩、對資源消耗過高等問題。

值得注意的是，以上所述僅為本發(fā)明的較佳實施例，并非因此限定本發(fā)明的專利保護(hù)范圍，或直接或間接運用于其他相關(guān)技術(shù)領(lǐng)域均同理皆包含于本發(fā)明所涵蓋的范圍內(nèi)。