白帽子-第三篇 服務器端應用安全

第七章 注入攻擊

2個關鍵條件

　　用戶可以控制輸入;

　　本來程序要執行的代碼，拼接了用戶輸入的數據。

7.3 正確的防護SQL注入

1.使用預編譯語句。

2.使用存儲過程。

3.檢驗數據類型

4.使用安全函數。

第八章 文件上傳漏洞

8.1 文件上傳漏洞概述

文件上傳漏洞是指用戶上傳了一個可執行的腳本文件，並經過此腳本文件得到了執行服務器端命令的能力。

要完成這個攻擊，須要知足以下幾個條件：

　　1.上傳的文件可以被web容器解釋執行。因此文件上傳後所在的目錄要是Web容器所覆蓋到的路徑。

　　2.用戶可以從Web上訪問這個文件。若是文件上傳了，但用戶沒法經過Web訪問，或者沒法得到Web容器解釋這個腳本，那麼也不能稱之爲漏洞。

　　3.用戶上傳的文件若被安全檢驗、格式化、圖片壓縮等功能改變了內容，則也可能致使攻擊失敗。

8.1.2 繞過文件上傳檢驗功能

再上傳文件的檢驗中，不少應用都是經過判斷文件名的後綴名的方法來驗證文件的安全性的。

可是在某些時候，攻擊者手動修改了上傳過程當中的POST包，在文件名後面添加一個%00字節，則能夠截斷某些函數對文件名的判斷。由於在許多語言的函數中，好比C、php等於眼的經常使用字符串處理中，0x00被認爲是終止符。

好比應用本來只容許上傳JPG圖片，那麼能夠構造文件名（須要修改post包）爲xxx.php[\0].JPG，其中[\0]爲十六進制的0x00字符，JAP繞過了應用的上傳文件類型;但對於服務器來講，此文件由於0x00字符截斷的關係，最終卻會變成xxx.php。

8.2功能仍是漏洞！！！

8.2.1Apache文件解析問題

好比在Apache1.x、2.x中，對於文件名的解析存在如下特性。

Apache對於文件名的解析是從後往前解析的，直到碰見一個Apache認識的文件類型爲止。

好比：

Phpshell.php.rar.rar.rar.rar

由於Apache不認識.rar這個文件類型，因此會一直便利後綴到.php，而後認爲這是一個php文件。

（Apache認識的文件定義在Apache的mime.type文件中）

Apache的這個特性，不少工程師在寫應用的時候並不知道，即使知道，可能有的人也會認爲只是WebServer應該作的事情。若是不考慮這些因素的話，寫出的安全檢驗功能可能會存在缺陷。好比rar是一個合法的上傳需求，在應用李值判斷後綴rar，最終用戶上傳的phpshell.php.rar.rar會被執行。

8.2.2 IIS文件解析問題

IIS6在處理文件解析時，也出現過一些漏洞。前面提到的0x00字符截斷文件名，在IIS和windows環境下就曾出現過很是相似的漏洞，不過截斷字符變成了「;」。

當文件名爲abc.asp;xx.jsp，IIS6會將文件解析稱abc.asp

 

