本發(fā)明涉及互聯(lián)網(wǎng)通信中數(shù)據(jù)安全領(lǐng)域，尤其涉及一種當移動端向?qū)津炞C時服務端進行安全有效的數(shù)據(jù)處理方法。

背景技術(shù)：

隨著移動互聯(lián)網(wǎng)時代的到來，移動端設備呈爆炸式增長，人們對移動端的應用需求越來越多，在安裝和運行不同的軟件過程中，移動端會出現(xiàn)很多向?qū)津炞C的場景。比如“注冊綁卡流程”、“找回密碼流程”、“修改資料流程”等，這些場景都有一個共同點：在向?qū)津炞C過程的每一步請求中，都有可能存在服務端驗證需要，當所有步驟驗證完成后，需要完成最后一步提交，并完成業(yè)務流程。

這種向?qū)津炞C的場景，會給系統(tǒng)帶來一些安全方面的問題：向?qū)津炞C過程的請求步驟只發(fā)生驗證過程，并不發(fā)生實際業(yè)務交互；最后一步提交時會發(fā)生實際業(yè)務交互，但對于服務端而言，最后一步和前面的請求驗證步驟是分開的，中間環(huán)節(jié)中的數(shù)據(jù)安全不能保證。

針對上述技術(shù)缺陷，現(xiàn)有技術(shù)中存在兩種可供選擇的解決方案。方案一，服務端記住中間步驟中已驗證過的數(shù)據(jù)，在最后一步提交時，由服務端組裝前面已驗證過的數(shù)據(jù)，并和最后一步移動端提交上來的數(shù)據(jù)組成完整數(shù)據(jù)源，完成業(yè)務處理。該方案的優(yōu)點在于：服務端記住每一步已驗證過的數(shù)據(jù)，移動端在最后一步時不用再提交以前驗證過的數(shù)據(jù)，則已驗證過的數(shù)據(jù)相對安全，原因在于客戶端沒機會再篡改已驗證的數(shù)據(jù)。但缺點在于：(1)服務端設計不靈活，由于要在最后一步完成前緩存驗證數(shù)據(jù)，并在最后一步組裝，這樣會對移動端向?qū)皆O計產(chǎn)生很強的依賴關(guān)系，如果移動端向?qū)е忻恳徊降臄?shù)據(jù)結(jié)構(gòu)發(fā)生改變，或者向?qū)У牟襟E發(fā)生改變，服務端也需要跟著改變邏輯；(2)由于驗證數(shù)據(jù)緩存在服務端，還要考慮客戶端在向?qū)н^程中的回退修改問題；(3)由于客戶端在前面的步驟驗證完成后，未必會走完最后一步，可能最終放棄提交業(yè)務，因此還要考慮服務端驗證數(shù)據(jù)緩存的時效性問題。

方案二，通過移動端記住每一步的數(shù)據(jù)，在最后一步提交時組裝之前所有步驟的數(shù)據(jù)，組成完整的業(yè)務數(shù)據(jù)一起提交，提交后由服務端再次驗證，完成業(yè)務處理。這種方案的優(yōu)點在于：服務端驗證和最后一步處理分開邏輯，服務端不用緩存數(shù)據(jù)，不依賴于客戶端的向?qū)皆O計。但缺點在于：為保證最后執(zhí)行業(yè)務時的數(shù)據(jù)安全性，服務端需要對最后一步提交的全部數(shù)據(jù)進行再次驗證，以保證數(shù)據(jù)沒有在驗證過后被客戶端篡改；但并不是所有的驗證都能再次驗證：比如手機驗證碼在驗證成功后，最后一步無法再次驗證手機驗證碼。

鑒于上述安全問題和現(xiàn)存解決方案的缺陷，本發(fā)明創(chuàng)造者經(jīng)過長時間的研究和實踐終于獲得了本創(chuàng)作。

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

本發(fā)明的目的在于提供一種針對移動端向?qū)津炞C的服務端數(shù)據(jù)處理方法，以解決現(xiàn)有技術(shù)中服務端設計不靈活，重復驗證的問題。

為了實現(xiàn)上述目的，本發(fā)明的技術(shù)方案是：一種針對移動端向?qū)津炞C的服務端數(shù)據(jù)處理方法，包括如下步驟：

服務端對移動端發(fā)送的需要驗證的業(yè)務數(shù)據(jù)進行數(shù)據(jù)驗證；

所述服務端對驗證通過的業(yè)務數(shù)據(jù)用服務端私鑰進行簽名，并返回移動端；上述步驟在所述移動端向?qū)Р襟E中完成；

所述服務端將移動端最后一步提交的組裝緩存的所有步驟的業(yè)務數(shù)據(jù)用公鑰進行驗簽，若全部驗簽通過，則所提交的業(yè)務數(shù)據(jù)已經(jīng)過通所述服務端的驗證。

