10大最重要的Web安全風險之三----A3,錯誤的認證和會話管理

OWASP TOP10

A1-注入   

A2-跨站腳本（XSS）  

A3-錯誤的認證和會話管理 

A4-不正確的直接對象引用  

A5-僞造跨站請求（CSRF）     -- Cross-Site Request Forgery

A7-限制遠程訪問失敗 

A8-未驗證的重定向和傳遞 

A9-不安全的加密存儲   

A10-不足的傳輸層保護

A3-錯誤的認證和會話管理

OWASP TOP10排名第3的威脅「遭破壞的認證和會話管理」，簡而言之，就是攻擊者竊聽了咱們訪問HTTP時的用戶名和密碼，或者是咱們的會話，從而獲得sessionID，進而冒充用戶進行Http訪問的過程。

因爲HTTP自己是無狀態的，也就是說HTTP的每次訪問請求都是帶有我的憑證的，而SessionID就是爲了跟蹤狀態的，而sessionID自己是很容易在網絡上被監聽的到，因此攻擊者每每經過監聽sessionID來達到進一步攻擊的目的。

這些漏洞每每會存在於Web頁面的「更改個人密碼」、「記住個人密碼」、「忘記密碼」、「安全提問」、「註銷登陸」、「郵件地址」等環節上。

那麼，通常來講，如何來防範這種漏洞呢？

第一，  咱們要總體審視咱們的架構

l        認證機制自己必須是簡單、集中和標準化的；

l        使用容器提供給咱們的標準session id；

l        確保在任什麼時候候用SSL來保護咱們的密碼和session id

第二，  驗證認證的實現機制

l        檢查SSL的實現方法

l        驗證全部與認證相關的函數

l        確保「註銷登陸」的動做可以關閉全部的會話

l        使用OWASP的WebScrab來測試你的應用

如何進行驗證測試

所謂認證，就是創建確信某物或某人是真實的這麼一個過程，authentication來自於希臘語αυθεντικός，即真實的，可信的。認證自己依賴於多個認證因子，在計算機安全領域，認證意味着驗證通信發起者的數字身份，常見的認證過程就是用戶登陸認證，所謂認證測試就是理解系統中的認證機制並找到方法繞過該認證機制。

認證測試須要考慮的點有不少，下面咱們逐一來進行解釋說明

l        在加密通道上傳遞密碼

原則上，用戶的認證必須經過加密信道進行傳輸，咱們在這裏的目的不是要驗證諸如HTTPS是否安全，咱們要驗證的僅僅是用戶的認證信息是否已經被加密了。

在用戶登陸時，最多見的方式是用戶輸入用戶名和密碼後，經過POST方法傳輸，通常來講，認證信息或者是經過不安全的HTTP傳遞，或者是經過加密的HTTPS傳遞。咱們注意到，甚至有些網站在登陸頁面顯示給咱們的是HTTPS，但事實上卻仍然是用HTTP的，最簡單的方法就是用網絡監聽工具，如SnifferPro或Ethereal來判斷是不是真實加密了。

下面，咱們用OWASP的WebScrab截取一些信息來作個例子

假設，登陸頁面要求用戶輸入用戶名和密碼，而後有一個「提交」按鈕，那麼在WebScrab中咱們獲得以下的請求數據：

POST http://www.example.com/AuthenticationServlet HTTP/1.1

Host: www.example.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404

Accept: text/xml,application/xml,application/xhtml+xml

Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://www.example.com/index.jsp

Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!

Content-Type: application/x-www-form-urlencoded

Content-length: 64

delegated_service=218&User=test&Pass=test&Submit=SUBMIT

在上面的數據中，咱們能夠看到，POST方法經過HTTP協議把數據發送到http://www.example.com/AuthenticationServlet，那麼顯然在這時，傳送的數據沒有進行加密，惡意用戶經過監聽網絡就很容易獲得用戶名和密碼。

再看下一個例子，假設是用HTTPS協議，那麼請求的頭數據以下：

POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1

Host: www.example.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404

Accept: text/xml,application/xml,application/xhtml+xml,text/html

Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: https://www.example.com/cgi-bin/login.cgi

Cookie: language=English;

Content-Type: application/x-www-form-urlencoded

Content-length: 50

Command=Login&User=test&Pass=test

可見，上述例子中的數據經加密後被傳送到https://www.example.com:443/cgi-bin/login.cgi，這就確保了數據是加密的而不被其餘人所竊取。

