張文盛，章紅琴

(1.安徽廣播電視大學(xué) 信息技術(shù)與網(wǎng)絡(luò)管理中心，安徽 合肥 230022；2.合肥恒卓科技有限公司 營(yíng)銷(xiāo)二部，安徽 合肥 230022)

0 引言

URL是Web應(yīng)用的入口，URL安全是Web應(yīng)用安全的重要組成部分。URL存在的安全問(wèn)題主要包括信息泄露和信息篡改。信息泄露包括兩種情況：一種是給攻擊者一些有用的信息，攻擊者據(jù)此推斷內(nèi)部實(shí)現(xiàn)細(xì)節(jié)，進(jìn)而找到漏洞[1]；另一種是URL本身包含一些敏感信息，例如密碼或SESSION ID，可直接為攻擊者所用[2]。信息篡改也包括兩種情況：一種是攻擊者修改URL中的參數(shù)，通過(guò)提交精心構(gòu)造的數(shù)據(jù)，完成結(jié)構(gòu)化查詢(xún)語(yǔ)言(Structured Query Language，SQL)注入、跨站腳本攻擊(Cross Site Scripting，XSS)注入等攻擊[3]；另一種是通過(guò)分析URL中參數(shù)存在的規(guī)律，進(jìn)而枚舉所有有效的參數(shù)，獲取非授權(quán)信息[4]。URL保護(hù)是針對(duì)上述安全問(wèn)題提出的解決方案。URL保護(hù)目標(biāo)包括信息完整性和信息保密性，完整性解決信息篡改問(wèn)題，保密性解決信息泄露問(wèn)題。

目前主流的URL保護(hù)方案是設(shè)計(jì)URL保護(hù)算法。URL保護(hù)算法采用密碼學(xué)提供的加密、解密、散列等工具，將這些工具進(jìn)行一定的組合，形成算法后對(duì)URL進(jìn)行保護(hù)。這些密碼學(xué)工具的構(gòu)造有很堅(jiān)實(shí)的理論基礎(chǔ)，也經(jīng)過(guò)實(shí)踐檢驗(yàn)，因此可靠性很高，能夠達(dá)到保護(hù)URL的目的。URL保護(hù)算法的缺點(diǎn)是需要保護(hù)密鑰，如果密鑰泄露，保護(hù)算法就形同虛設(shè)。此外保護(hù)算法在生成URL和檢驗(yàn)URL時(shí)都要進(jìn)行大量運(yùn)算，增加系統(tǒng)開(kāi)銷(xiāo)。針對(duì)這些缺點(diǎn)，本文選擇從另一個(gè)角度出發(fā)，設(shè)計(jì)基于短鏈接的URL保護(hù)模型，完成保護(hù)URL完整性和保密性的目的。

1 相關(guān)研究

目前URL保護(hù)算法包括三種：保護(hù)完整性(I型)[5]、保護(hù)機(jī)密性(II型)[6]、同時(shí)保護(hù)完整性和機(jī)密性(III型)[7]。這三種算法中，使用散列函數(shù)保證完整性，使用對(duì)稱(chēng)加密算法保證機(jī)密性。

以III型為例介紹URL保護(hù)算法的工作原理。假設(shè)該法采用消息摘要算法第5版(Message-Digest Algorithm Version 5，MD5)和高級(jí)加密標(biāo)準(zhǔn)(Advanced Encryption Standard，AES)共同保護(hù)URL。規(guī)定單引號(hào)為字符串定界符，單引號(hào)之間的字符為字符串內(nèi)容，加號(hào)為字符串拼接運(yùn)算符，則算法的具體執(zhí)行過(guò)程如下。

(1)將請(qǐng)求參數(shù)s1和密鑰key1按規(guī)定順序裝配成字符串s2=key1+s1；

(2)計(jì)算s2的MD5檢驗(yàn)和v=MD5(s2)；

(3)將檢驗(yàn)和v嵌入s1成為新的請(qǐng)求字符串s3=′v=′+v+′&′+s1；

(4)對(duì)s3使用密鑰key2執(zhí)行AES加密得到字符串s4=AES(s3,key2)；

(5)對(duì)s4使用改進(jìn)base64編碼為字符串s5=base64_encode(s4)，得到最終URL；

(6)解析過(guò)程逆向操作，期間驗(yàn)證檢驗(yàn)和，丟棄無(wú)效請(qǐng)求。

其工作原理如圖1和圖2所示。

圖1 III型保護(hù)算法生成URL過(guò)程