進一步地，在所述服務端的簽名過程中，服務端采用私鑰進行簽名，并定義一個關(guān)鍵字，把關(guān)鍵字和簽名值組裝成鍵值對，格式為：關(guān)鍵字+簽名值。

進一步地，所述關(guān)鍵字為服務端自定義的能代表某種驗證的表達式。

進一步地，所述服務端形成的鍵值對用服務端的對稱密鑰進行加密，形成加密字符串，按照預設格式向移動端返回驗證結(jié)果和加密字符串。

進一步地，所述移動端在最后一步提交時，組裝緩存的所有步驟業(yè)務數(shù)據(jù)和每一步服務端返回的加密字符串，按照預設的格式一起發(fā)送給服務端。

進一步地，所述服務端把移動端提交的加密字符串逐一解密，解密后還原成預設的關(guān)鍵字+簽名值的格式。

進一步地，所述服務端根據(jù)服務端對關(guān)鍵字定義的含義，查找最后一步移動端提交的全部業(yè)務數(shù)據(jù)中相對應的數(shù)據(jù)，并把對應的數(shù)據(jù)和簽名值進行驗簽比對。

進一步地，所述鍵值對的數(shù)量至少為一條。

與現(xiàn)有技術(shù)相比本發(fā)明具有以下有益效果：本發(fā)明針對移動端向?qū)津炞C的服務端數(shù)據(jù)處理方法，利用數(shù)據(jù)簽名的特點，達到再次驗證的效果；能簡單有效地保障移動端向?qū)津炞C場景下，服務端進行數(shù)據(jù)處理的安全性。

一方面，本發(fā)明采用數(shù)據(jù)簽名，僅在移動端最后一步提交時，完成一次驗證，避免重復驗證，節(jié)約程序資源。

另一發(fā)明，本發(fā)明數(shù)據(jù)簽名采用服務端自定義的能代表某種驗證的表達式，把關(guān)鍵字和簽名值組裝成鍵值對，編碼格式簡便，服務端具有較大的設計靈活性，數(shù)據(jù)格式的穩(wěn)定性好。

并且，本發(fā)明移動端在最后一步，將組成完整的業(yè)務數(shù)據(jù)一起提交，提交后由服務端再次驗證，服務端驗證和最后一步分開處理邏輯，服務端不用緩存數(shù)據(jù)，不依賴于客戶端的向?qū)皆O計，具有較大的設計靈活性。服務端在向?qū)н^程中，將需要驗證的數(shù)據(jù)進行簽名，并在最后步驟中統(tǒng)一驗證簽名，大大節(jié)約服務器的程序資源。

附圖說明

圖1為本發(fā)明的針對移動端向?qū)津炞C的服務端數(shù)據(jù)處理方法的流程示意圖；

圖2為本發(fā)明的移動端向?qū)津炞C中移動端和服務端雙方的流程示意圖。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整的描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例。

請參閱圖1所示，其為本發(fā)明的針對移動端向?qū)津炞C的服務端數(shù)據(jù)處理方法的流程示意圖；包括下述步驟：

步驟a，服務端對移動端發(fā)送的需要驗證的業(yè)務數(shù)據(jù)進行數(shù)據(jù)驗證；

步驟b，服務端對驗證通過的業(yè)務數(shù)據(jù)用服務端私鑰進行簽名，并返回移動端；

步驟c，服務端將移動端最后一步提交的組裝緩存的所有步驟的業(yè)務數(shù)據(jù)用公鑰進行驗簽，若全部驗簽通過，則所提交的業(yè)務數(shù)據(jù)已經(jīng)通過服務端的驗證。

經(jīng)過上述步驟c驗證的數(shù)據(jù)則可以信任，沒有被篡改，無須再次驗證；通過上述驗證后，則服務端進行最后一步的正常業(yè)務處理。

具體而言，上述步驟b的簽名過程應用在移動端向?qū)Р襟E中，在上述步驟b中，服務端采用私鑰進行簽名，并定義一個關(guān)鍵字，把關(guān)鍵字和簽名值組裝成鍵值對；關(guān)鍵字為服務端自定義的能代表某種驗證的表達式；最終形成的鍵值對的格式為：關(guān)鍵字+簽名值的格式。

較佳的，為了更好地保護簽名數(shù)據(jù)的安全性，在上述步驟b中，上述鍵值對還可以增加秘鑰；具體操作為：把上述鍵值對數(shù)據(jù)用服務端的對稱密鑰進行加密，形成加密字符串，向移動端返回驗證結(jié)果和加密字符串。

具體而言，在上述步驟b后，移動端根據(jù)服務端返回的驗證結(jié)果判斷是否進入下一步，并緩存來自服務端的加密字符串以及當前步驟中的業(yè)務數(shù)據(jù)。

