前言：

在互聯(lián)網(wǎng)時代，數(shù)據(jù)安全與個人隱私受到了前所未有的挑戰(zhàn)，各種新奇的攻擊技術層出不窮。如何才能更好地保護我們的數(shù)據(jù)？本文主要側重于分析幾種常見的攻擊的類型以及防御的方法。

一、XSS

XSS(Cross-SiteScripting)，跨站腳本攻擊，因為縮寫和CSS重疊，所以只能叫XSS。跨站腳本攻擊是指通過存在安全漏洞的Web網(wǎng)站注冊用戶的瀏覽器內運行非法的HTML標簽或JavaScript進行的一種攻擊。

跨站腳本攻擊有可能造成以下影響:

• 利用虛假輸入表單騙取用戶個人信息。
• 利用腳本竊取用戶的Cookie值，被害者在不知情的情況下，幫助攻擊者發(fā)送惡意請求。
• 顯示偽造的文章或圖片。

XSS的原理是惡意攻擊者往Web頁面里插入惡意可執(zhí)行網(wǎng)頁腳本代碼，當用戶瀏覽該頁之時，嵌入其中Web里面的腳本代碼會被執(zhí)行，從而可以達到攻擊者盜取用戶信息或其他侵犯用戶安全隱私的目的。

XSS的攻擊方式千變萬化，但還是可以大致細分為幾種類型。

1.非持久型XSS（反射型XSS）

非持久型XSS漏洞，一般是通過給別人發(fā)送帶有惡意腳本代碼參數(shù)的URL，當URL地址被打開時，特有的惡意代碼參數(shù)被HTML解析、執(zhí)行。

舉一個例子，比如頁面中包含有以下代碼：

<select><script>document.write(''+'<optionvalue=1>'+location.href.substring(location.href.indexOf('default=')+8)+'</option>');document.write('<optionvalue=2>English</option>');</script></select>

攻擊者可以直接通過URL(類似：https://xxx.com/xxx?default=<script>alert(document.cookie)</script>)注入可執(zhí)行的腳本代碼。不過一些瀏覽器如Chrome其內置了一些XSS過濾器，可以防止大部分反射型XSS攻擊。

非持久型XSS漏洞攻擊有以下幾點特征：

• 即時性，不經(jīng)過服務器存儲，直接通過HTTP的GET和POST請求就能完成一次攻擊，拿到用戶隱私數(shù)據(jù)。
• 攻擊者需要誘騙點擊,必須要通過用戶點擊鏈接才能發(fā)起
• 反饋率低，所以較難發(fā)現(xiàn)和響應修復
• 盜取用戶敏感保密信息

為了防止出現(xiàn)非持久型XSS漏洞，需要確保這么幾件事情：

• Web頁面渲染的所有內容或者渲染的數(shù)據(jù)都必須來自于服務端。
• 盡量不要從URL，document.referrer，document.forms等這種DOMAPI中獲取數(shù)據(jù)直接渲染。
• 盡量不要使用eval,newFunction()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.createElement()等可執(zhí)行字符串的方法。
• 如果做不到以上幾點，也必須對涉及DOM渲染的方法傳入的字符串參數(shù)做escape轉義。
• 前端渲染的時候對任何的字段都需要做escape轉義編碼。

2.持久型XSS（存儲型XSS）

持久型XSS漏洞，一般存在于Form表單提交等交互功能，如文章留言，提交文本信息等，黑客利用的XSS漏洞，將內容經(jīng)正常功能提交進入數(shù)據(jù)庫持久保存，當前端頁面獲得后端從數(shù)據(jù)庫中讀出的注入代碼時，恰好將其渲染執(zhí)行。

舉個例子，對于評論功能來說，就得防范持久型XSS攻擊，因為我可以在評論中輸入以下內容

主要注入頁面方式和非持久型XSS漏洞類似，只不過持久型的不是來源于URL，referer，forms等，而是來源于后端從數(shù)據(jù)庫中讀出來的數(shù)據(jù)。持久型XSS攻擊不需要誘騙點擊，黑客只需要在提交表單的地方完成注入即可，但是這種XSS攻擊的成本相對還是很高。

攻擊成功需要同時滿足以下幾個條件：

• POST請求提交表單后端沒做轉義直接入庫。
• 后端從數(shù)據(jù)庫中取出數(shù)據(jù)沒做轉義直接輸出給前端。
• 前端拿到后端數(shù)據(jù)沒做轉義直接渲染成DOM。

持久型XSS有以下幾個特點：

• 持久性，植入在數(shù)據(jù)庫中
• 盜取用戶敏感私密信息
• 危害面廣

3.如何防御

對于XSS攻擊來說，通常有兩種方式可以用來防御。

1)CSP

