web安全

lordharrd 發(fā)布于2019-08-22 18:08 / 3164人閱讀

摘要：是一種經(jīng)常出現(xiàn)在應(yīng)用中的計(jì)算機(jī)安全漏洞，它允許惡意用戶(hù)將代碼植入到提供給其它用戶(hù)使用的頁(yè)面中。如何攻擊要合理使用與為了省事兒，把應(yīng)當(dāng)提交的數(shù)據(jù)，做成請(qǐng)求。

XSS

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

For example:


        
        
      
      你輸入的內(nèi)容: {{{text}}}

submit點(diǎn)一下：

GG ~

如何防范?

目前來(lái)講，最簡(jiǎn)單的辦法防治辦法，還是將前端輸出數(shù)據(jù)都進(jìn)行轉(zhuǎn)義最為穩(wěn)妥。

比如，按照剛剛我們那個(gè)例子來(lái)說(shuō)，其本質(zhì)是，瀏覽器遇到script標(biāo)簽的話(huà)，則會(huì)執(zhí)行其中的腳本。但是如果我們將script標(biāo)簽的進(jìn)行轉(zhuǎn)義，則瀏覽器便不會(huì)認(rèn)為其是一個(gè)標(biāo)簽，但是顯示的時(shí)候，還是會(huì)按照正常的方式去顯示:

      
         
          
        
        你輸入的內(nèi)容: {{text2}}

再試一下：

特殊情況？

大部分情況下，我們靠對(duì) html 實(shí)體字符的轉(zhuǎn)義已經(jīng)能夠?qū)?XSS 風(fēng)險(xiǎn)控制在門(mén)外。但是一些特殊情況我們不得不進(jìn)行非轉(zhuǎn)義字符串的輸出時(shí)，隱患就會(huì)再次出現(xiàn)。

后端數(shù)據(jù)直出

當(dāng)我們需要后端直接將數(shù)據(jù)打印在 script 標(biāo)簽中生成 js 變量的時(shí)候，我們通常不希望變量的值被轉(zhuǎn)義從而避免前端渲染的時(shí)候值被二次轉(zhuǎn)義的問(wèn)題，所以我們的代碼會(huì)被輸出成:

  
    " };

試一下：

如何防范?

將特殊字符進(jìn)行字符串轉(zhuǎn)義比如 " " / 防止他們提前結(jié)束字符串、閉合 sciprt 標(biāo)簽。后端使用 json.dump() 實(shí)現(xiàn)。js 的 JSON.stringify 不會(huì)做這些操作

將輸出變量字符進(jìn)行 Unicode 編碼

將輸出變量字符進(jìn)行 Hex 16進(jìn)制編碼編碼

    
      ",
        data1: "u003cu002fu0073u0063u0072u0069u0070u0074u003eu003cu0073u0063u0072u0069u0070u0074u003eu0061u006cu0065u0072u0074u0028u0030u0029u003cu002fu0073u0063u0072u0069u0070u0074u003e",
        data2: "x3cx2fx73x63x72x69x70x74x3ex3cx73x63x72x69x70x74x3ex61x6cx65x72x74x28x30x29x3cx2fx73x63x72x69x70x74x3e"
      };

再試一下：

轉(zhuǎn)義就萬(wàn)無(wú)一失了？

naive ! 點(diǎn)個(gè)鏈接一秒中招！

點(diǎn)我

鏈接中如果存在 javacript: 開(kāi)頭的協(xié)議，點(diǎn)擊鏈接時(shí)瀏覽器會(huì)執(zhí)行后面的代碼，這個(gè)時(shí)候光轉(zhuǎn)義是沒(méi)有用的，需要對(duì) url 協(xié)議進(jìn)行白名控制，只允許 http, https, http, mailto 等安全協(xié)議

包括圖片 src 屬性img src="{{xss}}", iframe iframe src="{{xss}}" 都會(huì)存在這樣的問(wèn)題，都需要白名單處理。

處理方案總結(jié)

CSRF

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

如何攻擊？

要合理使用post與get, 為了省事兒，把應(yīng)當(dāng)提交的數(shù)據(jù)，做成get請(qǐng)求。殊不知，這不僅僅是違反了http的標(biāo)準(zhǔn)而已，也同樣會(huì)被黑客所利用。

比如，的網(wǎng)站中，有一個(gè)修改標(biāo)題的操作使用的是 get 請(qǐng)求:

http://example.com/api?changetitle=CSRF

那么惡意攻擊者可以使用:

這樣的話(huà)，用戶(hù)只需要訪(fǎng)問(wèn)一次黑客的網(wǎng)站，其實(shí)就相當(dāng)于在你的網(wǎng)站中，操作了一次。然而用戶(hù)卻沒(méi)有感知。

csrf攻擊升級(jí)

如果你使用了post請(qǐng)求來(lái)處理關(guān)鍵業(yè)務(wù)，并且我們校驗(yàn)了請(qǐng)求中的 cookie 是否包含了當(dāng)前用戶(hù)的登錄狀態(tài)。是否就是萬(wàn)無(wú)一失了呢。我們來(lái)看下面這個(gè)真實(shí)的例子。