圖2 III型保護(hù)算法解析URL過(guò)程

2 基于短鏈接的URL保護(hù)模型

短鏈接也是一種URL，只是長(zhǎng)度非常短，只有幾個(gè)字符，優(yōu)點(diǎn)是節(jié)省流量，方便生成二維碼，移動(dòng)應(yīng)用上使用很普遍[8]。本模型使用了短鏈接，工作原理如圖3所示。

圖3 基于短鏈接URL保護(hù)模型工作原理

圖3中，系統(tǒng)先生成URL，再根據(jù)URL在鍵-鍵(Key-Key，KK)緩存中查詢(xún)對(duì)應(yīng)的短鏈接，如果沒(méi)有，則使用短鏈接生成算法，生成一個(gè)短鏈接，建立URL和短鏈接的映射關(guān)系，存入KK緩存，然后將短鏈接返回給用戶(hù)。用戶(hù)訪(fǎng)問(wèn)短鏈接，系統(tǒng)在KK緩存中查詢(xún)?cè)摱替溄訉?duì)應(yīng)的URL，如果沒(méi)有則報(bào)錯(cuò)，否則再將URL傳給后端業(yè)務(wù)進(jìn)一步處理。

根據(jù)工作原理，KK緩存是模型核心，實(shí)現(xiàn)將URL映射成短鏈接和將短鏈接映射成URL的雙重功能，要求URL唯一和短鏈接唯一，屬于Key-Key緩存，區(qū)別于普通的鍵值(Key-Value，KV)緩存。KK緩存支持三個(gè)操作：存入U(xiǎn)RL和短鏈接的映射關(guān)系，根據(jù)URL獲取映射的短鏈接，根據(jù)短鏈接獲取映射的URL。

本模型中，URL和短鏈接之間的映射關(guān)系需要長(zhǎng)期維持，避免用戶(hù)過(guò)一段時(shí)間再訪(fǎng)問(wèn)短鏈接就報(bào)錯(cuò)，因此這種映射關(guān)系需要持久化，例如寫(xiě)入硬盤(pán)。隨著系統(tǒng)的持續(xù)訪(fǎng)問(wèn)，映射關(guān)系會(huì)越來(lái)越多，但其實(shí)經(jīng)常用到的不多，為了在映射數(shù)量和可用性之間找到平衡，需要定期清理映射關(guān)系，例如采用過(guò)期策略，超過(guò)一段時(shí)間沒(méi)有訪(fǎng)問(wèn)的映射關(guān)系，可以銷(xiāo)毀。

短鏈接使用短鏈接算法生成。該算法應(yīng)該基于URL生成短鏈接。為了保證系統(tǒng)安全，根據(jù)短鏈接很難推測(cè)出對(duì)應(yīng)的URL，需要設(shè)計(jì)安全高效的短鏈接生成算法，散列函數(shù)具有較好的單向性，可以用在生成算法中。為了保密，可以設(shè)置密鑰，密鑰泄漏了也沒(méi)有關(guān)系，可以換一個(gè)，對(duì)模型的執(zhí)行和安全性沒(méi)有任何影響。短鏈接很短，碰撞概率很高，因此算法需要加鹽，例如隨機(jī)數(shù)，萬(wàn)一發(fā)生碰撞，可以再生成一個(gè)。

短鏈接只有幾個(gè)隨機(jī)字符，不包含任何敏感信息。短鏈接是隨機(jī)字符串，假設(shè)長(zhǎng)度為6，采用26個(gè)大小寫(xiě)英文字符和10個(gè)數(shù)字，則短鏈接空間大小是626=56 800 235 584≈568億。合法的短鏈接最多也就十幾萬(wàn)個(gè)，只有總空間的萬(wàn)分之一不到，也就是枚舉1萬(wàn)個(gè)短鏈接，才有一個(gè)可能是合法的。完全遍歷短鏈接空間進(jìn)行攻擊，需要花費(fèi)很長(zhǎng)時(shí)間和代價(jià)。即使遍歷整個(gè)空間，由于所有的URL都是合法生成的，造成攻擊的的可能性幾乎不存在。

