總結Web應用中基於瀏覽器的安全漏洞

‍‍‍‍‍1.瀏覽器緩存

每次打開一個網站，網頁的內容會緩存到用戶的機器中。若是這些內容在其餘網頁中須要從新加載，瀏覽器加載的是緩存，而不是再次下載內容。若是一些Web應用商店以及顯示用戶敏感信息（好比地址，信用卡信息，用戶名）這些信息也是會記錄到緩存中的，所以能夠經過檢測瀏覽器緩存檢索到這些信息的。

在IE瀏覽器中這些信息存儲在：

C:\Users\<user_name>\AppData\Local\Microsoft\Windows\Temporary Internet Files

在Firefox瀏覽器：

C:\Users\<user_name>\AppData\Local\Mozilla\Firefox\Profiles\<profile-id>\Cache 或者在地址欄輸入about:cache

在Chrome瀏覽器中的地址欄輸入chrome://cache，其存儲在

C:\Users\<user_name>\AppData\Local\Google\Chrome\User Data\Default\Cache

驗證

咱們在Mozilla Firefox 瀏覽器下實驗，訪問幾個網頁事後而後退出網站。在地址欄輸入about:cache.這就能夠顯示在瀏覽器中的緩存信息了，經過緩存列表以及其中的內容選擇你感興趣的內容。

下面的截圖就顯示了用戶儀表盤，在用戶儀表盤中可能含有高危敏感信息，好比地址，電話號碼，信用卡信息，E-mail等等。

 

打開一個特定的緩存條目，在用戶儀表盤中咱們能夠看到地址，電話號碼，訂單歷史等等

‍‍‍‍小貼士

這個問題能夠經過在響應頭中設置合適的緩存控制屬性解決。

主要有如下兩種緩存屬性：

Cache-control: no-cache

no-cache屬性表示，瀏覽器不使用特定的請求-響應緩存信息。瀏覽器存儲緩存信息，而不是從緩存中讀取內容，每一次都會向服務器發送請求。換句話來講，緩存只是保留在瀏覽器中，對於攻擊者或者惡意用來來講就十分容易的讀取到相關信息。

Cache-control: no-store

no-store屬性表示，請求-響應不會被緩存或者存儲到瀏覽器中。

使用HTML meta標籤

你還可使用meta標籤實現對緩存的控制，設置以下：

<meta http-equiv=」Cache-Control」 content=」no-cache」 /> <meta http-equiv=」Cache-Control」 content=」no-store」 />

若是在HTTP響應頭中手動添加cache-control頭，而且設置 no-cache。以下圖所示，瀏覽器依舊會對頁面進行緩存

若是訪問瀏覽器緩存，那麼咱們就能夠在用戶儀表盤中緩存頁面中找到它。使用離線模式打開會顯示詳細的細節，以下圖：

若是cache-control頭設置爲no-store, no-cache。咱們在用戶儀表盤中就找不到了。

所以，開發者須要分析網頁的內容以及調整適當的cache-control屬性。

2. 瀏覽器內存中的密碼

大多數的站點以及服務器使用hash或者Encrypt方式進行加密，但這種方式不適用於保存在瀏覽器內存中的密碼。GET請求以及POST請求在瀏覽器內存中幾乎就是透明的，攻擊者可經過相似WinHex的工具查看到這些敏感信息。

驗證

訪問站點，輸入有效的憑證，以下截圖。

 

下面的截圖顯示了用戶名以及密碼傳遞給服務器

從網站中退出，但請不要關閉瀏覽器，而後打開相似WinHex的工具，定位到正確的路徑。

首先打開內存

而後選擇瀏覽器（本列中咱們使用的FireFox），選擇全部內存

在數據中搜索用戶名，咱們能夠獲取完整的登陸請求信息。

從這裏開始，攻擊者就能夠盜取用戶登陸憑證。

小貼士

這個問題出如今瀏覽器/本地機器上，使用SSL並不會下降危險性。用戶並不能阻止瀏覽器記錄密碼或者其餘一些敏感信息，這個問題的解決方法即是使用哈希加密。

下面是加鹽哈希的工做流程：

存儲在數據庫中的MD5哈希密碼。當一個用戶請求登陸頁面時，服務器隨機生成一個數，這個數就被稱爲salt（鹽）而後返回給用戶的頁面。一個Javascript腳本出如今用戶機器上，對用戶輸入的密碼進行MD5計算。接着加鹽後再計算哈希值，這個哈希值會發送到服務器，服務器從數據庫中選擇密碼的哈希值結合鹽值並計算MD5值。若是這個值匹配，用戶就成功登陸。

每一次的鹽值都不盡相同，所以攻擊者就算從瀏覽器中內存中獲取到了哈希值，這個哈希值也是沒用的。

另外一個實現方法，使用一個Javascript腳本實現當用戶退出事後就強行關閉瀏覽器，這麼作瀏覽器的內存就會被重置。

3. 返回刷新攻擊

瀏覽器的返回功能，你們都熟悉。經過前進後退這個功能，咱們能夠顯示最近瀏覽的頁面。此外，瀏覽器也會留意到像用戶名，密碼，銀行卡帳號等變量。這是由於經過POST方式傳送給服務器的同時對頁面進行了抓取。若是用戶登陸網站，執行一些操做事後退出了，攻擊者在同一臺機器上進行登陸，他是能夠在瀏覽器窗口中看到註銷頁面的，而後他一直按後退按鈕，直到顯示成功登陸那個頁面，而後單擊刷新按鈕，瀏覽器自動從新提交請求的全部信息。