具體而言，上述步驟c發(fā)生在移動端向?qū)瓿勺詈笠徊叫枰蚍斩颂峤粫r，在該過程中，若存在加密情形，所述移動端組裝緩存的所有步驟業(yè)務數(shù)據(jù)，和每一步服務端返回的加密字符串，按照預設的格式一起發(fā)送給服務端。

相應的，所述服務端把移動端提交的加密字符串逐一解密，解密后還原成預設的鍵值對的格式，關(guān)鍵字+簽名值的格式。在本實施例中，存在至少一個向?qū)Р襟E，每一個向?qū)Р襟E都可能需要驗證，因此，存在至少一條鍵值對數(shù)據(jù)，因此，移動端向服務端發(fā)送鍵值對數(shù)據(jù)值，按照預設的格式將每條鍵值對數(shù)據(jù)發(fā)送至服務端，避免發(fā)生驗證紊亂。

具體而言，在上述步驟c中，根據(jù)服務端對關(guān)鍵字定義的含義，查找最后一步移動端提交的全部業(yè)務數(shù)據(jù)中相對應的數(shù)據(jù)，并把對應的數(shù)據(jù)和簽名值進行驗簽比對，如果全部驗簽通過，根據(jù)數(shù)據(jù)簽名的特點，可以斷定所提交的業(yè)務數(shù)據(jù)已經(jīng)過服務端的驗證，并且沒有被篡改，無須再次驗證。

請參閱圖2所示，其為本發(fā)明的移動端向?qū)津炞C中移動端和服務端雙方處理的流程示意圖，下面按照時序的先后順序說明該過程為：

步驟s01，移動端向服務端發(fā)送當前步驟中需要驗證的業(yè)務數(shù)據(jù)；本領(lǐng)域技術(shù)人員可以理解的是，業(yè)務數(shù)據(jù)的傳輸格式可以為常用的編碼格式，此過程也可以加密。

步驟c01，服務端對提交的業(yè)務數(shù)據(jù)，進行數(shù)據(jù)驗證；

步驟c02，對驗證通過的數(shù)據(jù)用服務端私鑰進行簽名，并定義一個關(guān)鍵字，把關(guān)鍵字和簽名值組裝成鍵值對，最后形成的鍵值對為：關(guān)鍵字+簽名值的形式；

關(guān)鍵字為服務端自定義的能代表某種驗證的表達式；針對被驗證的數(shù)據(jù)或者數(shù)據(jù)組合，簽名使用服務端自己的私鑰進行簽名。

在本實施例中，比如手機號的驗證關(guān)鍵字定義為“s01”，姓名的驗證關(guān)鍵字定義為“s02”；則驗證成功手機號后，對userid+手機號進行簽名，形成一個簽名值。顯然，該種定義方式具有多種形式。

步驟c03，服務端把上述鍵值對數(shù)據(jù)用服務端的對稱密鑰進行加密，形成加密字符串，向移動端返回驗證結(jié)果和加密字符串；顯然可以理解的是，驗證關(guān)鍵字與加密字符串可以設置同一格式，統(tǒng)一編碼。

步驟s02，根據(jù)服務端返回的驗證結(jié)果判斷是否進入下一步，并緩存加密字符串以及當前步驟中的業(yè)務數(shù)據(jù)；

步驟s03，組裝緩存的所有步驟業(yè)務數(shù)據(jù)，和每一步服務端返回的加密字符串，一起發(fā)送給服務端；

步驟c04，把移動端提交的加密字符串逐一解密，解密后還原成關(guān)鍵字+簽名值的數(shù)據(jù)格式；

步驟c05，根據(jù)服務端對關(guān)鍵字定義的含義，查找最后一步移動端提交的全部業(yè)務數(shù)據(jù)中相對應的數(shù)據(jù)，并把對應的數(shù)據(jù)和簽名值進行驗簽比對，如果全部驗簽通過，根據(jù)數(shù)據(jù)簽名的特點，可以斷定所提交的業(yè)務數(shù)據(jù)已經(jīng)過服務端的驗證，并且沒有被篡改，無須再次驗證。

在本實施例中，比如關(guān)鍵字為s01，則查找提交上來的業(yè)務數(shù)據(jù)中的userid+手機號，并把userid+手機號和鍵值對中s01對應的簽名值進行驗簽；

步驟c06，進行最后一步的正常業(yè)務處理。

至此，已經(jīng)結(jié)合附圖所示的優(yōu)選實施方式描述了本發(fā)明的技術(shù)方案，但是，本領(lǐng)域技術(shù)人員容易理解的是，本發(fā)明的保護范圍顯然不局限于這些具體實施方式。在不偏離本發(fā)明的原理的前提下，本領(lǐng)域技術(shù)人員可以對相關(guān)技術(shù)特征作出等同的更改或替換，這些更改或替換之后的技術(shù)方案都將落入本發(fā)明的保護范圍之內(nèi)。