本模型和普通的URL保護(hù)算法屬于兩種不同的方案，稱(chēng)采用URL保護(hù)算法的方案為基于加密保護(hù)URL的算法模型，簡(jiǎn)稱(chēng)算法模型，稱(chēng)本模型為基于短鏈接保護(hù)URL的映射模型，簡(jiǎn)稱(chēng)映射模型。映射模型僅在URL和短鏈接之間進(jìn)行高速的映射操作，不涉及復(fù)雜的加解密算法，理論上性能高于算法模型。算法模型需要保護(hù)密鑰，一旦密鑰泄漏，保護(hù)就失效了。映射模型可以設(shè)置密鑰，但密鑰泄漏不影響模型的安全性，安全性要高于算法模型。此外使用短鏈接也節(jié)省傳輸流量，適合移動(dòng)互聯(lián)網(wǎng)應(yīng)用。

算法模型中，服務(wù)器根據(jù)URL進(jìn)行編碼和解碼，不依賴(lài)于其他狀態(tài)。映射模型中，服務(wù)器根據(jù)KK緩存中的數(shù)據(jù)進(jìn)行編碼和解碼，依賴(lài)于KK緩存。因此本質(zhì)上，算法模型是無(wú)狀態(tài)模型，映射模型是有狀態(tài)模型。

3 系統(tǒng)實(shí)現(xiàn)

3.1 KK緩存

KK緩存有多種選型，例如關(guān)系型數(shù)據(jù)庫(kù)MySQL；非關(guān)系型數(shù)據(jù)庫(kù)MongoDB；KV數(shù)據(jù)庫(kù)Memcache和Redis等。MySQL和MongoDB等數(shù)據(jù)庫(kù)可以建立唯一索引，并且本身已具備持久化能力，完全滿(mǎn)足KK緩存的要求，唯一的缺點(diǎn)是性能不如KV數(shù)據(jù)庫(kù)。Memcache屬于純內(nèi)存數(shù)據(jù)庫(kù)，不具備持久化能力，Memcache基于內(nèi)存，速度最快，但無(wú)法滿(mǎn)足KK的唯一性要求，需要改造。Redis的MSETNX命令可以一次設(shè)置多個(gè)KV，使用MSETNX <短鏈接> <短鏈接> ，也可變相支持KK，只是內(nèi)存占用增加一倍，此外Redis支持持久化。各種選型對(duì)比如表1所示。

表1 KK緩存選型對(duì)比

純內(nèi)存KK緩存中的數(shù)據(jù)只保存在內(nèi)存中，因此速度最快，屬于高速緩存，但缺點(diǎn)也明顯，一但系統(tǒng)重啟或崩潰數(shù)據(jù)便會(huì)丟失，還需從其他地方重新加載，例如和其他可持久型數(shù)據(jù)庫(kù)進(jìn)行合作。純內(nèi)存KK緩存重啟后，要重新初始化，從后端數(shù)據(jù)庫(kù)中加載所有映射關(guān)系。系統(tǒng)運(yùn)行中有新的映射關(guān)系建立，KK緩存中存一份，數(shù)據(jù)庫(kù)也要存一份。

為了測(cè)試各種選型的性能差異，改造Memcache實(shí)現(xiàn)純內(nèi)存KK緩存。Memcache的add操作在key存在的時(shí)候出錯(cuò)返回，該操作最接近KK需求。修改add操作的邏輯，實(shí)現(xiàn)Redis MSETNX相同功能，執(zhí)行兩次set，一次是set(key=url，value=短鏈接)，一次是set(key=短鏈接，value=url)，并且任何key存在的時(shí)候，都出錯(cuò)返回。后端再配合MySQL數(shù)據(jù)庫(kù)，就可以滿(mǎn)足KK緩存需求。

3.2 短鏈接生成算法

短鏈接生成算法有很多種實(shí)現(xiàn)方法，為了測(cè)試方便，選用的短鏈接生成算法偽代碼如下：

function ShortText(url,key,rand){

用a-z,0-9,A-Z共62個(gè)字符構(gòu)建字符表chars；

str=md5(rand+key+url);

//字符串連接，輸出為128位二進(jìn)制數(shù)據(jù)

取str前4個(gè)字節(jié)，作為32位無(wú)符號(hào)整數(shù)賦值給變量a;

b=0x3fffffff&a;

//將最高2位抹掉，變成30位數(shù)

ret=〃;

for(i=0;i<6;i++){

//循環(huán)6次

c=b&0x3d;

//限制c在0-62之間

ret=ret+chars[c];

//字符串連接

b=b>>5;

}

return ret;

//返回一個(gè)長(zhǎng)度為6的字符串

}

3.3 接口

由于KK緩存選型和短鏈接生成算法實(shí)現(xiàn)有很多種，為了兼容各種選擇，映射模型采用接口的方式實(shí)現(xiàn)，這樣不管采用什么系統(tǒng)，都可以無(wú)縫使用。接口定義如下：

