4.2 Web驗證機制存在的漏洞

4.2.1 用戶名和密碼可以進行預測

用戶名和密碼都能夠預測了，理所當然的，這里的漏洞就很大了。

（1）可預測的用戶名。一些應用程序根據某種順序自動生成賬戶名，當然，現在郵箱、手機、QQ號碼成為用戶名的可能性越來越高，攻擊者們也越來越省事了；一些應用程序在大批量創建用戶之后，并自動指定初始密碼，然后通過某種方式（郵件、短信）將密碼分配給用戶。

（2）可預測的初始化密碼。讓攻擊者能夠預測其他應用程序用戶的密碼，基于內網的企業應用程序經常存在這種漏洞。如果所有用戶都收到相同的密碼，或者根據用戶名和職務、ID、手機號碼等創建的密碼，這種密碼非常容易被攻破。比這個更加糟糕的是，很多人有了初始密碼之后，幾乎不做修改，就一直使用；如果初始密碼過于復雜，很多人會從一個極端走向另外一個極端，使用盡可能簡易的密碼。

4.2.2 重置密碼和忘記密碼漏洞

1．重置密碼功能漏洞

一般的密碼重置的設計都是分為以下四步。

第一步：輸入賬戶名。

第二步：驗證身份。

第三步：重置密碼。

第四步：完成。

通常漏洞是會存在于步驟二或者步驟三中。下面來看看常見的一些重置密碼漏洞的方式及漏洞產生的原因。

（1）手機驗證碼爆破從而重置密碼。

這種設計一般是在找回密碼時會給指定的手機號發送一個用于驗證身份的驗證碼，然后只要用戶輸入正確的驗證碼，就可以進行密碼重置了。

這種設計產生重置密碼漏洞的情況，一般是由于驗證設計過于簡單，而且對校驗碼的校驗使用次數沒有進行限制，導致正確的驗證碼可以被枚舉爆破，從而重置密碼。此方法也是最常見的重置密碼的方式，因為大多數廠商最開始的設置都是采取的4～6位純數字驗證碼的驗證方式，而且是沒有防止爆破的設計。

漏洞展示

1 找回密碼，選擇手機找回，如圖4-10所示，點擊獲取驗證碼后，驗證碼位置隨便寫4個數字，密碼寫成自己想要改的密碼。

2 用burpsuite抓包，然后選擇4位純數字對驗證碼位置的爆破。4位純數字，1萬種情況，普通配置的計算機和網速2分鐘就可以跑出來。如圖4-11所示，跑出來正確的驗證碼，就已經成功重置用戶密碼了。

（2）郵箱驗證碼爆破從而重置密碼。

這種設計一般是在找回密碼時會給指定郵箱發送一個用于校驗的URL鏈接，鏈接中一般會有一個參數就是用于驗證身份的驗證碼，然后用戶點擊指定url就可以進入重置密碼的頁面從而去重置密碼了。

這種設計產生重置密碼漏洞的情況，也是由于重置密碼鏈接中的驗證碼參數設計過于簡單，可以被爆破，從而可以重置密碼。

（3）偷梁換柱——給指定郵箱發送URL重置密碼鏈接。

這種設計一般是在找回密碼時會給指定郵箱發送一個用于校驗的URL鏈接，鏈接中一般肯定會存在兩個比較重要的參數，一個是用戶名（或者手機號、QQ郵箱之類的能代表用戶身份的參數），另一個就是一個加密的字符串（通過服務器端的某種算法生成的用來驗證用戶身份的參數）。然后用戶在重置密碼時，單擊郵箱中的重置密碼鏈接，就可以重置賬號密碼了。

這種設計產生重置密碼漏洞的情況，一般是由于重置密碼鏈接中的表示用戶名的參數和用于校驗的加密字符串參數沒有進行一一對應，導致可以被黑客偷梁換柱，從而重置密碼。

也就是說，那個驗證身份的加密字符串是萬能的。例如，生成的重置密碼URL為：http://www. xx.com/xx.php? username=admin1&code=qwertyyu，由于這里的參數code在服務器端驗證時，只要其自身的算法滿足服務器端的驗證就直接通過了，不會去驗證這個code是不是和aasdsdff賬戶對應的。從而，黑客可以直接利用URL:http://www.xx.com/xx.php? username=admin2&code=qwertyyu重置賬號admin2的密碼。