CSP本質上就是建立白名單，開發(fā)者明確告訴瀏覽器哪些外部資源可以加載和執(zhí)行。我們只需要配置規(guī)則，如何攔截是由瀏覽器自己實現(xiàn)的。我們可以通過這種方式來盡量減少XSS攻擊。

通常可以通過兩種方式來開啟CSP：

• 設置HTTPHeader中的Content-Security-Policy
• 設置meta標簽的方式

這里以設置HTTPHeader來舉例：

• 只允許加載本站資源

Content-Security-Policy:default-src'self'

• 只允許加載HTTPS協(xié)議圖片

Content-Security-Policy:img-srchttps://*

• 允許加載任何來源框架

Content-Security-Policy:child-src'none'

如需了解更多屬性，請查看Content-Security-Policy文檔

對于這種方式來說，只要開發(fā)者配置了正確的規(guī)則，那么即使網(wǎng)站存在漏洞，攻擊者也不能執(zhí)行它的攻擊代碼，并且CSP的兼容性也不錯。

2)轉義字符

用戶的輸入永遠不可信任的，最普遍的做法就是轉義輸入輸出的內容，對于引號、尖括號、斜杠進行轉義

functionescape(str){str=str.replace(/&/g,'&')str=str.replace(/</g,'<')str=str.replace(/>/g,'>')str=str.replace(/"/g,'&quto;')str=str.replace(/'/g,''')str=str.replace(/`/g,'`')str=str.replace(/\//g,'/')returnstr}

但是對于顯示富文本來說，顯然不能通過上面的辦法來轉義所有字符，因為這樣會把需要的格式也過濾掉。對于這種情況，通常采用白名單過濾的辦法，當然也可以通過黑名單過濾，但是考慮到需要過濾的標簽和標簽屬性實在太多，更加推薦使用白名單的方式。

constxss=require('xss')lethtml=xss('<h3id="title">XSSDemo</h3><script>alert("xss");</script>')//-><h3>XSSDemo</h3><script>alert("xss");</script>console.log(html)

以上示例使用了js-xss來實現(xiàn)，可以看到在輸出中保留了h3標簽且過濾了script標簽。

3)HttpOnlyCookie。

這是預防XSS攻擊竊取用戶cookie最有效的防御手段。Web應用程序在設置cookie時，將其屬性設為HttpOnly，就可以避免該網(wǎng)頁的cookie被客戶端惡意JavaScript竊取，保護用戶cookie信息。

二、CSRF

CSRF(CrossSiteRequestForgery)，即跨站請求偽造，是一種常見的Web攻擊，它利用用戶已登錄的身份，在用戶毫不知情的情況下，以用戶的名義完成非法操作。

1.CSRF攻擊的原理

下面先介紹一下CSRF攻擊的原理：

完成CSRF攻擊必須要有三個條件：

• 用戶已經(jīng)登錄了站點A，并在本地記錄了cookie
• 在用戶沒有登出站點A的情況下（也就是cookie生效的情況下），訪問了惡意攻擊者提供的引誘危險站點B(B站點要求訪問站點A)。
• 站點A沒有做任何CSRF防御

我們來看一個例子：當我們登入轉賬頁面后，突然眼前一亮驚現(xiàn)"XXX隱私照片，不看后悔一輩子"的鏈接，耐不住內心躁動，立馬點擊了該危險的網(wǎng)站（頁面代碼如下圖所示），但當這頁面一加載，便會執(zhí)行submitForm這個方法來提交轉賬請求，從而將10塊轉給黑客。

2.如何防御

防范CSRF攻擊可以遵循以下幾種規(guī)則：

• Get請求不對數(shù)據(jù)進行修改
• 不讓第三方網(wǎng)站訪問到用戶Cookie
• 阻止第三方網(wǎng)站請求接口
• 請求時附帶驗證信息，比如驗證碼或者Token

1)SameSite

可以對Cookie設置SameSite屬性。該屬性表示Cookie不隨著跨域請求發(fā)送，可以很大程度減少CSRF的攻擊，但是該屬性目前并不是所有瀏覽器都兼容。

2)RefererCheck

