WebApp 安全風(fēng)險與防護課堂（第二講）開課了！

本文由葡萄城技術(shù)團隊于原創(chuàng)并首發(fā)

轉(zhuǎn)載請注明出處：葡萄城官網(wǎng)，葡萄城為開發(fā)者提供專業(yè)的開發(fā)工具、解決方案和服務(wù)，賦能開發(fā)者。

?

在昨天的公開課中，由于參與的小伙伴們積極性和熱情非常高，我們的講師Carl（陳慶）把原定第二講的大部分也一并獻出了，所以原定三場的公開課也變?yōu)榱藘蓤?，本系列的公開課生動有趣、干貨滿滿、受眾廣泛，所以沒有參與上次課程的小伙伴們這次請不要忘記了，本期公開課，我們將著重介紹OWASP Top 10（10項最嚴(yán)重的Web應(yīng)用程序安全風(fēng)險預(yù)警）及其應(yīng)對策略。公開課地址：http://live.vhall.com/137416596

?

OWASP Top 10 應(yīng)用安全風(fēng)險詳解

《OWASP Top 10》的目的在于為廣大企業(yè)確定一組最嚴(yán)重的風(fēng)險項目。對于其中的每一項風(fēng)險，我們將使用基于OWASP風(fēng)險等級排序的評級方案，為您提供關(guān)于漏洞普遍性、可檢測性、業(yè)務(wù)/技術(shù)影響等信息。

?

一、注入

將不受信任的數(shù)據(jù)作為命令或查詢的一部分發(fā)送到解析器時，會產(chǎn)生諸如SQL注入、NoSQL注入、OS注入和LDAP注入等注入缺陷。***者的惡意數(shù)據(jù)可以誘使解析器在沒有適當(dāng)授權(quán)的情況下執(zhí)行非預(yù)期命令或訪問數(shù)據(jù)。

?

?

可利用性：容易

幾乎任何數(shù)據(jù)源都能成為注入載體，包括環(huán)境變量、所有類型的用戶、參數(shù)、外部和內(nèi)部Web服務(wù)。當(dāng)***者可以向解釋器發(fā)送惡意數(shù)據(jù)時，注入漏洞便可產(chǎn)生。

普遍性：常見

注入漏洞十分普遍，尤其是在遺留代碼中。注入漏洞通常能在SQL、LDAP、XPath或是NoSQL查詢語句、OS命令、XML解析器、SMTP包頭、表達式語句及ORM查詢語句中找到。

可檢測性：易

注入漏洞很容易通過代碼審查發(fā)現(xiàn)。掃描器和模糊測試工具可以幫助***者找到這些漏洞。

技術(shù)影響：嚴(yán)重

注入能導(dǎo)致數(shù)據(jù)丟失、破壞或泄露給無授權(quán)方、缺乏可審計性或是拒絕服務(wù)。注入有時甚至能導(dǎo)致主機被完全接管。

業(yè)務(wù)影響：未知

您的應(yīng)用和數(shù)據(jù)需要受到保護，以避免對業(yè)務(wù)造成影響。

自查：您的應(yīng)用程序脆弱嗎？

當(dāng)您的應(yīng)用有如下情況時，是脆弱且易受到***的：

1. 用戶提供的數(shù)據(jù)沒有經(jīng)過應(yīng)用程序的驗證、過濾或凈化。

2. 動態(tài)查詢語句或非參數(shù)化的調(diào)用，在沒有上下文感知轉(zhuǎn)義的情況下，被用于解釋器。

3. 在ORM搜索參數(shù)中使用了惡意數(shù)據(jù)，這樣搜索就獲得包含敏感或未授權(quán)的數(shù)據(jù)。

4. 惡意數(shù)據(jù)直接被使用或連接，諸如SQL語句或命令在動態(tài)查詢語句、命令或存儲過程中包含結(jié)構(gòu)和惡意數(shù)據(jù)。

一些常見的注入，包括：SQL、OS命令、ORM、LDAP和表達式語言（EL）或OGNL注入。

所有編譯器的原理都是相似的，因此 Code Review是目前為止最有效的檢測應(yīng)用程序注入風(fēng)險的辦法之一。當(dāng)然，您也可以對代碼中所有參數(shù)、字段、頭、cookie、JSON和XML數(shù)據(jù)輸入進行DAST掃描，并將SAST和DAST工具添加到CI/CD進程中，以便在項目部署前對現(xiàn)有代碼或新代碼進行注入檢測。

如何防止注入？

防止注入漏洞需要將數(shù)據(jù)與命令語句、查詢語句分隔開來：

1. 最佳選擇是使用安全的API，完全避免使用解釋器，或提供參數(shù)化界面的API，或遷移到ORM或?qū)嶓w框架中。（注意：當(dāng)參數(shù)化時，如果PL/SQL或T-SQL將查詢和數(shù)據(jù)連接在一起，或者執(zhí)行帶有立即執(zhí)行或exec()的惡意數(shù)據(jù)，存儲過程仍然可以引入SQL注入漏洞。）

2. 使用正確或符合“白名單”規(guī)范的輸入驗證方法，同樣有助于防止注入***，但這很可能引起用戶的吐槽，因為許多應(yīng)用程序在輸入中需要特殊字符，如文本區(qū)域或移動應(yīng)用程序的API。

3. 對于所有動態(tài)查詢，可以使用該解釋器的特定轉(zhuǎn)義語法轉(zhuǎn)義特殊字符。OWASP的Java Encoder和類似的庫提供了這樣的轉(zhuǎn)義例程。（注意：在SQL結(jié)構(gòu)中，表名、列名等無法轉(zhuǎn)義，因此用戶提供的結(jié)構(gòu)往往是非常危險的。）

4. 在查詢中使用LIMIT和其他SQL控件，防止在SQL注入時引發(fā)大量數(shù)據(jù)泄露。

***案例場景

?

在這兩個案例中，***者在瀏覽器中將“id”參數(shù)的值修改成： ’or’1’=’1。例如：

http://example.com/app/accountView?id=' or '1'='1