驗證

登陸到網頁並進入修改密碼的頁面，輸入當前密碼，以及修改後的密碼點擊提交。

更改密碼的一系列請求和響應，請看下面的截圖

請求

響應

密碼更改爲功

瀏覽網頁，而後註銷，註銷事後離開機器前沒有關閉瀏覽器。若是攻擊者能進行物理訪問這臺機器，只需簡單的單擊後退按鈕的下拉菜單，只須要找到更改密碼後的頁面就好了。

當點擊進入一個特殊的頁面，瀏覽器會顯示已通過期的警示頁面。

此刻，攻擊者就可使用瀏覽器代理工具，好比Burp並配置瀏覽器經過代理髮送請求。

在錯誤頁面中單擊刷新按鈕，瀏覽器會彈出一個提示窗口

使用配置好的代理工具，攻擊者能夠看到發送給服務器的請求，而且能夠截取到用戶的密碼

變種攻擊

網站成功登陸事後使用重定向，登陸頁面含有驗證碼。若是用戶使用正確的用戶名及密碼可是驗證碼錯誤，那麼網站會返回到登陸頁面，並提示用戶錯誤信息。

在這種狀況下，攻擊者一樣可使用後退和刷新功能盜取用戶名密碼。即便驗證碼錯誤，攻擊者也可以獲取像用戶名以及密碼這些敏感信息。

驗證

訪問網站的登陸頁面，輸入正確的用戶名和錯誤的密碼

對用戶名以及密碼驗證事後，服務器響應「200 OK」和錯誤描述「用戶名/密碼錯誤」

單擊後退按鈕，訪問之前可以正確登入的頁面。

瀏覽器警告說，憑證過時了，同時要求用戶從新發送數據到服務器。

在瀏覽器和服務器之間配置代理，對傳輸到服務器的數據進行攔截，而後點擊發送按鈕

用戶的帳號密碼能夠經過明文顯示給咱們

問題分析

在這個例子中，修改密碼的頁面爲「changepass.aspx」 後面出現的頁面是「changepass1.aspx」。「changepass1.aspx」頁面是在提供當前密碼以及新密碼事後再出現的。因此，瀏覽器記錄了發送到「changepass1.aspx」的請求。咱們來理一理整個順序。

用戶訪問「changepass.aspx」頁面。

用戶輸入當前密碼，新的密碼，最後確認新的密碼。

密碼以及提交請求發送到「changepass1.aspx」

用戶在「changepass1.aspx」頁面進行身份驗證

當攻擊者打開「changepass1.aspx」頁面，請求就會發送到「changepass1.aspx」。這個請求裏就包含了當前密碼，新的密碼以及確認的密碼。

4. 自動保存

當用戶提交帳號以及密碼以後，瀏覽器會提示是否記住密碼。若是用戶單擊「記住密碼」，瀏覽器會存儲密碼，在下一次訪問該站點時就會自動填寫相關內容。這個功能確實是方便了用戶，用戶不須要記住過多的密碼，可是若是用戶是在公用機器上使用這個功能，那麼後果又是怎樣？攻擊者能夠十分輕鬆的找到帳號密碼。

即便密碼通過加密，或者是有一個主密碼來保護（經過一個密碼來訪問存儲的密碼）。攻擊者能夠經過訪問這個站點來檢索存儲在瀏覽器中的密碼，攻擊者只須要鍵入用戶名，瀏覽器就會自動填充密碼字段，只須要運行相似Burp的工具攔截瀏覽器請求就能夠獲取密碼。

這裏，輸入用戶名和密碼以後，瀏覽器彈出提示咱們是否保存密碼

 

若是用戶確認保存密碼以後，密碼就會存儲到瀏覽器中。在FireFox中你能夠經過點擊工具→選項→安全→保存的密碼

如今假設瀏覽器中保存的密碼有一個主密碼來管理，只有經過密碼驗證以後才能看到上面截圖中的信息

在這個例子中，攻擊者須要一箇中間代理工具來攔截傳送到服務器的請求。

到站點中，雙擊用戶名字段的表框，它就會顯示存儲的用戶名列表。點擊其中一個用戶名，在密碼字段瀏覽器就會自動填寫了，從攔截請求中能夠十分容易的找到帳號以及密碼信息。

小貼士

在目前絕大多數瀏覽器產品的最新版本中，這個自動保存功能依舊存在。在這個特容易撞庫的年代，密碼多了確實很差記，這個就看你們本身的取捨了。

5. 瀏覽器歷史記錄

當用戶提交數據的時候，不是GET請求就是POST請求。GET請求的話是能夠經過觀察URL自己發現端倪的，然而POST請求存在於請求的主體，如下兩張截圖就顯示了GET請求以及POST請求的用戶數據。

因此的GET請求均可以經過瀏覽器的歷史記錄以及緩存進行訪問，即便註銷並關閉瀏覽器，這些數據也是能夠經過歷史記錄查看的。

GET request:

POST request:

驗證

用戶在填寫了用戶名和密碼以後，點擊登入按鈕，這裏會提交一個GET請求

使用Burp攔截請求，截圖以下

因此，攻擊者能夠經過歷史記錄獲取信息

一樣的，若是站點經過GET方式發送敏感信息，攻擊者也是能夠經過瀏覽器歷史查看到的。

小貼士

讓不使用GET方式發送敏感信息，成爲咱們不說的祕密！