HTTPReferer是header的一部分，當瀏覽器向web服務器發(fā)送請求時，一般會帶上Referer信息告訴服務器是從哪個頁面鏈接過來的，服務器籍此可以獲得一些信息用于處理。可以通過檢查請求的來源來防御CSRF攻擊。正常請求的referer具有一定規(guī)律，如在提交表單的referer必定是在該頁面發(fā)起的請求。所以通過檢查http包頭referer的值是不是這個頁面，來判斷是不是CSRF攻擊。

但在某些情況下如從https跳轉到http，瀏覽器處于安全考慮，不會發(fā)送referer，服務器就無法進行check了。若與該網(wǎng)站同域的其他網(wǎng)站有XSS漏洞，那么攻擊者可以在其他網(wǎng)站注入惡意腳本，受害者進入了此類同域的網(wǎng)址，也會遭受攻擊。出于以上原因，無法完全依賴RefererCheck作為防御CSRF的主要手段。但是可以通過RefererCheck來監(jiān)控CSRF攻擊的發(fā)生。

3)AntiCSRFToken

目前比較完善的解決方案是加入Anti-CSRF-Token。即發(fā)送請求時在HTTP請求中以參數(shù)的形式加入一個隨機產(chǎn)生的token，并在服務器建立一個攔截器來驗證這個token。服務器讀取瀏覽器當前域cookie中這個token值，會進行校驗該請求當中的token和cookie當中的token值是否都存在且相等，才認為這是合法的請求。否則認為這次請求是違法的，拒絕該次服務。

這種方法相比Referer檢查要安全很多，token可以在用戶登陸后產(chǎn)生并放于session或cookie中，然后在每次請求時服務器把token從session或cookie中拿出，與本次請求中的token進行比對。由于token的存在，攻擊者無法再構造出一個完整的URL實施CSRF攻擊。但在處理多個頁面共存問題時，當某個頁面消耗掉token后，其他頁面的表單保存的還是被消耗掉的那個token，其他頁面的表單提交時會出現(xiàn)token錯誤。

4)驗證碼

應用程序和用戶進行交互過程中，特別是賬戶交易這種核心步驟，強制用戶輸入驗證碼，才能完成最終請求。在通常情況下，驗證碼夠很好地遏制CSRF攻擊。但增加驗證碼降低了用戶的體驗，網(wǎng)站不能給所有的操作都加上驗證碼。所以只能將驗證碼作為一種輔助手段，在關鍵業(yè)務點設置驗證碼。

三、點擊劫持

點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將需要攻擊的網(wǎng)站通過iframe嵌套的方式嵌入自己的網(wǎng)頁中，并將iframe設置為透明，在頁面中透出一個按鈕誘導用戶點擊。

1.特點

• 隱蔽性較高，騙取用戶操作
• "UI-覆蓋攻擊"
• 利用iframe或者其它標簽的屬性

2.點擊劫持的原理

用戶在登陸A網(wǎng)站的系統(tǒng)后，被攻擊者誘惑打開第三方網(wǎng)站，而第三方網(wǎng)站通過iframe引入了A網(wǎng)站的頁面內容，用戶在第三方網(wǎng)站中點擊某個按鈕（被裝飾的按鈕），實際上是點擊了A網(wǎng)站的按鈕。
接下來我們舉個例子：我在優(yōu)酷發(fā)布了很多視頻，想讓更多的人關注它，就可以通過點擊劫持來實現(xiàn)

iframe{width:1440px;height:900px;position:absolute;top:-0px;left:-0px;z-index:2;-moz-opacity:0;opacity:0;filter:alpha(opacity=0);}button{position:absolute;top:270px;left:1150px;z-index:1;width:90px;height:40px;}</style>......<button>點擊脫衣</button><imgsrc="http://pic1.win4000.com/wallpaper/2018-03-19/5aaf2bf0122d2.jpg"><iframesrc="http://i.youku.com/u/UMjA0NTg4Njcy"scrolling="no"></iframe>

從上圖可知，攻擊者通過圖片作為頁面背景，隱藏了用戶操作的真實界面，當你按耐不住好奇點擊按鈕以后，真正的點擊的其實是隱藏的那個頁面的訂閱按鈕，然后就會在你不知情的情況下訂閱了。

3.如何防御

1）X-FRAME-OPTIONS

X-FRAME-OPTIONS是一個HTTP響應頭，在現(xiàn)代瀏覽器有一個很好的支持。這個HTTP響應頭就是為了防御用iframe嵌套的點擊劫持攻擊。