再看下面的一個例子，咱們在一個能夠經過HTTP協議訪問到的頁面上經過HTTPS協議來發送數據

POST https://www.example.com:443/login.do HTTP/1.1

Host: www.example.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404

Accept: text/xml,application/xml,application/xhtml+xml,text/html

Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://www.example.com/homepage.do

Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F

Content-Type: application/x-www-form-urlencoded

Content-length: 45

User=test&Pass=test&portal=ExamplePortal

如上，咱們看到，咱們的請求經過HTTPS引向了https://www.example.com:443/login.do，但若是咱們再看Referer的值，就發現咱們是從HTTP頁http://www.example.com/homepage.do過來的。在這種狀況下，咱們的瀏覽器窗口中並不會告訴咱們如今使用的安全鏈接，而事實上咱們卻正在使用安全鏈接。

在上面的例子中，若是咱們用Get方法，那麼所輸入的用戶名和密碼將會以明文的方式顯示在URL中，這顯然是不可取的。那麼，若是咱們經由Get方法經過HTTPS來傳遞數據是否可行呢，看下面的數據

GET https://www.example.com/success.html?user=test&pass=test HTTP/1.1

Host: www.example.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404

Accept: text/xml,application/xml,application/xhtml+xml,text/html

Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: https://www.example.com/form.html

If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT

If-None-Match: "43a01-5b-4868915f"

從上面的例子能夠看到，用戶名和密碼都以明文的方式在URL裏存在，而不像上面的幾個例子中都在消息體中，但並非說攻擊者就能夠很容易看到這些信息，TLS/SSL畢竟是安全性很高的協議，整個HTTP數據包是加密的，但仍然要注意的是這些用戶名和密碼在傳輸過程當中會被存儲在代理和服務器上，這也就有可能會泄露用戶信息。

        用戶列舉測試法

這種測試，簡而言之是經過與應用的認證機制的交互，嘗試可否得到一些正確的用戶名，這對後面咱們會講到的暴力破解頗有效，確認了正確的用戶名就能用暴力破解去嘗試密碼了。

一般，WEB應用對於用戶名正確的輸入會有一些信息反饋，例如，若是咱們輸錯了密碼，那麼有時會反饋告知咱們系統存在該用戶，或密碼錯誤。因此，做爲測試人員，就要嘗試不一樣的請求來判斷系統是否會有不一樣的返回。

對於HTTP的響應消息測試：

        輸入正確的用戶名和密碼

指望結果：使用WebScrab抓取服務器的返回信息（HTTP 200 Response,消息的長度）

        輸入正確的用戶名/錯誤的密碼

指望結果：從瀏覽器咱們每每會獲得以下的返回

或者是以下返回

甚至是以下的返回

Login for User foo: invalid password

        輸入不存在的用戶名

指望結果：返回可能以下

或者是以下的消息

Login failed for User foo: invalid Account

一般狀況下，對於不一樣的出錯信息，服務器每每返回的消息是同樣的，但若是不一樣，測試人員就要去嘗試在什麼狀況下不一樣，以下：

客戶請求：正確用戶/錯誤密碼——>服務器返回：密碼錯誤

客戶請求：錯誤用戶/錯誤密碼——>服務器返回：用戶不存在。

那麼顯然第一條就告訴咱們咱們輸入的是正確的用戶名，經過這種方式咱們就能夠得到一些正確的用戶名信息。

還有其餘一些嘗試列舉的方法：

        有些應用程序會返回一些特定的出錯信息；

        分析URL以及重定向URL

以下面的URL：

http://www.foo.com/err.jsp?User=baduser&Error=0

http://www.foo.com/err.jsp?User=gooduser&Error=2

上面兩個URL都告訴咱們到了錯誤頁面，但上一條是Error值爲0，下一條Error值爲2，那麼咱們能夠猜想咱們得到了一個正確的用戶名。

        URI探測

有時候，Web服務器在接受一個對目錄訪問請求時，根據目錄是否存在會有不一樣的返回信息，例如在某些網站會給每一個用戶設定一個目錄，那麼咱們若是嘗試訪問某個已存在的目錄時，它可能的返回頁面以下：

403 Forbidden error code

404 Not found error code

舉例：

http://www.foo.com/account1-返回的出錯信息: 403 Forbidden

http://www.foo.com/account2-返回的出錯信息: 404 file Not Found

那麼顯然，account1是現實存在的。

l        探測性用戶帳戶測試法