這樣查詢語句的意義就變成了從accounts表中返回所有記錄。

SQL盲注

SQL盲注，就是在SQL語句注入后且成功執(zhí)行時，執(zhí)行的結(jié)果不能回顯到前端頁面。此時，我們需要利用一些方法進行判斷或者嘗試，這個過程稱之為盲注。

盲注一般分為三類：

一、基于布爾的盲注

基于布爾的盲注通常使用邏輯判斷推測獲取的數(shù)據(jù)，通過給定條件，服務(wù)器返回真或假。使用二分法或者正則表達式等方法即可縮小判斷的范圍。

二、基于時間的盲注

主要是利用延時或者執(zhí)行的時間來判斷。

If(ascii(substr(database(),1,1))>115,0,sleep(5))%23 //if 判斷語句，條件為假，執(zhí)行 sleep

因為延時會受到網(wǎng)絡(luò)環(huán)境的影響，因此這種方法不是很可靠。

三、基于報錯的盲注

構(gòu)造payload讓信息通過錯誤提示顯示。

count(*)和rand(0)和group by報錯

rand(0)是偽隨機數(shù)列，01101100。產(chǎn)生報錯的原因是因為rand(0)并不是一個定值，相當(dāng)于一個變量。使用group by時，會建立一張?zhí)摂M表，字段為key和count(*)。執(zhí)行插入操作，第一次返回0，但虛擬表中沒有這個項，數(shù)據(jù)庫會認(rèn)為需要插入這個項，但數(shù)據(jù)庫并沒有記錄下來，因此，會再次執(zhí)行rand(0) 試圖獲取，但此時獲取的是第二個數(shù)。依次類推，當(dāng)數(shù)據(jù)庫查詢發(fā)現(xiàn)0這個項不存在，執(zhí)行插入操作時， rand(0)返回值為1，但是1已經(jīng)存在，這時插入已經(jīng)存在的項就會報錯。

WAF繞過

之所以要談到WAF的常見特征，是為了更好的了解WAF的運行機制，以便增加繞過WAF的機會?？傮w來說，WAF(Web Application Firewall)具有以下四個方面的功能：

1. 審計設(shè)備：用來截獲所有HTTP數(shù)據(jù)或者僅僅滿足某些規(guī)則的會話

2. 訪問控制設(shè)備：用來控制對Web應(yīng)用的訪問，既包括主動安全模式也包括被動安全模式

3. 架構(gòu)/網(wǎng)絡(luò)設(shè)計工具：當(dāng)運行在反向代理模式，他們被用來分配職能，集中控制，虛擬基礎(chǔ)結(jié)構(gòu)等

4. WEB應(yīng)用加固工具：這些功能增強被保護Web應(yīng)用的安全性，它不僅能夠屏蔽WEB應(yīng)用固有弱點，而且能夠保護WEB應(yīng)用編程錯誤導(dǎo)致的安全隱患

WAF過濾機制：

1. 異常檢測協(xié)議：拒絕不符合HTTP標(biāo)準(zhǔn)的請求；

2. 增強的輸入驗證：代理和服務(wù)端的驗證，而不只是限于客戶端驗證；

3. 白名單&黑名單：白名單適用于穩(wěn)定的Web應(yīng)用，黑名單適合處理已知問題；

4. 基于規(guī)則和基于異常的保護：基于規(guī)則更多的依賴黑名單機制，基于異常更為靈活；

5. 狀態(tài)管理：重點進行會話保護；

6. 其他：Cookies保護、抗***規(guī)避技術(shù)、響應(yīng)監(jiān)視和信息泄露保護等。

繞過WAF的方法：

從目前能找到的資料來看，繞過WAF的技術(shù)主要分為9類，包含：

1. 大小寫混合（最簡單的繞過技術(shù)，用于只針對小寫或大寫的關(guān)鍵字匹配技術(shù)）

2. 替換關(guān)鍵字（這種方式大小寫轉(zhuǎn)化無法繞過，而且正則表達式會替換或刪除select、union這些關(guān)鍵字，如果只匹配一次就很容易繞過）

3. 使用編碼（URL編碼、Unicode編碼）

4. 使用注釋（普通注釋、內(nèi)聯(lián)注釋）

5. 等價函數(shù)與命令（有些函數(shù)或命令因其關(guān)鍵字被檢測出來而無法使用，但是在很多情況下可以使用與之等價或類似的代碼替代其使用）

6. 特殊符號（特殊符號有特殊的含義和用法，涉及信息量比前面提到的幾種都要多）

7. HTTP參數(shù)控制（這里HTTP參數(shù)控制除了對查詢語句的參數(shù)進行篡改，還包括HTTP方法、HTTP頭的控制）

8. 緩沖區(qū)溢出（緩沖區(qū)溢出用于對付WAF，有不少WAF是C語言寫的，而C語言自身沒有緩沖區(qū)保護機制，因此如果WAF在處理測試向量時超出了其緩沖區(qū)長度，就會引發(fā)bug從而實現(xiàn)繞過）

9. 整合繞過（整合的意思是結(jié)合使用前面談到的各種繞過技術(shù)，單一的技術(shù)可能無法繞過過濾機制，但是多種技術(shù)的配合使用成功的可能性就會增加不少。除非每一種技術(shù)單獨都無法使用，否則它們能產(chǎn)生比自身大得多的能量。）

二、身份認(rèn)證失效

通過錯誤地使用Web應(yīng)用程序的身份認(rèn)證和會話管理功能，***者能夠破譯密碼、密鑰和會話令牌，或者利用其它開發(fā)缺陷來暫時性或永久性地冒充管理員的身份。

?

?

可利用性：容易

***者可以輕松獲取數(shù)百萬條有效用戶名和密碼組合，包括證書、默認(rèn)的賬戶管理列表、自動的暴力破解和字典***工具，以及高級的GPU破解工具。會話管理可以很容易地被利用，尤其是沒有過期的會話密匙。

普遍性：常見

大多數(shù)管理系統(tǒng)的設(shè)計和實現(xiàn)，都存在身份認(rèn)證失效的問題。會話管理是身份驗證和訪問控制的基礎(chǔ)，并且存在于整個應(yīng)用程序的進程中。