interface Iurlmap

{

public function createShortLink($url);

//根據(jù)URL生成短鏈接

public function createMap($url);

//獲取URL映射短鏈接

public function resolvMap($shortlink);

//獲取短鏈接映射的URL

}

4 性能測(cè)試

比較算法模型(選用III算法，實(shí)現(xiàn)同參考文獻(xiàn)[7])和映射模型的性能開(kāi)銷(xiāo)，映射模型中的KK緩存選型包括MySQL、MongoDB、改進(jìn)Memcache和Redis。在PHP中單機(jī)(不經(jīng)過(guò)交換機(jī)和路由器)測(cè)試，配置是AMD EPYC 7281 16-Core Processor，內(nèi)存128 GB，操作系統(tǒng)Ubuntu 18.04.3 LTS，PHP 7.2.19-0ubuntu0.18.04.1 (cli，NTS)，MySQL 5.7.27-0ubuntu0.18.04.1，MongoDB 3.6.3，Redis 4.0.9，改進(jìn)Memcached基于1.4.5版本修改。Memcache等服務(wù)采用C/S模式訪(fǎng)問(wèn)，網(wǎng)絡(luò)通信很慢，作為對(duì)比，本測(cè)試還使用PHP的數(shù)組模擬純內(nèi)存KK緩存，簡(jiǎn)稱(chēng)mem。測(cè)試項(xiàng)目包括生成URL和解析URL，采用兩組不同長(zhǎng)度的URL作為輸入或輸出，分別是25字符和250字符。每組包括2種耗時(shí)測(cè)試：運(yùn)行100萬(wàn)次和運(yùn)行1 000萬(wàn)次，每種測(cè)試5次，取耗時(shí)均值，耗時(shí)單位為秒，測(cè)試結(jié)果如表2所示。

表2中，L*表示URL長(zhǎng)度，例如L25表示URL長(zhǎng)度為25字符；R*表示運(yùn)行次數(shù)，例如R100表示運(yùn)行100萬(wàn)次，T*表示該列測(cè)試類(lèi)型所需的平均時(shí)間，例如T1表示URL長(zhǎng)度25字符運(yùn)行100萬(wàn)次所需的平均時(shí)間；P1=(T4-T2)×100/T2，統(tǒng)計(jì)URL長(zhǎng)度增加10倍，耗時(shí)增加多少；P2=1 000/T2，統(tǒng)計(jì)每秒執(zhí)行操作次數(shù)(Query Per Second，QPS)，單位為萬(wàn)/s。從表2可以看出，運(yùn)行次數(shù)增加10倍，所有操作的耗時(shí)也增加10倍，耗時(shí)與運(yùn)行次數(shù)為線(xiàn)性關(guān)系；URL長(zhǎng)度增加10倍，算法模型耗時(shí)增加50%，而映射模型耗時(shí)變化很小，說(shuō)明算法模型耗時(shí)與輸入強(qiáng)相關(guān)，映射模型耗時(shí)與輸入弱相關(guān)；QPS比較，mem > III型> Memcache > Redis > MySQL > MongoDB，純內(nèi)存KK緩存速度比III保護(hù)算法快20倍，但C/S模式因?yàn)樯婕熬W(wǎng)絡(luò)通信等IO操作，導(dǎo)致Memcache比III型保護(hù)算法慢將近20倍。

表2 算法模型和映射模型的性能測(cè)試

5 結(jié)束語(yǔ)

保護(hù)URL能提高Web應(yīng)用的安全性，傳統(tǒng)基于加密保護(hù)URL的算法模型存在處理慢和密鑰泄漏問(wèn)題，本文設(shè)計(jì)一種基于短鏈接保護(hù)URL的映射模型，詳細(xì)描述模型的工作原理，通過(guò)KK緩存實(shí)現(xiàn)URL和短鏈接的高速轉(zhuǎn)換，保證了安全性和可用性。在探討了系統(tǒng)實(shí)現(xiàn)關(guān)鍵技術(shù)后，測(cè)試了算法模型和映射模型的性能，結(jié)果表明映射模型理論性能比算法模型要高一些，但由于實(shí)現(xiàn)的原因，實(shí)際性能要低一些。此外映射模型的結(jié)構(gòu)比算法模型復(fù)雜，穩(wěn)定性也要差一點(diǎn)。總體上，映射模型無(wú)密鑰泄漏問(wèn)題，節(jié)省流量，處理速度也不慢，可以滿(mǎn)足大多數(shù)Web應(yīng)用的需求。