docs 中創(chuàng)建文檔的 API 是 https://xxx.xxx/api/explorer/create/ 需求通過(guò) post 請(qǐng)求，帶上 type 類(lèi)型就可以創(chuàng)建一個(gè)新的文檔。

攻擊者在自己的網(wǎng)站中寫(xiě)下以下代碼:

你當(dāng)打開(kāi)攻擊者網(wǎng)站，并且通過(guò)誘導(dǎo)你成功點(diǎn)擊按鈕的時(shí)候，你就成功的發(fā)起了一次創(chuàng)建文檔的請(qǐng)求。之前在我們的網(wǎng)站中就存在這樣的問(wèn)題，現(xiàn)在已經(jīng)修復(fù):

點(diǎn)擊一下:

為什么這種攻擊方法能生效？

瀏覽器表單發(fā)起 POST 的時(shí)候，會(huì)給這次請(qǐng)求自動(dòng)帶上所請(qǐng)求域名的 cookie，這個(gè) cookie 中保存著我們?cè)谠凑局械牡卿浶畔ⅲㄍǔ?sessionid:123456qwertyu 這種)。

應(yīng)對(duì)方法

每個(gè) post 請(qǐng)求都帶上一個(gè)與前用戶(hù) session 綁定的唯一 token，每次收到請(qǐng)求都去校驗(yàn)這個(gè) token 是否合法。

每個(gè) post 請(qǐng)求都去校驗(yàn)請(qǐng)求的 referer 是否來(lái)自于源站，否則就拒絕。但這種方法有弊端，因?yàn)闉g覽器可以設(shè)置請(qǐng)求中不帶 referer，并且低端瀏覽器可以偽造 referer

現(xiàn)代瀏覽器可以通過(guò)設(shè)置 cookie 的 SameSite屬性，來(lái)防止跨域調(diào)用時(shí)帶上包含 sessionid 的 cookie set-cookie: xxx-session=4050e145-043a-4ed0-977a-47d88cd4bbc7; SameSite=Lax

目前我們的文檔采用了 1、3兩種方法。

光說(shuō)不練假把式，攻擊一個(gè)試試

你還別說(shuō)，隨便一找，真找到一個(gè)網(wǎng)站，沒(méi)有校驗(yàn) csrf token，我們?nèi)ビ亚樵囂揭幌?/p>

嚴(yán)正聲明，我是保持學(xué)習(xí)的態(tài)度，去試一試這個(gè)網(wǎng)站是否存在漏洞，所以找了一個(gè)提交工單的功能，來(lái)測(cè)試我們的跨站請(qǐng)求是否執(zhí)行成功。請(qǐng)勿模仿

http://user.zhuolaoshi.com/m/...

為了防止裝逼失敗，先貼一張昨天實(shí)驗(yàn)成功的截圖

攻擊一下：

攻擊成功。

一個(gè)被忽略了很久的漏洞 window.opener

帶有 target="_blank" 跳轉(zhuǎn)的網(wǎng)頁(yè)擁有了瀏覽器 window.opener 對(duì)象賦予的對(duì)原網(wǎng)頁(yè)的跳轉(zhuǎn)權(quán)限，這可能會(huì)被惡意網(wǎng)站利用，例如一個(gè)惡意網(wǎng)站在某 UGC 網(wǎng)站 Po 了其惡意網(wǎng)址，該 UGC 網(wǎng)站用戶(hù)在新窗口打開(kāi)頁(yè)面時(shí)，惡意網(wǎng)站利用該漏洞將原 UGC 網(wǎng)站跳轉(zhuǎn)到偽造的釣魚(yú)頁(yè)面，用戶(hù)返回到原窗口時(shí)可能會(huì)忽視瀏覽器 URL 已發(fā)生了變化，偽造頁(yè)面即可進(jìn)一步進(jìn)行釣魚(yú)或其他惡意行為:

代碼如下

想象一下，你在瀏覽淘寶的時(shí)候，點(diǎn)擊了網(wǎng)頁(yè)聊天窗口的一條外鏈，出去看了一眼，回來(lái)之后淘寶網(wǎng)已經(jīng)變成了另一個(gè)域名的高仿網(wǎng)站，而你卻未曾發(fā)掘，繼續(xù)買(mǎi)東西把自己的錢(qián)直接打到騙子手里。

修復(fù)方法

為 target="_blank" 加上 rel="noopener noreferrer" 屬性。

外跳的地址

缺點(diǎn): 應(yīng)為禁止了跳轉(zhuǎn)帶上 referrer，目標(biāo)網(wǎng)址沒(méi)辦法檢測(cè)來(lái)源地址。

還有一種方法是，所有的外部鏈接都替換為內(nèi)部的跳轉(zhuǎn)連接服務(wù)，點(diǎn)擊連接時(shí)，先跳到內(nèi)部地址，再由服務(wù)器 redirect 到外部網(wǎng)址。現(xiàn)在很多站點(diǎn)都是這么做的,不僅可以規(guī)避風(fēng)險(xiǎn)，還可以控制非法站點(diǎn)的打開(kāi)