可檢測性：一般

***者通常使用指南手冊來檢測失效的身份驗證。除此之外，也會關(guān)注密碼轉(zhuǎn)儲、字典***，或者在類似釣魚、社會工程***后，發(fā)現(xiàn)失效的身份認(rèn)證。

技術(shù)影響：嚴(yán)重

***者只需訪問幾個賬戶，或者一個管理員賬戶就可以破壞我們的系統(tǒng)。根據(jù)應(yīng)用程序業(yè)務(wù)場景的不同，可能會導(dǎo)致洗錢、欺詐、用戶身份盜竊、泄露法律保護的敏感信息等嚴(yán)重違法行為。

自查：您的應(yīng)用程序脆弱嗎？

確認(rèn)用戶身份、身份驗證和會話管理非常重要，這些措施可用于將惡意的、未經(jīng)身份驗證的***者與授權(quán)用戶進行分離。如果您的應(yīng)用程序存在如下問題，那么可能存在身份驗證失效漏洞：

1. 允許憑證填充，***者可利用此獲得有效的用戶名和密碼。

2. 允許暴力破解或其他自動***。

3. 使用默認(rèn)、弱安全性的密碼，例如“Password1”或“admin/admin”。

4. 使用弱安全性或失效的驗證憑證。

5. 使用明文、加密或弱散列密碼。

6. 缺少或失效的多因素身份驗證。

7. 暴露URL中的會話ID（例如URL重寫）。

8. 在成功登錄后不會更新會話ID。

9. 不正確地使會話ID失效。當(dāng)用戶不活躍的時候，用戶會話或認(rèn)證令牌（特別是單點登錄（SSO）令牌）沒有正確注銷或失效。

10. 在盡可能的情況下，使用多因素身份驗證，以防止憑證填充、暴力破解和被盜憑據(jù)再利用***。

11. 不要使用已發(fā)送或部署默認(rèn)的憑證，特別是管理員用戶。

12. 定期執(zhí)行弱密碼檢查。

13. 將密碼長度、復(fù)雜性和循環(huán)策略與NIST-800-63 B的指導(dǎo)方針或其他現(xiàn)代的密碼策略保持一致。

14. 確認(rèn)注冊、憑據(jù)恢復(fù)和API路徑，確保對所有輸出結(jié)果使用相同的消息，用以抵御賬戶枚舉***。

15. 限制或逐漸延遲失敗的登錄嘗試。記錄所有失敗信息并在憑據(jù)填充、暴力破解或其他***被檢測時提醒系統(tǒng)管理員。

16. 使用服務(wù)器端內(nèi)置的會話管理器，在登錄后生成高度復(fù)雜且不存在于URL的隨機會話ID。這樣當(dāng)用戶登出、閑置、絕對超時后使其失效。

如何防止？

?

***案例場景

場景#1：最常見的***方式——憑證填充，使用已知密碼的列表。如果應(yīng)用程序不限制身份驗證嘗試次數(shù)，則可以將應(yīng)用程序用作密碼oracle， 以確定憑證是否有效。

場景#2：大多數(shù)身份驗證***都是由于密碼作為唯一的認(rèn)證因素。

場景#3：應(yīng)用會話超時設(shè)置不正確。用戶使用公共計算機訪問應(yīng)用程序時，直接關(guān)閉瀏覽器選項卡就離開，而不是選擇“注銷”。

憑據(jù)填充（撞庫）

撞庫，是***通過收集互聯(lián)網(wǎng)已泄露的用戶和密碼信息，生成對應(yīng)的字典表，嘗試批量登陸其他網(wǎng)站后，得到一系列可以登錄的用戶。很多用戶在不同網(wǎng)站使用的是相同的賬號和密碼，因此***可以通過獲取用戶在A網(wǎng)站的賬戶從而嘗試登錄B網(wǎng)站，這就是撞庫***。

撞庫可以通過數(shù)據(jù)庫安全防護技術(shù)解決，數(shù)據(jù)庫安全技術(shù)包括：數(shù)據(jù)庫漏掃、數(shù)據(jù)庫加密、數(shù)據(jù)庫防火墻、數(shù)據(jù)脫敏、數(shù)據(jù)庫安全審計系統(tǒng)。

撞庫并不神秘，事實上，它正被廣泛的使用。舉例而言，根據(jù)Shape Security的報告，“***者們一旦鎖定了一個財富100強的B2C(企業(yè)對消費者)網(wǎng)站，就會在一個星期內(nèi)使用遍布世界各地的代理服務(wù)器，對其進行超過五百萬次登錄嘗試?！?雪上加霜的是，被竊取的憑證也并不難找。***們會為了找樂子或?qū)で髶P名立萬的機會把憑證散播到網(wǎng)上。當(dāng)***們在憑證黑市(比如Cracking-dot-org、 Crackingking-dot-org以及 Crackingseal-dot-io)做生意時，這些名聲會派上大用場。

多因素驗證

多因素驗證（Multi-factor authentication，縮寫為 MFA），又譯多因子認(rèn)證、多因素認(rèn)證，是一種計算機訪問控制的方法，用戶要通過兩種以上的認(rèn)證機制之后，才能得到授權(quán)，使用計算機資源。例如，用戶要輸入PIN碼，插入銀行卡，最后再經(jīng)指紋比對，通過這三種認(rèn)證方式，才能獲得授權(quán)。這種認(rèn)證方式可以提高安全性。

三、敏感數(shù)據(jù)泄露

許多Web應(yīng)用程序和API都無法正確保護敏感數(shù)據(jù)，例如：財務(wù)數(shù)據(jù)、醫(yī)療數(shù)據(jù)和PII數(shù)據(jù)。***者可以通過竊取或修改未加密的數(shù)據(jù)來實施信用卡詐騙、身份盜竊或其他犯罪行為。未加密的敏感數(shù)據(jù)容易受到破壞，因此，我們需要對敏感數(shù)據(jù)加密，這些數(shù)據(jù)包括：傳輸過程中的數(shù)據(jù)、存儲的數(shù)據(jù)以及瀏覽器的交互數(shù)據(jù)。