該響應頭有三個值可選，分別是

• DENY，表示頁面不允許通過iframe的方式展示
• SAMEORIGIN，表示頁面可以在相同域名下通過iframe的方式展示
• ALLOW-FROM，表示頁面可以在指定來源的iframe中展示

2）JavaScript防御

對于某些遠古瀏覽器來說，并不能支持上面的這種方式，那我們只有通過JS的方式來防御點擊劫持了。

<head><styleid="click-jack">html{display:none!important;}</style></head><body><script>if(self==top){varstyle=document.getElementById('click-jack')document.body.removeChild(style)}else{top.location=self.location}</script></body>

以上代碼的作用就是當通過iframe的方式加載頁面時，攻擊者的網(wǎng)頁直接不顯示所有內容了。

給大家推薦一個好用的BUG監(jiān)控工具Fundebug，歡迎免費試用！

四、URL跳轉漏洞

定義：借助未驗證的URL跳轉，將應用程序引導到不安全的第三方區(qū)域，從而導致的安全問題。

1.URL跳轉漏洞原理

黑客利用URL跳轉漏洞來誘導安全意識低的用戶點擊，導致用戶信息泄露或者資金的流失。其原理是黑客構建惡意鏈接(鏈接需要進行偽裝,盡可能迷惑),發(fā)在QQ群或者是瀏覽量多的貼吧/論壇中。
安全意識低的用戶點擊后,經(jīng)過服務器或者瀏覽器解析后，跳到惡意的網(wǎng)站中。

惡意鏈接需要進行偽裝,經(jīng)常的做法是熟悉的鏈接后面加上一個惡意的網(wǎng)址，這樣才迷惑用戶。

諸如偽裝成像如下的網(wǎng)址，你是否能夠識別出來是惡意網(wǎng)址呢？

http://gate.baidu.com/index?act=go&url=http://t.cn/RVTatrdhttp://qt.qq.com/safecheck.html?flag=1&url=http://t.cn/RVTatrdhttp://tieba.baidu.com/f/user/passport?jumpUrl=http://t.cn/RVTatrd

2.實現(xiàn)方式：

• Header頭跳轉
• Javascript跳轉
• META標簽跳轉

這里我們舉個Header頭跳轉實現(xiàn)方式：

<?php$url=$_GET['jumpto'];header("Location:$url");?>http://www.wooyun.org/login.php?jumpto=http://www.evil.com

這里用戶會認為www.wooyun.org都是可信的，但是點擊上述鏈接將導致用戶最終訪問www.evil.com這個惡意網(wǎng)址。

3.如何防御

1)referer的限制

如果確定傳遞URL參數(shù)進入的來源，我們可以通過該方式實現(xiàn)安全限制，保證該URL的有效性，避免惡意用戶自己生成跳轉鏈接

2)加入有效性驗證Token

我們保證所有生成的鏈接都是來自于我們可信域的，通過在生成的鏈接里加入用戶不可控的Token對生成的鏈接進行校驗，可以避免用戶生成自己的惡意鏈接從而被利用，但是如果功能本身要求比較開放，可能導致有一定的限制。

五、SQL注入

SQL注入是一種常見的Web安全漏洞，攻擊者利用這個漏洞，可以訪問或修改數(shù)據(jù)，或者利用潛在的數(shù)據(jù)庫漏洞進行攻擊。

1.SQL注入的原理

我們先舉一個萬能鑰匙的例子來說明其原理：

<formaction="/login"method="POST"><p>Username:<inputtype="text"name="username"/></p><p>Password:<inputtype="password"name="password"/></p><p><inputtype="submit"value="登陸"/></p></form>

后端的SQL語句可能是如下這樣的：

letquerySQL=`SELECT*FROMuserWHEREusername='${username}'ANDpsw='${password}'`;//接下來就是執(zhí)行sql語句...

這是我們經(jīng)常見到的登錄頁面，但如果有一個惡意攻擊者輸入的用戶名是admin'--，密碼隨意輸入，就可以直接登入系統(tǒng)了。why!----這就是SQL注入

我們之前預想的SQL語句是:

SELECT*FROMuserWHEREusername='admin'ANDpsw='password'

但是惡意攻擊者用奇怪用戶名將你的SQL語句變成了如下形式：

SELECT*FROMuserWHEREusername='admin'--'ANDpsw='xxxx'

