總結Web應用中基于瀏覽器的安全漏洞
責編：admin ｜2015-04-21 10:51:52Web瀏覽器或者手機瀏覽器都是在用戶與互聯網之間充當著中介者的角色，在日常生活中我們使用更多的不外乎Google Chrome, Mozilla Firefox, Internet Explorer, Opera, Safari等。隨著用戶越來越多，漸漸的各大瀏覽器也就成為了黑客攻擊的目標。源碼中哪怕是一點點小錯誤，也可能會導致瀏覽器被黑客利用。
本文就將介紹一些基于瀏覽器的漏洞。
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方式發送敏感信息，成為我們不說的秘密！
[轉自FreeBuf黑客與極客（FreeBuf.COM）]