此外，IIS曾出現過一個漏洞，由於處理文件夾擴展名出錯，致使將/*.asp/目錄下全部的文件都作爲asp文件進行處理。

8.3 設計安全的文件上傳功能

1.文件上傳的目錄設置爲不可執行

2.判斷文件類型

　　結合MIME Type、後綴檢查等方式。

　　在文件類型檢查中，強烈推薦白名單的方式，黑名單的方式已經無數次被證實是不可靠的。

　　對於圖片的處理，可使用壓縮函數或者resize函數，處理圖片的同時，破壞其中的代碼。

3.使用隨機數改寫文件名和文件路徑

4.單獨設置文件服務器的域名

　　因爲瀏覽器同源策略的關係，一系列客戶端攻擊將失效。

第九章 認證與會話管理

9.1 Who am I？

認證的目的是爲了認出用戶是誰，受權的目的是爲了決定用戶能作什麼。

9.2 密碼那些事兒

密碼的優勢是使用成本低，認證過程實現起來很簡單;缺點是密碼認證是一種比較弱的安全方案。

通常來講，密碼必須以不可逆的加密算法，或者是單向散列函數算法，加密後存在數據庫中，這樣即便是網站管理人員也不可以看到用戶的密碼。

 

目前，黑客們普遍使用的一種破解MD5後密碼的方法是「彩虹表」。

彩虹表的思路是手機儘量多的密碼明文和MD5對應值，爲了不黑客經過採用表查詢出密碼明文，在計算密文的時候，增長一個「salt」以增長明文的複雜度。

9.5 Session Fixation攻擊

在用戶登陸網站的過程當中，若是登陸先後用戶的SessionID沒有發生變化，則會存在Session Fixation問題。

具體的攻擊過程是，攻擊者先獲取到一個未經認證的SessionID，而後用這個SessionID交給用戶認證。認證完成後服務器並無更新SessionID的值，因此攻擊者能夠經過SessionID直接進入Y的帳戶。若是SessionID保存在Cookie中，比較難作到這一點，可是若是保存在URL中，那麼攻擊者只需誘使用戶打開這個連接便可。

解決Session Fixation的正確作法是登陸完成後，重寫SessionID。

9.7 單點登陸（SSO）

從用戶體驗的角度看，SSO無疑讓用戶的使用更加方便;可是從安全的角度，SSO把風險集中在了單點上。

SSO的優勢在於風險集中化，只須要保護好這一點。解決了因爲各個系統產品需求，應用環境、開發工程師的水平存在差別，登陸功能的標準難以統一的問題。

SSO的缺點也很明顯，若是單點一旦被攻破，後果很是嚴重。

下降這種風險的辦法就是在一些敏感系統裏，增長額外的認證機制。

第十章 訪問控制

1.基於URL的控制訪問

　　在基於Java的Web應用中，增長一個filter實現。

2.基於方法的控制訪問

3.基於數據的控制訪問

10.2 垂直權限管理

訪問控制其實是創建用戶和權限之間的對應關係，如今應用普遍的一種方法就是「基於角色的訪問控制」，建成RBAC。Spring Security中的權限管理就是RBAC模型的一個實現。

Spring Security提供兩種權限管理方式，一種是「基於URL的訪問控制」，一種是「基於method的訪問控制「。

對於「基於URL的訪問控制」，Spring Security使用配置文件對訪問URL的用戶權限進行設定。

對於「基於method的訪問控制「，Spring Security使用Java中的斷言，分別在方法調用前和調用後實施訪問控制。

10.3水平權限管理

在RBAC這種「基於角色的訪問控制」模型下，系統只會驗證用戶A是否數據角色RoleX，而不會判斷A是否能訪問只屬於B的數據DataB，所以發生了越權訪問。這樣的問題，咱們稱之爲「水平權限管理問題」，又稱「基於數據的訪問控制」。

<至今還是一個難題！>

10.4 OAuth

第十三章 應用層拒絕服務攻擊

DDOS又稱分佈式拒絕服務，全稱是Distributed Denial of Service。DDOS本是利用合理的請求形成資源過載，致使服務不可用。

預防應用層DDOS：

　　1.使用緩存。相比於讀寫數據庫，查詢緩存所消耗的資源能夠忽略不計。

　　　　缺點：緩存未命中。

　　2.限制「客戶端」每一個請求的頻率。

　　　　缺點：沒法明確的肯定客戶端，（IP僞造，Cookie清空）

　　3.應用代碼性能優化，網站架構優化（CDN，鏡像站點分流）

　　4.驗證碼

　　　　缺點：用戶體驗，被破解。

　　5.讓客戶端解析一段JS，並給出正確的運行結果。由於大部分自動化腳本是直接構造HTTP完成的。

　　6.服務器支持：Apache，Nginx，限制單個IP訪問次數

　　7.Yahoo專利：架構中有一臺master服務器集中計算全部IP請求頻率，並同步到每一臺WebServer上。

資源耗盡攻擊

　　1.Slowloris攻擊，以極低的網速往服務器發送HTTP請求。畸形的HTTP請求，不發送終止符\r\n\r\n，只發送http頭保持連接。

　　2.HTTP POST DOS，發送POST包時，指定一個很是大的Content-Length，而後以極低的速度發包。

　　3.Server Limit DOS，Web Sever對HTTP包頭都是有限制的，好比Apache限制爲8192個字節。攻擊者經過xss攻擊向客戶端寫入一個很是大的Cookie，將沒法訪問該Cookie所在域的任何頁面。

ReDOS

　　若是正則表達式寫的很差，就可能被惡意利用，消耗大量的資源。

　　正則表達式是基於NFA的，他是一個狀態機，每一個狀態和輸入符號均可能有許多個不一樣的下一個狀態。

　　好比，

^(a+)+$

　　當輸入4個a是，他可能有16條路經，當輸入16個a的時候，則有65536中狀況。

　　這極大的增長了正則引擎解析數據時的消耗！！！