?

?

可利用性：一般

***者并非直接***，而是在傳輸過程中、從客戶端（例如：瀏覽器）竊取密鑰、發(fā)起中間人***，或從服務(wù)器端直接竊取明文數(shù)據(jù)。

普遍性：廣泛

這是最常見，也是最具影響力的***手段。在數(shù)據(jù)加密的過程中，由于不安全的密鑰生成、管理以及使用弱加密算法、弱協(xié)議和弱密碼（未加鹽的哈希算法或弱哈希算法），導(dǎo)致數(shù)據(jù)泄露事件頻發(fā)。

可檢測性：一般

在服務(wù)器端，檢測傳輸過程中的數(shù)據(jù)弱點很容易，但檢測存儲數(shù)據(jù)的弱點卻異常困難。

技術(shù)影響：嚴(yán)重

敏感數(shù)據(jù)泄露事件造成的影響是非常嚴(yán)重的，因為這些數(shù)據(jù)通常包含了很多個人信息（PII），例如：醫(yī)療記錄、認(rèn)證憑證、個人隱私、信用卡信息等。這些信息受到相關(guān)法律和條例的保護，例如：歐盟《通用數(shù)據(jù)保護條例》（GDPR）和地方隱私保護法律。

自查：您的應(yīng)用程序脆弱嗎？

首先你需要確認(rèn)哪些數(shù)據(jù)（包含：傳輸過程中的數(shù)據(jù)、存儲數(shù)據(jù)）是敏感數(shù)據(jù)。例如：密碼、信用卡卡號、醫(yī)療記錄、個人信息等，這些數(shù)據(jù)應(yīng)該被加密，請Review：

1. 在數(shù)據(jù)傳輸過程中是否使用明文傳輸？這和傳輸協(xié)議相關(guān)，如：HTTP、SMTP和FTP。（注意：外網(wǎng)流量十分危險，請驗證所有的內(nèi)部通信，如：負(fù)載平衡器、Web服務(wù)器或后端系統(tǒng)之間的通信。）

2. 當(dāng)數(shù)據(jù)被長期存儲時，無論存儲在哪里，它們是否都被加密或備份？

3. 無論默認(rèn)條件還是源代碼中，是否還在使用任何舊的、脆弱的加密算法？

4. 是否使用默認(rèn)加密密鑰，生成或重復(fù)使用脆弱的加密密鑰，或者缺少恰當(dāng)?shù)拿荑€管理或密鑰回轉(zhuǎn)？

5. 是否強制加密敏感數(shù)據(jù)，例如：用戶代理（如：瀏覽器）指令，傳輸協(xié)議是否被加密？

6. 用戶代理（如：應(yīng)用程序、郵件客戶端）是否未驗證服務(wù)器端證書的有效性？

如何防止？

對一些需要加密的敏感數(shù)據(jù)，應(yīng)該做到以下幾點：

1. 對系統(tǒng)處理、存儲或傳輸?shù)臄?shù)據(jù)分類，并根據(jù)分類分別進行訪問控制。

2. 熟悉與敏感數(shù)據(jù)保護相關(guān)的法律和條例，并根據(jù)每項法規(guī)的要求保護敏感數(shù)據(jù)。

3. 對于沒必要存放，但重要的敏感數(shù)據(jù)，應(yīng)當(dāng)盡快清除，或者通過 PCI DSS標(biāo)記或攔截，只有未存儲的數(shù)據(jù)才不會被竊取。

4. 確保已存儲的所有敏感數(shù)據(jù)都被加密。

5. 確保使用了最新、強大的標(biāo)準(zhǔn)算法或密碼、參數(shù)、協(xié)議和密鑰，并且密鑰管理到位。

6. 確保傳輸過程中的數(shù)據(jù)被加密，如：使用TLS。

7. 確保數(shù)據(jù)加密被強制執(zhí)行，如：使用HTTP嚴(yán)格安全傳輸協(xié)議（HSTS ）。

8. 禁止緩存對包含敏感數(shù)據(jù)的響應(yīng)。

9. 確保使用密碼專用算法存儲密碼，如：Argon2 、scrypt 、bcrypt 或PBKDF2 。

10. 將工作因素（延遲因素）設(shè)置在可接受的范圍。

11. 單獨驗證每個安全配置項的有效性。

***案例場景

場景 #1：假設(shè)一個應(yīng)用程序使用自動化的數(shù)據(jù)加密系統(tǒng)加密了信用卡信息，并存儲在數(shù)據(jù)庫中，當(dāng)數(shù)據(jù)被檢索時自動解密。這會導(dǎo)致SQL注入漏洞能夠以明文形式獲得所有信用卡卡號。

場景 #2：一個網(wǎng)站上沒有使用或強制使用TLS，或者僅使用弱加密算法。***者通過監(jiān)測網(wǎng)絡(luò)流量（如：不安全的無線網(wǎng)絡(luò)），將網(wǎng)絡(luò)連接從HTTPS降級到HTTP，就可以截取請求并竊取用戶會話 cookie。然后，***者可以復(fù)制用戶cookie并成功劫持經(jīng)過認(rèn)證的用戶會話、訪問或修改用戶個人信息。除此之外，***者還可以更改所有傳輸過程中的數(shù)據(jù)，如：轉(zhuǎn)款的接收者。

場景 #3：密碼數(shù)據(jù)庫使用未加鹽的哈希算法或弱哈希算法去存儲密碼，此時，一個文件上傳漏洞可使***能夠獲取密碼文件，而這些未加鹽的哈希密碼通過彩虹表暴力破解方式即可快速破解。

各國應(yīng)對措施

日本個人信息保護法