在SQL中,'--是閉合和注釋的意思，--是注釋后面的內容的意思，所以查詢語句就變成了：

SELECT*FROMuserWHEREusername='admin'

所謂的萬能密碼,本質上就是SQL注入的一種利用方式。

一次SQL注入的過程包括以下幾個過程：

• 獲取用戶請求參數(shù)
• 拼接到代碼當中
• SQL語句按照我們構造參數(shù)的語義執(zhí)行成功

SQL注入的必備條件：

1.可以控制輸入的數(shù)據(jù)
2.服務器要執(zhí)行的代碼拼接了控制的數(shù)據(jù)。

我們會發(fā)現(xiàn)SQL注入流程中與正常請求服務器類似，只是黑客控制了數(shù)據(jù)，構造了SQL查詢，而正常的請求不會SQL查詢這一步，SQL注入的本質:數(shù)據(jù)和代碼未分離，即數(shù)據(jù)當做了代碼來執(zhí)行。

2.危害

• 獲取數(shù)據(jù)庫信息管理員后臺用戶名和密碼獲取其他數(shù)據(jù)庫敏感信息：用戶名、密碼、手機號碼、身份證、銀行卡信息……整個數(shù)據(jù)庫：脫褲
• 獲取服務器權限
• 植入Webshell，獲取服務器后門
• 讀取服務器敏感文件

3.如何防御

• 嚴格限制Web應用的數(shù)據(jù)庫的操作權限，給此用戶提供僅僅能夠滿足其工作的最低權限，從而最大限度的減少注入攻擊對數(shù)據(jù)庫的危害
• 后端代碼檢查輸入的數(shù)據(jù)是否符合預期，嚴格限制變量的類型，例如使用正則表達式進行一些匹配處理。
• 對進入數(shù)據(jù)庫的特殊字符（'，"，，<，>，&，*，;等）進行轉義處理，或編碼轉換。基本上所有的后端語言都有對字符串進行轉義處理的方法，比如lodash的lodash._escapehtmlchar庫。
• 所有的查詢語句建議使用數(shù)據(jù)庫提供的參數(shù)化查詢接口，參數(shù)化的語句使用參數(shù)而不是將用戶輸入變量嵌入到SQL語句中，即不要直接拼接SQL語句。例如Node.js中的mysqljs庫的query方法中的?占位參數(shù)。

六、OS命令注入攻擊

OS命令注入和SQL注入差不多，只不過SQL注入是針對數(shù)據(jù)庫的，而OS命令注入是針對操作系統(tǒng)的。OS命令注入攻擊指通過Web應用，執(zhí)行非法的操作系統(tǒng)命令達到攻擊的目的。只要在能調用Shell函數(shù)的地方就有存在被攻擊的風險。倘若調用Shell時存在疏漏，就可以執(zhí)行插入的非法命令。

命令注入攻擊可以向Shell發(fā)送命令，讓Windows或Linux操作系統(tǒng)的命令行啟動程序。也就是說，通過命令注入攻擊可執(zhí)行操作系統(tǒng)上安裝著的各種程序。

1.原理

黑客構造命令提交給web應用程序，web應用程序提取黑客構造的命令，拼接到被執(zhí)行的命令中，因黑客注入的命令打破了原有命令結構，導致web應用執(zhí)行了額外的命令，最后web應用程序將執(zhí)行的結果輸出到響應頁面中。

我們通過一個例子來說明其原理，假如需要實現(xiàn)一個需求：用戶提交一些內容到服務器，然后在服務器執(zhí)行一些系統(tǒng)命令去返回一個結果給用戶

//以Node.js為例，假如在接口中需要從github下載用戶指定的repoconstexec=require('mz/child_process').exec;letparams={/*用戶輸入的參數(shù)*/};exec(`gitclone${params.repo}/some/path`);

如果params.repo傳入的是https://github.com/admin/admin.github.io.git確實能從指定的gitrepo上下載到想要的代碼。
但是如果params.repo傳入的是https://github.com/xx/xx.git&&rm-rf/*&&恰好你的服務是用root權限起的就糟糕了。

2.如何防御

• 后端對前端提交內容進行規(guī)則限制（比如正則表達式）。
• 在調用系統(tǒng)命令前對所有傳入?yún)?shù)進行命令行參數(shù)轉義過濾。
• 不要直接拼接命令語句，借助一些工具做拼接、轉義預處理，例如Node.js的shell-escapenpm包

以上就是常見的web安全漏洞及防御方法！