衆所周知，在系統中每每會有默認帳戶或者很容易被猜到的經常使用帳戶，並且每每不少用戶會使用默認的密碼，一樣，有些應用系統的測試帳戶研發人員有時也會忘記刪除。這個問題事實上是一個漏洞，而這種漏洞每每是因爲如下緣由形成的：

        沒有經驗的IT工程師，他們每每不會更改安裝的架構組件的缺省密碼；

       編程人員在應用中留有後門以便測試，但在發佈時忘記刪除；

        系統的管理員和用戶採用了很簡單的密碼；

        系統有內嵌的，沒法刪除的內部用戶名和密碼

        ……

對於注入Cisco路由器或WebLogic等，他們都有一些默認的用戶名和密碼，咱們能夠直接嘗試，對於一些咱們根本不瞭解的應用，咱們能夠作以下嘗試：

        嘗試如下系統管理員的經常使用帳號——"admin", "administrator", "root", "system", "guest", "operator", "super"，"qa", "test", "test1", "testing"，針對用戶名和密碼組合嘗試，也能夠嘗試諸如"password", "pass123", "password123", "admin",或guest"這些密碼。若是這些都沒法成功，咱們能夠寫一些腳原本嘗試相似的用戶名和密碼組合。

        管理員的密碼有時會與系統名字相關，如咱們測試的應用系統叫「Obscurity」，那麼能夠嘗試用戶名/密碼組合Obscurity/obscurity。

        利用註冊頁面咱們也能夠猜想用戶名和密碼的格式和長度。

        嘗試上述提到的全部用戶名和空密碼。

        查看頁面的源文件，嘗試找到全部引用到用戶名和密碼的信息，好比"If username='admin' then starturl=/admin.asp else /index.asp"

        尋找那些源文件中註釋中可能含有的用戶名和密碼信息；

        …….

l        強力測試（暴力測試）

任何一種技術，在不一樣的人手裏運用所達到的效果是不一樣的，正如暴力測試，也叫暴力破解，安全服務人員和測試人員利用這種技術來驗證是否存在漏洞，而攻擊者則利用其來尋找漏洞。

Web應用系統一般會有一些用戶認證方式，這些方式包括證書、指紋、一次性令牌等等，但更多的，每每是用戶名和密碼的組合，這就使得暴力破解成爲可能。

在對Web應用系統作暴力測試時，首先咱們須要瞭解的是系統的認證機制，一般Web系統會採用如下兩種機制：

        HTTP認證——包含基本存取認證和數字存取認證。

        基於HTML表單的認證。

咱們下面對這些認證方式作一下簡單介紹：

基本存取認證

基本存取認證假設假定用戶會以用戶名和密碼的組合來代表本身的身份，當用戶瀏覽器使用這種機制訪問站點時，web服務器將會返回一個包含「WWW-Authenticate」頭的401響應，且包含了一個「Basic」值，以及被保護的域名（例如，WWW-Authenticate: Basic realm=」wwwProtectedSite」）客戶端會彈出一個須要用戶輸入該域用戶名和密碼的提示框。而後，客戶端瀏覽器返回給服務器一個響應，響應包含「Authorization」頭，還包含「Basic」值以及鏈接了用戶名，冒號，密碼的基於64位的編碼（例如，Authorization: Basic b3dhc3A6cGFzc3dvcmQ=），但惋惜的是，這個回覆只要被攻擊者監聽到就很容易被解碼。

咱們來看一下這個過程：

1.客戶端發送一個標準的HTTP請求

GET /members/docs/file.pdf HTTP/1.1

Host: target

2. web服務器定位到訪問的這個資源是在一個受保護的目錄；

3.服務器發送一個HTTP 401的認證請求；

HTTP/1.1 401 Authorization Required

Date: Sat, 04 Nov 2006 12:52:40 GMT

WWW-Authenticate: Basic realm="User Realm"

Content-Length: 401

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Content-Type: text/html; charset=iso-8859-1

4.瀏覽器彈出要求輸入用戶名和密碼的數據窗口；

5.用戶輸入用戶名和密碼後，包含如下數據後再次提交；

GET /members/docs/file.pdf HTTP/1.1

Host: target

Authorization: Basic b3dhc3A6cGFzc3dvcmQ=

6.服務器把客戶信息和存儲的信息進行比較；

7.若是身份驗證正確，服務器發回被請求的內容，若是失敗，服務器將會返回HTTP

www.owasp.org_Image-basm-sessid.jpg_Basm-sessid

www.owasp.org_Image-basm-sessid2.jpg_Basm-sessid2