近年來，因信息、通信技術(shù)的發(fā)展，企業(yè)需要收集大量個人信息，用以提供準(zhǔn)確且迅速的服務(wù)。個人信息的利用，無論是對現(xiàn)今的商業(yè)活動，還是對國民生活都變得不可或缺。但是，另一方面，由于處理個人信息狀況不當(dāng)，導(dǎo)致個人權(quán)利和利益受到損害的可能性也在增大。在日本，包含企業(yè)和政府等團體的組織內(nèi)部，泄露的個人信息數(shù)量累積超過了1000萬件。于是，鑒于規(guī)范處理個人信息，明確國家及地方公共團體的職責(zé)，確保個人信息有效利用等目的，日本于2005年4月1日起頒布《個人信息保護法》。

歐盟《通用數(shù)據(jù)保護條例》（GDPR)

歐盟《通用數(shù)據(jù)保護條例》（General Data Protection Regulation，簡稱GDPR），其前身是歐盟在1995年制定的《計算機數(shù)據(jù)保護法》，該法明確規(guī)定：

1. 對違法企業(yè)的罰金最高可達2000萬歐元（約合1.5億元人民幣）或其全球營業(yè)額的4%，以高者為準(zhǔn)。

2. 網(wǎng)站經(jīng)營者必須事先向客戶說明會自動記錄客戶的搜索和購物記錄，并獲得用戶的同意，否則按“未告知記錄用戶行為”作違法處理。

3. 企業(yè)不能再使用模糊、難以理解的語言，或冗長的隱私政策來從用戶處獲取數(shù)據(jù)使用許可。

4. 明文規(guī)定了用戶的“被遺忘權(quán)”（right to be forgotten），即用戶個人可以要求責(zé)任方刪除關(guān)于自己的數(shù)據(jù)記錄。

設(shè)計安全賬號系統(tǒng)的正確姿勢

數(shù)據(jù)安全防范的方法簡單來說，當(dāng)數(shù)據(jù)從用戶鍵盤敲出的那一刻，到服務(wù)器后臺存儲過程中，都需保持正確的姿勢。如：

1. 用正確的姿勢保存密碼

a)???? 低級錯誤：明文保存密碼

b)??? 低級錯誤：可逆加密密碼

c)???? 錯誤方法：md5 加密密碼

d)??? 正確方法：加鹽 hash 保存密碼

1. 用正確的姿勢傳輸數(shù)據(jù)

a)???? 驗證服務(wù)端的合法性

b)??? 確保通信的安全

1. 用正確的姿勢加密敏感信息

2. 用正確的姿勢對數(shù)據(jù)進行備份和監(jiān)控

?

四、XML 外部實體（XXE）

許多較早的或配置錯誤的XML處理器評估了XML文件中的外部實體引用。***者可以利用外部實體竊取使用URI文件處理器的內(nèi)部文件和共享文件、監(jiān)聽內(nèi)部掃描端口、執(zhí)行遠(yuǎn)程代碼和實施拒絕服務(wù)***。

?

?

可利用性：一般

如果***者可以上傳XML文檔或在XML文檔中添加惡意內(nèi)容（如，易受***的代碼、依賴項或集成），他們就能夠***含有缺陷的XML處理器。

普遍性：常見

一般來說，許多舊的XML處理器能夠?qū)ν獠繉嶓w、XML進程中被引用和評估的URI進行規(guī)范。SAST 工具可以通過檢查依賴項和安全配置來發(fā)現(xiàn)XXE缺陷。DAST工具需要額外的手動步驟來檢測和利用XXE缺陷。

技術(shù)影響：嚴(yán)重

XXE缺陷可用于提取數(shù)據(jù)、執(zhí)行遠(yuǎn)程服務(wù)器請求、掃描內(nèi)部系統(tǒng)、執(zhí)行拒

絕服務(wù)***和其他***。

?

自查：您的應(yīng)用程序脆弱嗎？

應(yīng)用程序，特別是基于XML的Web服務(wù)，可能在以下方面容易受到***：

1. 您的應(yīng)用程序直接接受XML文件或者接受XML文件上傳，特別是來自不受信任源的文件，或者將不受信任的數(shù)據(jù)插入XML文件，并提交給XML處理器解析。

2. 在應(yīng)用程序或基于Web服務(wù)的SOAP中，所有XML處理器都啟用了文檔類型定義（DTDs）。

3. 為了實現(xiàn)安全性或單點登錄（SSO），您的應(yīng)用程序應(yīng)該使用了 SAML進行身份認(rèn)證，而假設(shè)SAML使用了XML進行身份確認(rèn)，那么您的應(yīng)用程序就容易受到XXE***。

4. 如果您的應(yīng)用程序使用第1.2版之前的SOAP，并將XML實體傳遞到SOAP框架，那么它可能受到XXE***。

5. 存在XXE缺陷的應(yīng)用程序更容易受到拒絕服務(wù)***，如： Billion Laughs ***。

如何防止？

培訓(xùn)開發(fā)人員的安全意識，是識別和減少XXE的關(guān)鍵，除此之外，還需要：

1. 盡可能地使用簡單的數(shù)據(jù)格式（如：JSON），避免對敏感數(shù)據(jù)進行序列化。?

2. 及時修復(fù)或更新應(yīng)用程序或底層操作系統(tǒng)使用的XML處理器和庫。同時，通過依賴項檢測，將SOAP更新到1.2版本或更高版本。

3. 參考《OWASP Cheat Sheet ‘XXE Prevention‘》，在應(yīng)用程序的所有XML解析器中禁用XML外部實體和DTD進程。

4. 在服務(wù)器端實施（“白名單”）輸入驗證、過濾和清理， 以防止在XML文檔、標(biāo)題或節(jié)點中出現(xiàn)惡意數(shù)據(jù)。

5. 驗證XML或XSL文件上傳功能是否使用了XSD驗證或其他類似的驗證。

6. 盡管在許多集成環(huán)境中，手動代碼審查是大型、復(fù)雜應(yīng)用程序的最佳選擇，但是SAST 工具可以檢測源代碼中的XXE漏洞。 如果無法實現(xiàn)這些控制，請考慮使用虛擬修復(fù)程序、API安全網(wǎng)關(guān)或Web應(yīng)用程序防火墻（ WAF ）來檢測、監(jiān)控和防止XXE***。

***案例場景