（4）偷梁換柱——疏忽驗證用戶身份。

這種設計一般是在最后一步設置新密碼時，程序員往往會疏忽驗證用戶身份，從而被偷梁換柱，重置密碼。這種一般是由于前面步驟二中已經驗證了身份，然后步驟三重置密碼時沒有對用戶身份進行持續性的驗證導致的。

漏洞展示

1 注冊賬號test，點擊忘記密碼，收到一封重置密碼的郵件。

http://ovs.ifl ytek.com/public/change_password? &md1=
  wffITuct8rJhZ63vwwCRcusSIrrNRho

2 訪問重置密碼，如圖4-12所示。

3 抓包修改賬號為admin，如圖4-13所示。

4 最后賬號admin成功登錄，如圖4-14所示。

（5）程序員泄露。

有時雖然加密字符串的算法很復雜，但是在重置密碼的過程中，如果程序員自己不小心將其泄露了，那也可以被重置密碼。這種屬于程序員自己沒有將開發調試時的一些數據在正式上線前去掉導致的。

（6）加密算法過于簡單而被破解。

有時利用郵箱的URL重置密碼，雖然不存在爆破的情況，但是由于加密算法過于簡單而被破解，導致密碼重置。這種一般都是一些簡單的加密算法，將一些關鍵參數如用戶名、郵箱、手機號、驗證字符、時間戳等，進行一定的規則的組合，然后進行md5、base64加密。

（7）沒有對關鍵的身份驗證的參數進行追蹤。

在重置密碼的4個步驟中，有時當你輸入賬戶名之后，直接去修改URL或者前端代碼去進行重置密碼，從而也能成功地繞過身份驗證去重置密碼。這種一般是由于沒有對關鍵的身份驗證的參數進行追蹤導致的。

（8）沒有驗證手機號或者郵箱身份。

有時修改密碼會給郵箱或者手機發送一個新密碼，那么抓包將手機號或者郵箱改成我們自己的會怎么樣呢？這種一般是由于沒有驗證手機號或者郵箱的對應身份導致的。

（9）利用CSRF破解。

有時CSRF利用好的話，也可以重置用戶甚至是管理員的密碼。這種一般是由于登錄賬號后重置密碼或者綁定郵箱、手機號時沒有token也沒有驗證refer導致的。

（10）利用XSS漏洞破解。

有時XSS漏洞也可以重置密碼，當然這種也是因為本身重置密碼中就有其他的設計缺陷。這種一般是用XSS劫持了賬戶后，由于某些奇怪的設計造成的。

2．忘記密碼功能漏洞

忘記密碼之后怎么辦？大多數人會依賴網站的“密碼找回”功能找回密碼。但據官方公布的資料顯示，密碼找回功能或存在漏洞，導致用戶賬號泄密，甚至出現被盜的威脅。

“某些大型支付網站，通過密碼找回功能的漏洞，一旦獲取方法，只需5分鐘就可以侵入客戶賬號”。來自tools網站的著名“白帽子”（維護網絡安全的專業人士）Tang3曾經說到，他曾與團隊一同發現并修補過類似的安全漏洞。通過這類漏洞，黑客能夠盜取任意賬號的密碼，出現用戶隱私泄露、好友關系詐騙，甚至財產直接受損的嚴重后果。

其主要原因是網站開發人員的安全意識不足，“密碼找回”功能存在設計缺陷。例如，密碼找回的憑證太弱，就會容易被黑客暴力破解；又或者有的網站直接將密保問題的答案寫在網頁源代碼中，黑客只需通過填寫他人注冊郵箱，進行密碼找回的操作，查看網頁源代碼就能得到密保問題答案，從而達到篡改他人賬號密碼的目的。

4.2.3 對驗證登錄的暴力破解攻擊

暴力破解攻擊是指攻擊者通過系統地組合所有可能性（如登錄時用到的賬戶名、密碼），嘗試所有的可能性破解用戶的賬戶名、密碼等敏感信息。攻擊者會經常使用自動化腳本組合出正確的用戶名和密碼。

對防御者而言，給攻擊者留的時間越長，其組合出正確的用戶名和密碼的可能性就越大。這就是為什么時間在檢測暴力破解攻擊時是如此重要的原因了。