目前，已經(jīng)有大量XXE缺陷被發(fā)現(xiàn)并公開，這些缺陷包括上傳可被接受的惡意XML文件、嵌入式設(shè)備的 XXE缺陷及深嵌套的依賴項等。

XML基本定義

XML是用于標(biāo)記電子文件使其具有結(jié)構(gòu)性的標(biāo)記語言，可以用來標(biāo)記數(shù)據(jù)、定義數(shù)據(jù)類型，是一種允許用戶對自己的標(biāo)記語言進行定義的源語言。XML文檔結(jié)構(gòu)包括XML聲明、DTD文檔類型定義（可選）、文檔元素。

?

圖片來自網(wǎng)絡(luò)

XML由3個部分構(gòu)成，分別是：文檔類型定義（Document Type Definition，DTD），即XML的布局語言；可擴展的樣式語言（Extensible Style Language，XSL），即XML的樣式表語言；以及可擴展鏈接語言（Extensible Link Language，XLL）。

XML 中的實體分為以下五種：字符實體，命名實體，外部實體，參數(shù)實體，內(nèi)部實體，普通實體和參數(shù)實體都分為內(nèi)部實體和外部實體兩種，外部實體定義需要加上 SYSTEM關(guān)鍵字，其內(nèi)容是URL所指向的外部文件實際的內(nèi)容。如果不加SYSTEM關(guān)鍵字，則為內(nèi)部實體，表示實體指代內(nèi)容為字符串。

XML外部實體

XML外部實體表示外部文件的內(nèi)容，用 SYSTEM 關(guān)鍵詞表示：

在上面的代碼中， XML外部實體 ‘entityex’ 被賦予的值為：file://etc/passwd。在解析XML文檔的過程中，實體’entityex’的值會被替換為URI(file://etc/passwd)內(nèi)容值（也就是passwd文件的內(nèi)容）。 關(guān)鍵字’SYSTEM’會告訴XML解析器，’entityex’實體的值將從其后的URI中讀取，并把讀取的內(nèi)容替換entityex出現(xiàn)的地方。

假如 SYSTEM 后面的內(nèi)容可以被用戶控制，那么用戶就可以隨意替換為其他內(nèi)容，從而讀取服務(wù)器本地文件（file:///etc/passwd)或者遠(yuǎn)程文件（http://www.baidu.com/abc.txt）。

XXE 注入定義

XXE注入（即XML External Entity, XML外部實體注入）。通過 XML 實體，”SYSTEM”關(guān)鍵詞導(dǎo)致 XML 解析器可以從本地文件或者遠(yuǎn)程 URI 中讀取數(shù)據(jù)。***者可以通過 XML 實體傳遞自己構(gòu)造的惡意值，從而引導(dǎo)處理程序解析它。當(dāng)引用外部實體時，***者通過構(gòu)造惡意內(nèi)容，可讀取任意文件、執(zhí)行系統(tǒng)命令、探測內(nèi)網(wǎng)端口、***內(nèi)網(wǎng)網(wǎng)站等行為。

XXE 漏洞原理

最常見的XXE漏洞類型分為以下三種：

1. 基礎(chǔ)的XXE注入— 外部實體注入本地DTD

2. 基于盲注的XXE注入—XML解析器在響應(yīng)中不顯示任何錯誤

3. 基于錯誤的XXE注入—成功解析之后，XML解析器始終顯示SAME響應(yīng)。（即“您的消息已被接收”），因此，我們可能希望解析器將文件的內(nèi)容“打印”到錯誤響應(yīng)中。

既然XML可以從外部讀取DTD文件，那我們就自然地想到了如果將路徑換成另一個文件的路徑，那么服務(wù)器在解析這個XML的時候就會把那個文件的內(nèi)容賦值給SYSTEM前面的根元素中，只要我們在XML中讓前面的根元素的內(nèi)容顯示出來，就可以讀取那個文件的內(nèi)容了。這就造成了一個任意文件讀取的漏洞。

假設(shè)我們指向的是一個內(nèi)網(wǎng)主機的端口呢？是否會給出錯誤信息，我們是不是可以從錯誤信息上來判斷內(nèi)網(wǎng)主機這個端口是否開放，這就造成了一個內(nèi)部端口被探測的問題。一般來說，服務(wù)器解析XML有兩種方式，一種是一次性將整個XML加載進內(nèi)存中，進行解析；另一種是一部分的、“流式”地加載、解析。如果我們遞歸地調(diào)用XML定義，一次性調(diào)用巨量的定義，那么服務(wù)器的內(nèi)存就會被消耗完，造成了拒絕服務(wù)***。

五、失效的訪問控制

未對通過身份驗證的用戶實施恰當(dāng)?shù)脑L問控制。***者可以利用這些缺陷，訪問未經(jīng)授權(quán)的功能或數(shù)據(jù)，例如：訪問其他用戶的賬戶、查看敏感文件、修改其他用戶的數(shù)據(jù)、更改訪問權(quán)限等。

六、安全配置錯誤

安全配置錯誤是最常見的安全問題，這通常是由于不安全的默認(rèn)配置、不完整的臨時配置、開源云存儲、錯誤的 HTTP 標(biāo)頭配置以及包含敏感信息的詳細(xì)錯誤信息所造成的。因此，我們不僅需要對所有的操作系統(tǒng)、框架、庫和應(yīng)用程序進行安全配置，而且必須及時修補和升級它們。

七、跨站腳本（XSS）

當(dāng)應(yīng)用程序的新網(wǎng)頁中包含不受信任的、未經(jīng)驗證或轉(zhuǎn)義的數(shù)據(jù)時，或者使用可以創(chuàng)建 HTML或 JavaScript 的瀏覽器 API 更新現(xiàn)有網(wǎng)頁時，就會出現(xiàn) XSS 缺陷。XSS 讓***者能夠在受害者的瀏覽器中執(zhí)行腳本，并劫持用戶會話、破壞網(wǎng)站或?qū)⒂脩糁囟ㄏ虻綈阂庹军c。

?

?

可利用性：容易

自動化工具能夠檢測并利用所有的三種XSS形式，并且存放在便于***者利用的漏洞中。

普遍性：廣泛

XSS是OWASP Top10中第二普遍的安全問題，存在于近三分之二的應(yīng)用程序中。

可檢測性：容易

自動化工具能發(fā)現(xiàn)XSS問題，尤其是一些成熟的技術(shù)框架中，如：PHP、J2EE或JSP、ASP.NET等。

技術(shù)影響：中等

XSS對于反射和DOM的影響是中等的，而對于存儲的XSS，XSS的影響更為嚴(yán)重，譬如在受到***的瀏覽器上執(zhí)行遠(yuǎn)程代碼，如：竊取憑證和會話或傳遞惡意軟件等。

自查：您的應(yīng)用程序脆弱嗎？

針對用戶的瀏覽器，存在三種XSS類型：

1. 反射式XSS：應(yīng)用程序或API包含未經(jīng)驗證和未經(jīng)轉(zhuǎn)義的用戶輸入，并作為HTML輸出的一部分，受到此類***可以讓***者在受害者的瀏覽器中執(zhí)行任意的HTML和JavaScript。

2. 存儲式XSS：你的應(yīng)用或者API將未凈化的用戶輸入進行存儲，并在其他用戶或者管理員的頁面展示出來。存儲型XSS一般被認(rèn)為是高?；驀?yán)重的風(fēng)險。

3. 基于DOM的XSS：會動態(tài)的將***者操控的內(nèi)容加入到頁面的 JavaScript框架、單頁面程序或API中。為避免此類***，你應(yīng)該禁止將***者可控的數(shù)據(jù)發(fā)送給不安全的JavaScript API。

典型的XSS***造成的結(jié)果包含：盜取Session、賬戶、繞過MFA、DIV替換、對用戶瀏覽器的***（例如：惡意軟件下載、鍵盤記錄）以及其他用戶側(cè)的***。

如何防止？

防止XSS，需要將不可信的數(shù)據(jù)與動態(tài)的瀏覽器內(nèi)容區(qū)分開：

1. 使用已解決XSS問題的框架，如：Ruby 3.0 或 React JS。了解每個框架對XSS保護的局限性，并適當(dāng)?shù)靥幚砦锤采w的用例。

2. 為了避免反射式或存儲式的XSS漏洞，最好的辦法是根據(jù)HTML 輸出的上下文（包括：主體、屬性、JavaScript、CSS或URL） 對所有不可信的HTTP請求數(shù)據(jù)進行恰當(dāng)?shù)霓D(zhuǎn)義 。

3. 在客戶端修改瀏覽器文檔時，為了避免DOM XSS***，最好的選擇是實施上下文敏感數(shù)據(jù)編碼。如果這種情況不能避免，可以采用《OWASP Cheat Sheet ‘DOM based XSS Prevention ‘》 一文中描述的類似于上下文敏感的轉(zhuǎn)義技術(shù)，并應(yīng)用于瀏覽器API。

4. 使用內(nèi)容安全策略（CSP）是對抗XSS的最終防御策略。如果不存在可以通過本地文件存放惡意代碼的漏洞（例如：路徑遍歷覆蓋和允許在網(wǎng)絡(luò)中傳輸?shù)囊资?**的庫），則該策略是有效的。

***案例場景

場景#1：應(yīng)用程序在下面的HTML代碼段構(gòu)造中使用了未經(jīng)驗證或轉(zhuǎn)義的不可信的數(shù)據(jù)源：

***者在瀏覽器中修改“CC” 參數(shù)為如下值：

這個***會導(dǎo)致受害者的會話ID被發(fā)送到***者的網(wǎng)站，使得***者能夠劫持用戶當(dāng)前會話。

內(nèi)容安全策略 (CSP)

內(nèi)容安全策略 (CSP) 是一個額外的安全層，用于檢測并削弱某些特定類型的***，包括跨站腳本 (XSS) 和數(shù)據(jù)注入***等。無論是數(shù)據(jù)盜取、網(wǎng)站內(nèi)容污染還是惡意軟件，這些***都是主要的手段。

CSP 被設(shè)計成完全向后兼容（除CSP2 在向后兼容有明確提及的不一致外）。不支持CSP的瀏覽器也能與實現(xiàn)了CSP的服務(wù)器正常合作，反之亦然：不支持 CSP 的瀏覽器只會忽略它，如常運行，默認(rèn)為網(wǎng)頁內(nèi)容使用標(biāo)準(zhǔn)的同源策略。如果網(wǎng)站不提供 CSP Header，瀏覽器將使用標(biāo)準(zhǔn)的同源策略。

為使CSP可用, 你需要配置你的網(wǎng)絡(luò)服務(wù)器返回? Content-Security-Policy? HTTP Header ( 有時你會看到一些關(guān)于X-Content-Security-Policy Header的提法, 那是舊版本，你無須再如此指定它)。

除此之外,? <meta>? 元素也可以被用來配置該策略, 例如：

上下文敏感數(shù)據(jù)編碼（XSS編碼與繞過）

對于了解Web安全的朋友來說，都知道XSS這種漏洞，其危害性不用強調(diào)。一般對于該漏洞的防護有兩個思路：一是過濾敏感字符，諸如【<，>，script，'】等，另一種是對敏感字符進行html編碼，諸如php中的htmlspecialchars()函數(shù)。

一般情況，正確實施這兩種方案之一就可以有效防御XSS漏洞了。但其實也會有一些場景，即使實施了這兩種方案，***者也可以繞過防護，導(dǎo)致XSS漏洞被利用。

場景一：XSS注入點在某個html標(biāo)簽屬性中，代碼片段如下：

?

可以看到，這里防護措施采用的是方案一：過濾敏感字符。這里如果輸入javascript:alert (11)，是會被過濾掉的，輸出的內(nèi)容會是：

?

?

場景二：XSS注入點在js標(biāo)簽中，代碼片段如下：

?

?

這里采用的防護措施是第二種，即使用php內(nèi)置函數(shù)htmlspecialchars對敏感字符進行編碼。如果輸入正常的payload，如：<img src=1 onerror=alert(11)>，是不會有彈窗的，此時瀏覽器的輸出如下圖：