暴力破解攻擊是通過巨大的嘗試次數獲得一定成功率的。因此在Web應用程序日志上，你會經常發現有很多的登錄失敗條目，而且這些條目的IP地址通常還是同個IP地址。有時你又會發現不同的IP地址會使用同一個賬戶、不同的密碼進行登錄。

大量的暴力破解請求會導致服務器日志中出現大量異常記錄，從中你會發現一些奇怪的進站前鏈接，如http://user:password@website.com/login.html。

有時，攻擊者會用不同的用戶名和密碼頻繁地進行登錄嘗試，這就給主機入侵檢測系統或者記錄關聯系統一個檢測到他們入侵的好機會。當然這里會有一些誤報，需要我們排除掉。例如，同一個IP地址用同一個密碼重復登錄同一個賬戶，這種情況可能只是一個還未更新密碼或者未獲得正確認證的Web/移動應用程序而已，應排除掉這種干擾因素。

4.2.4 對用戶密碼強度不進行控制

網絡安全事件日益頻發，人們對密碼的保護意識自然開始增強，媒體網站也紛紛發文告誡用戶該如何設置安全的密碼。密碼中不要包含常用的詞匯，不要以生日、郵箱、用戶名、手機號等作為密碼。

設置密碼的方式已經被許多普通用戶熟知，那么在設置自己密碼時，中國用戶的安全意識是否已經足夠了呢？本節僅以2014年底的某購票網站因撞庫事件泄露的數據作為我們的數據源，來分析一下目前中國用戶的密碼設置習慣。

先來看一下該次泄露數據的總體情況。在本次事件中，共有131389名用戶的信息遭到泄露，其中主要以80后和90后為主，80后占比最高，為65%，是90后的一倍多，如圖4-15所示。從目前來看，80后仍然是泄露事件的主力軍。

設置密碼之大忌

（1）密碼中包含常用詞匯。

從網絡曝光的13萬條泄露數據來看，仍有不少人在設置自己的密碼時使用了123456、1314、520、521等常用詞匯，其中密碼中包含520的用戶有4500人之多，如圖4-16所示。

（2）用生日做密碼。

在本次泄露數據中，依然有2326人僅僅使用自己的生日6位數字作為密碼！而那些在密碼中包含生日數字的用戶更是多不勝舉。在這些犯了密碼設置大忌的人中，尤以80后為主，占比達到83.8%，遠超過其他年齡段的群體，如圖4-17所示。看來用生日做密碼是80后一個普遍存在的壞習慣。

（3）使用用戶名、郵箱做密碼。

泄露數據又給了我們一次“驚喜”，竟然有1700多人使用自己的注冊用戶名作為自己的密碼，而使用注冊郵箱作為密碼的用戶更為嚴重，有2396人之多。有趣的是，在泄露的人群中，90后的絕對占比（絕對占比即不同年齡段使用郵箱、用戶名的占比與不同年齡段用戶總數占比的比值）遠大于其他年齡群體，如圖4-18所示?？磥?0后和90后在密碼設置上的習慣都是不一樣的。

（4）用手機號做密碼。

本次泄露事件中有81名用戶使用了手機號做密碼。其中，60后的絕對占比最高，并且隨著年齡的降低，這一使用習慣絕對占比逐漸降低，如圖4-19所示。

年齡大的用戶要記的東西多，要使用一個好記的作為密碼才便于記憶，也是情有可原，畢竟自己的手機號還是記得最準確的，不容易搞混，但是這樣做很容易給黑客暴力破解密碼可乘之機。

另外，我們發現，該網站有一半以上的用戶還在使用純數字或純英文這種單一的密碼設置形式，使用組合密碼的用戶只占了46%。在如此高敏感高風險的網站中，居然有這么多用戶的密碼設置這么簡單。在這之中，尤其以80后使用組合密碼的為最少，只占了42%，而90后使用組合密碼的超過了一半，為53.38%。看來90后在密碼安全意識上是要略強過80后的。

4.2.5 對網絡安全證書進行攻擊

所謂的網站安全證書是通過在客戶端瀏覽器和Web服務器之間建立一條SSL安全通道，保證了雙方傳遞信息的安全性，而且用戶可以通過服務器證書驗證他所訪問的網站是否真實可靠。

信息發送者先對原始數據進行雜湊運算得到消息摘要，再使用自己的簽名私鑰對消息摘要進行加密運算。服務器/網站安全證書的基本過程則是信息接收者對收到的原始數據采用相同的雜湊運算得到消息摘要，將兩者進行對比，以校驗原始數據是否被篡改。通過服務器/網站安全證書技術可以實現對數據完整性以及傳送數據行為不可否認性的保護。

網絡安全證書傳輸步驟如下。

（1）簽名發送方（甲）對需要發送的明文使用雜湊算法，計算摘要。

（2）甲使用其簽名私鑰對摘要進行加密，得到密文。

（3）甲將密文、明文和簽名證書發送給簽名驗證方（乙）。

（4）乙方驗證簽名證書的有效性，并一方面將甲發送的密文通過甲的簽名證書解密得到摘要，另一方面將明文相同的采用雜湊算法計算出摘要。

（5）乙對比兩個摘要，如果相同，服務器證書則可以確認明文在傳輸過程中沒有被更改，并且信息是由證書所申明身份的實體發送的。

那么網絡安全證書又存在哪些漏洞，使得Web驗證機制安全受到威脅呢？

（1）證書有效期篡改。

以微信的COM_TENC.RSA證書為例，直接修改證書有效期（僅僅改動COM_TENC.RSA文件）：

Certifi cate:
    ……
    Validity
    Not Before: Jan 19 14:39:322015 GMT
    Not After : Jan 11 14:39:322015 GMT
    ……

很明顯，證書有效期錯誤，結束時間比開始時間還早，但是修改后的APK依然可以正常安裝、運行，因為COM_TENC.RSA文件里的公鑰（證書的一部分）和．SF文件都沒有修改，可以通過Android證書驗證機制。

聯想開來，某個已過期的證書依然可以使用，假如某個擁有高權限的證書已經過期，危害會很大。例如，Adobe頒發過某個證書C（使用Adobe公鑰簽名該證書），然后證書C過期了，但是由于用Adobe的公鑰驗證該證書仍然可以通過（修復過的證書鏈認證可以通過，除非Adobe吊銷它自己的證書），而Android并沒有驗證證書有效性，所以用證書C簽過名的APK依然擁有Adobe的高權限。

（2）證書擁有者主體篡改。

以微信的COM_TENC.RSA證書為例，直接修改證書擁有者名字（僅僅改動COM_TENC. RSA文件）：

Certificate:
    ……
    Issuer: C=86, ST=Guangdong, L=Shenzhen, O=abcdefg Technology
（Shenzhen）Company Limited, OU=abcdefg Guangzhou Research and
Development Center, CN=abcdefg
    Validity
    Not Before: Jan 19 14:39:322015 GMT
    Not After : Jan 11 14:39:322015 GMT
    Subject: C=86, ST=Guangdong, L=Shenzhen, O=abcdefg Technology
（Shenzhen）Company Limited, OU=abcdefg Guangzhou Research and
Development Center, CN=abcdefg
    ……

將開發者信息修改為了abcdefg，但是修改后的APK依然可以正常安裝、運行，因為COM_TENC.RSA文件里的公鑰（證書的一部分）和．SF文件都沒有修改，可以通過Android證書驗證機制。

聯想開來，開發者主體信息很容易修改，造成知識版權問題。例如，可以把Google開發的APK的開發者證書信息修改成我自己的名字，擴大影響力；或者，把自己開發的惡意APK冠上Google的名字。

（3）證書吊銷CRL。

Android證書機制并沒有引入CRL吊銷機制，已經吊銷但擁有合法簽名的證書依然可以使用，和第一項證書過期類似（證書過期也是吊銷的一種方法）。

但是，證書吊銷還有另外一個應用，當發現某個證書的私鑰有泄露或是被破解時，業界常用的手法是吊銷該證書，加入CRL列表。例如，2012年發生的Yahoo Axis私鑰泄露事件。在Android系統里，并沒有采用證書吊銷機制，設想場景：Adobe頒發過某個證書D（使用Adobe公鑰簽名該證書），然后證書D在使用過程中發生了私鑰泄露，那么此時只有吊銷Adobe自己的根證書才能真正使證書D失效，成本大而且會影響其他Adobe簽過名的證書。