?

?

這里的敏感字符< >，已經(jīng)被html編碼了，最后在<div>標(biāo)簽里面輸出的時候，瀏覽器再使用html解碼將其原文顯示出來，但是并不會觸發(fā)js引擎，所以也就沒有彈窗。

下圖是js編碼后的payload：

?

?

八、不安全的反序列化

不安全的反序列化會導(dǎo)致遠(yuǎn)程代碼執(zhí)行。即使反序列化缺陷不會導(dǎo)致遠(yuǎn)程代碼執(zhí)行，***者也可以利用它們來執(zhí)行***，包括：重播***、注入***和特權(quán)升級***。

?

?

可利用性：難

對反序列化的利用非常困難。因為在不更改或調(diào)整底層可被利用代碼的情況下，現(xiàn)成的反序列化漏洞很難被使用。

可檢測性：一般

有些工具可以被用于發(fā)現(xiàn)反序列化缺陷，但經(jīng)常需要人工幫助來驗證發(fā)現(xiàn)的問題。希望有關(guān)反序列化缺陷的普遍性數(shù)據(jù)將隨著工具的開發(fā)而被更多的識別和解決。

技術(shù)影響：嚴(yán)重

反序列化缺陷的影響不能被低估。它們可能導(dǎo)致遠(yuǎn)程代碼執(zhí)行***，這是可能發(fā)生的最嚴(yán)重的***之一。

自查：您的應(yīng)用程序脆弱嗎？

如果反序列化進攻者提供惡意代碼或者被篡改過的對象，將會使整個應(yīng)用程序和API變的脆弱，這可能會導(dǎo)致以下兩種主要類型的***：

1. 如果應(yīng)用中存在可以在反序列化過程中或者之后被改變行為的類，則***者可以通過改變應(yīng)用邏輯或者實現(xiàn)遠(yuǎn)程代碼執(zhí)行***，這種***方式被稱為對象和數(shù)據(jù)結(jié)構(gòu)***。

2. 典型的數(shù)據(jù)篡改***，如訪問控制相關(guān)的***，其中使用了現(xiàn)有的數(shù)據(jù)結(jié)構(gòu)，但內(nèi)容發(fā)生了變化。

在應(yīng)用程序中，序列化可能被用于:

• 遠(yuǎn)程和進程間通信（RPC / IPC）

• 連線協(xié)議、Web服務(wù)、消息代理

• 緩存/持久性

• 數(shù)據(jù)庫、緩存服務(wù)器、文件系統(tǒng)

• HTTP cookie、HTML表單參數(shù)、API身份驗證令牌

如何防止？

唯一安全的架構(gòu)模式是：不接受來自不受信源的序列化對象，或使用只允許原始數(shù)據(jù)類型的序列化媒體。 如果上述均無法實現(xiàn)，請考慮使用下面的方法：

1. 執(zhí)行完整性檢查，如：任何序列化對象的數(shù)字簽名，以防止惡意對象創(chuàng)建或數(shù)據(jù)篡改。

2. 在創(chuàng)建對象之前強制執(zhí)行嚴(yán)格的類型約束，因為代碼通常被期望成一組可定義的類。繞過這種技術(shù)的方法已經(jīng)被證明，所以完全依賴于它是不可取的。

3. 如果可能，隔離運行那些在低特權(quán)環(huán)境中的反序列化代碼。

4. 記錄反序列化的例外情況和失敗信息，如：傳入的類型不是預(yù)期的類型，或者反序列處理引發(fā)的例外情況。

5. 限制或監(jiān)視來自于容器或服務(wù)器傳入和傳出的反序列化網(wǎng)絡(luò)連接。

6. 監(jiān)控反序列化，當(dāng)用戶持續(xù)進行反序列化時，對用戶進行警告。

***案例場景

場景 #1：一個React應(yīng)用程序調(diào)用了一組Spring Boot微服務(wù)，為了確保原有的代碼不變，解決方法是序列化用戶狀態(tài)，并在每次請求時來回傳遞。這時，***者可利用“R00”Java對象簽名，并使用Java Serial Killer工具在應(yīng)用服務(wù)器上獲得遠(yuǎn)程代碼執(zhí)行。

場景 #2：一個PHP論壇使用PHP對象序列化來保存一個“超級”cookie。該cookie包含了用戶的ID、角色、密碼哈希和其他狀態(tài)：

a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

***者可以更改序列化對象以授予自己為admin權(quán)限：

a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

九、使用含有已知漏洞的組件

組件（例如：庫、框架和其他軟件模塊）擁有和應(yīng)用程序相同的權(quán)限。如果應(yīng)用程序中含有已知漏洞的組件被***者利用，可能會造成嚴(yán)重的數(shù)據(jù)丟失或服務(wù)器接管。同時，使用含有已知漏洞的組件和API會破壞應(yīng)用程序的防御手段，造成各種***并產(chǎn)生嚴(yán)重影響。

十、不足的日志記錄和監(jiān)控

不足的日志記錄和監(jiān)控，以及事件響應(yīng)缺失或無效的集成，使***者能夠進一步***系統(tǒng)，并篡改、提取或銷毀數(shù)據(jù)。大多數(shù)缺陷研究顯示，缺陷被檢測出的時間超過200天，且通常通過外部檢測方檢測，而不是通過內(nèi)部流程或監(jiān)控檢測。

未雨綢繆 - 項目中如何應(yīng)對

開發(fā)人員需要做些什么？

1. 提高風(fēng)險意識

2. Code Review

3. 建立可重復(fù)使用的安全流程和標(biāo)準(zhǔn)安全控制

4. 安全檢測工具

a)???? ZAP Tools

b)??? 靜態(tài)代碼分析

1. 建立持續(xù)性的應(yīng)用安全測試

2. 管理完整的應(yīng)用程序生命周期

以上便是從本次公開課分享——“WebApp 安全風(fēng)險與防護（系列二）”中截取的部分內(nèi)容，相信一定能對您的WebApp應(yīng)用程序安全防護有所幫助。