1 目的

通過對(duì)主流的WEB高危漏洞表現(xiàn)形式和危害介紹牧氮，增強(qiáng)WEB應(yīng)用開發(fā)人員的安全意識(shí)；以WEB應(yīng)用開發(fā)安全原則和解決方案規(guī)范開發(fā)過程中的安全控制旁舰，推動(dòng)開發(fā)人員編寫強(qiáng)壯安全的代碼茫舶。

3 名詞解釋

1) Cross Site Script（XSS）跨站腳本攻擊:

攻擊者利用應(yīng)用程序的動(dòng)態(tài)展示數(shù)據(jù)功能翩剪，在html頁(yè)面里嵌入惡意代碼。當(dāng)用戶瀏覽該頁(yè)之時(shí)祟偷，這些嵌入在html中的惡意代碼會(huì)被執(zhí)行察滑，用戶瀏覽器被攻擊者控制，從而達(dá)到攻擊者的特殊目的修肠。

跨站腳本攻擊有三種攻擊形式

• 反射型跨站腳本攻擊:攻擊者會(huì)通過社會(huì)工程學(xué)手段贺辰，發(fā)送一個(gè)URL連接給用戶打開，在用戶打開頁(yè)面的同時(shí)嵌施，瀏覽器會(huì)執(zhí)行頁(yè)面中嵌入的惡意腳本饲化。
• 存儲(chǔ)型跨站腳本攻擊：攻擊者利用web應(yīng)用程序提供的錄入或修改數(shù)據(jù)功能，將數(shù)據(jù)存儲(chǔ)到服務(wù)器或用戶cookie中吗伤，當(dāng)其他用戶瀏覽展示該數(shù)據(jù)的頁(yè)面時(shí)吃靠，瀏覽器會(huì)執(zhí)行頁(yè)面中嵌入的惡意腳本。所有瀏覽者都會(huì)受到攻擊足淆。
• DOM****跨站攻擊：由于html頁(yè)面中巢块，定義了一段JS礁阁，根據(jù)用戶的輸入，顯示一段html代碼夕冲，攻擊者可以在輸入時(shí)氮兵，插入一段惡意腳本，最終展示時(shí)歹鱼，會(huì)執(zhí)行惡意腳本泣栈。

2) SQL injection，SQL注入攻擊

當(dāng)應(yīng)用程序?qū)⒂脩糨斎氲膬?nèi)容弥姻，拼接到SQL語(yǔ)句中南片，一起提交給數(shù)據(jù)庫(kù)執(zhí)行時(shí)，就會(huì)產(chǎn)生SQL注入威脅庭敦。

用戶的輸入疼进，也是SQL語(yǔ)句的一部分，所以攻擊者可以利用這部分可以控制的內(nèi)容秧廉，注入自己定義的語(yǔ)句伞广，改變SQL語(yǔ)句執(zhí)行邏輯，讓數(shù)據(jù)庫(kù)執(zhí)行任意自己需要的指令疼电。通過控制部分SQL語(yǔ)句嚼锄，攻擊者可以查詢數(shù)據(jù)庫(kù)中任何自己需要的數(shù)據(jù)，利用數(shù)據(jù)庫(kù)的一些特性蔽豺，可以直接獲取數(shù)據(jù)庫(kù)服務(wù)器的系統(tǒng)權(quán)限区丑。

3) ****File upload****，任意文件上傳攻擊

Web應(yīng)用程序在處理用戶上傳的文件時(shí)修陡，沒有判斷文件的擴(kuò)展名是否在允許的范圍內(nèi)沧侥，就把文件保存在服務(wù)器上，導(dǎo)致惡意用戶可以上傳任意文件魄鸦，甚至上傳腳本木馬到web服務(wù)器上宴杀，直接控制web服務(wù)器。

4) 任意文件下載

當(dāng)用戶通過web 下載文件時(shí)拾因，所下載文件及路徑為變量形式傳給程序婴氮，程序未對(duì)下載文件及路徑做檢測(cè)茅姜，導(dǎo)致用戶可隨意輸入下載地址睛廊，造成任意文件下載漏洞的出現(xiàn)政敢。

4 WEB威脅及應(yīng)對(duì)措施

4.1 輸入驗(yàn)證

4.1.1 SQL注入

4.1.1.1 表現(xiàn)形式

當(dāng)應(yīng)用程序?qū)⒂脩糨斎氲膬?nèi)容迅皇，拼接到SQL語(yǔ)句中迫靖，一起提交給數(shù)據(jù)庫(kù)執(zhí)行膳灶，就會(huì)產(chǎn)生SQL注入威脅悔常。

由于用戶的輸入循帐，也是SQL語(yǔ)句的一部分护赊，所以攻擊者可以利用這部分可以控制的內(nèi)容惠遏，注入自己定義的語(yǔ)句砾跃，改變SQL語(yǔ)句執(zhí)行邏輯，讓數(shù)據(jù)庫(kù)執(zhí)行任意自己需要的指令节吮。通過控制部分SQL語(yǔ)句抽高，攻擊者可以查詢數(shù)據(jù)庫(kù)中任何自己需要的數(shù)據(jù)，利用數(shù)據(jù)庫(kù)的一些特性透绩，可以直接獲取數(shù)據(jù)庫(kù)服務(wù)器的系統(tǒng)權(quán)限翘骂。

4.1.1.2 危險(xiǎn)性

1. 可讀取數(shù)據(jù)庫(kù)中的庫(kù)和表

2. 可執(zhí)行系統(tǒng)命令

3. 可以修改任意文件

4. 可以安裝木馬后門

4.1.1.3 開發(fā)原則

1. 前端頁(yè)面部分

a) 最小輸入原則

限定輸入長(zhǎng)度及類型：瀏覽器限定字符串最大為2083字節(jié)(微軟 Internet Explorer)實(shí)際可使用的URL長(zhǎng)度為2048字節(jié)。

b) 客戶端與服務(wù)器端必須都做驗(yàn)證：
建立白名單帚豪，拒絕所有其他數(shù)據(jù)
服務(wù)端做數(shù)據(jù)處理的SQL語(yǔ)句不允許拼接參數(shù)碳竟，使用參數(shù)化方式創(chuàng)建SQL語(yǔ)句

c) 數(shù)據(jù)庫(kù)部分：
儲(chǔ)存過程中不允許出現(xiàn)：exec

4.1.1.4 解決方案

1. 【輔助】過濾或轉(zhuǎn)義

a) 對(duì)參數(shù)進(jìn)行關(guān)鍵詞過濾（所有可能操作數(shù)據(jù)庫(kù)信息的關(guān)鍵字）

b) 對(duì)關(guān)鍵字進(jìn)行轉(zhuǎn)義

2. 【首選】使用參數(shù)化方式創(chuàng)建SQL語(yǔ)句進(jìn)行數(shù)據(jù)處理

3. 【推薦】使用第三方安全框架ESAPI處理參數(shù)

JAVA支持良好，代碼示例：

4.1.2 跨站腳本攻擊

4.1.2.1 表現(xiàn)形式

Web應(yīng)用程序從用戶處獲得輸入狸臣，不經(jīng)驗(yàn)證莹桅，直接在Web頁(yè)面上輸出。漏洞類型：

1. 存儲(chǔ)型XSS / 持久型

2. 反射型XSS / 非持久型

3. DOM based XSS

4.1.2.2 危害性

1. 盜取用戶cookie烛亦，偽造用戶身份登錄诈泼。

2. 控制用戶瀏覽器。

3. 結(jié)合瀏覽器及其插件漏洞煤禽，下載病毒木馬到瀏覽者的計(jì)算機(jī)上執(zhí)行厂汗。

4. 衍生URL跳轉(zhuǎn)漏洞。

5. 使官方網(wǎng)站出現(xiàn)釣魚頁(yè)面呜师。

6. 蠕蟲攻擊

7. 盜取客戶端鍵盤記錄

4.1.2.3 開發(fā)原則

1. 對(duì)輸入進(jìn)行安全性白名單/黑名單驗(yàn)證，可采用正則表達(dá)式贾节。

a) 統(tǒng)一大小寫之后再驗(yàn)證汁汗，并且如果采用危險(xiǎn)字符（特殊字符+關(guān)鍵字）過濾的方式進(jìn)行驗(yàn)證，勿將危險(xiǎn)字符替換為空栗涂，容易產(chǎn)生繞過知牌。

2. 驗(yàn)證所有的headers, cookies, query strings, form fields, hidden fields。

3. 對(duì)即將輸出到前端的用戶可控?cái)?shù)據(jù)進(jìn)行編碼轉(zhuǎn)義斤程。

4. 不要在JS文件中編寫重要代碼角寸。

5. 在測(cè)試階段, 進(jìn)行必要的安全測(cè)試和檢驗(yàn)。

4.1.2.4 解決方案

1. 【輔助】輸入驗(yàn)證：

驗(yàn)證輸入忿墅，確保所有可能構(gòu)成JavaScript扁藕、CSS等語(yǔ)句的特殊字符及關(guān)鍵字都被驗(yàn)證（過濾或轉(zhuǎn)義）。針對(duì)必須包含富文本的特殊需求疚脐，謹(jǐn)慎設(shè)置白名單亿柑。

2. 【強(qiáng)制】輸出轉(zhuǎn)義：

a) HTML標(biāo)簽轉(zhuǎn)義，下表為需要編碼的字符：

b) JavaScript內(nèi)容轉(zhuǎn)義棍弄。Java示例代碼:

c) CSS style內(nèi)容轉(zhuǎn)義：把除了字母望薄、數(shù)字外的所有字符都編碼成十六進(jìn)制疟游，形式為“\uHH”

d) URL內(nèi)容安全編碼：可使用URLEncode，將字符轉(zhuǎn)換成“%HH”的格式痕支。

e) XML中對(duì)數(shù)據(jù)部分做HTML轉(zhuǎn)義颁虐。示例代碼：

f) JSON內(nèi)容做HTMLEscape，再對(duì)變量做一次JavascriptEscape卧须。示例：

3. 【強(qiáng)制輔助】給Cookies加上HttpOnly選項(xiàng)

在Http響應(yīng)中另绩，使用Set-Cookie時(shí)，添加額外的標(biāo)簽故慈，該標(biāo)簽會(huì)保護(hù)cookie板熊，防止JavaScript讀取

• 使用HttpOnly函數(shù)，javax.servlet.http.Cookie

• 當(dāng)使用Java EE 6和以上版本察绷，HttpOnly flag可以在web.xml中設(shè)置

  
  
  image.png

• Tomcat六以上的版本干签，可以在context.xml中添加useHttpOnly屬性

  
  

4. 【推薦】預(yù)防XSS的安全框架：

a) JAVA：ESAPI框架，對(duì)富文本處理有良好的支持

以下舉例框架中常用的Encoder接口提供的轉(zhuǎn)義方法：

     [圖片上傳失敗...(image-ec308-1607912037170)]

** 示例**:/lessons/CrossSiteScripting/SearchStaff.jsp

     [圖片上傳失敗...(image-569c97-1607912037170)]

                            [圖片上傳失敗...(image-bd142-1607912037170)]

b) .NET : ANTIXSS支持

       [圖片上傳失敗...(image-948b19-1607912037170)]

c) PHP: XSS支持

        [圖片上傳失敗...(image-daafb4-1607912037170)]

5. 【強(qiáng)制】禁止引用第三方腳本拆撼，禁止iframe引用第三方頁(yè)面容劳。

4.1.3 任意文件上傳

4.1.3.1 表現(xiàn)形式

Web應(yīng)用程序在處理用戶上傳的文件操作時(shí)，如果用戶上傳文件的路徑闸度、文件名竭贩、擴(kuò)展名成為用戶可控?cái)?shù)據(jù)，就會(huì)導(dǎo)致直接上傳腳本木馬到web服務(wù)器上莺禁，直接控制web 服務(wù)器留量。

1. 中間件解析漏洞

a) IIS6.0

Microsoft IIS 可以執(zhí)行ASP 或者任何其他可執(zhí)行擴(kuò)展執(zhí)行任何擴(kuò)展名文件，如"a.asp;.jpg"就以ASP或ASPX 文件方式在服務(wù)器上執(zhí)行哟冬，需要文件上傳程序通過檢查文件名的最后一段作為擴(kuò)展名來(lái)保護(hù)系統(tǒng)楼熄。利用這個(gè)漏洞，攻擊者可以繞過保護(hù)把危險(xiǎn)的可執(zhí)行文件上傳到服務(wù)器上浩峡。

上傳a.asp;.jpg,****服務(wù)器發(fā)現(xiàn)后綴為jpg****可岂，允許上傳，但通過web****訪問時(shí)由;****自動(dòng)截?cái)嗪苍郑瑘?zhí)行a.asp****木馬程序(iis6.0****解析漏洞)

b) 00截?cái)嗌蟼髀┒?/p>

上傳文件名為x.php%00.jpg 時(shí)缕粹，php 驗(yàn)證程序后綴名為JPG 允許上傳，當(dāng)php取文件名時(shí)纸淮，讀取到%00 會(huì)認(rèn)為是截?cái)喾?hào)平斩，以x.php 進(jìn)行存儲(chǔ)，最終導(dǎo)致php 文件上傳咽块。

4.1.3.2 危害性

惡意用戶可以上傳任意文件双戳，甚至上傳后門、木馬，病毒飒货，惡意腳本或者WebShell到web服務(wù)器上魄衅，直接控制web服務(wù)器。

4.1.3.3 開發(fā)原則

1. 由程序自定義上傳文件的文件名稱塘辅。

2. 只接受指定類型的文件（如zip晃虫、圖片等），并驗(yàn)證上傳文件類型扣墩。

3. 檢查上傳文件文件大小哲银。

4. 重要目錄設(shè)置文件訪問權(quán)限。（Java SecurityManager）

5. 所有涉及路徑的操作驗(yàn)證路徑安全性呻惕。

4.1.3.4 解決方案

1. 【推薦】上傳文件要保存的文件名和目錄名由系統(tǒng)根據(jù)策略生成荆责，不允許用戶自定義。

2. 【首選】允許用戶自定義文件名的情況亚脆，需要做兩個(gè)類型的驗(yàn)證：上傳文件目錄限制及文件類型白名單驗(yàn)證做院。

• • 上傳文件的目錄必須是http請(qǐng)求無(wú)法直接訪問到的
  • 上傳文件的目錄必須限定于指定目錄，為達(dá)到此需求同樣需驗(yàn)證文件名濒持，可借鑒操作系統(tǒng)對(duì)文件名稱的要求：不能包含下列字符：""键耕、"/"、":"柑营、""屈雄、"?"、" " "官套、"<"酒奶、">"、"|"奶赔。*
  • 設(shè)置文件類型白名單惋嚎，并且正確驗(yàn)證文件類型：對(duì)于絕大部分開發(fā)人員使用的截取"."來(lái)判斷文件名的方式，禁止截取最后一個(gè)"."字符做判斷纺阔，須以"."為分界字符截取字符串集合，循環(huán)驗(yàn)證集合內(nèi)所有值修然，或者直接截取第一個(gè)"."字符（即文件名除了擴(kuò)展名外不允許出現(xiàn)"."字符）笛钝。
  • 重要文件直接驗(yàn)證文件內(nèi)容

3. 【推薦】圖片上傳，通過處理（縮略圖愕宋、水印等）玻靡，無(wú)異常后再保存到服務(wù)器。

4. 【強(qiáng)制輔助】代碼層面也須設(shè)置文件上傳目錄的權(quán)限中贝，禁止文件執(zhí)行：Java SecurityManager囤捻，可控制文件的讀寫、刪除邻寿、執(zhí)行權(quán)限蝎土。

5. 【推薦】上傳文件需要做日志記錄视哑。

4.1.4 任意文件下載

4.1.4.1 表現(xiàn)形式

當(dāng)用戶通過web下載文件時(shí)，所下載文件及路徑為變量形式傳給程序誊涯，例：http://www.aaaaaa.com/download.action?file=centos.iso挡毅，若程序未對(duì)下載文件及路徑做檢測(cè)，就會(huì)導(dǎo)致用戶可隨意輸入下載地址暴构，造成任意文件下載漏洞的出現(xiàn)跪呈。

代碼實(shí)例JAVA：

           [圖片上傳失敗...(image-c4cd0d-1607912037170)]

通過以上代碼，用戶可以構(gòu)建以下惡意請(qǐng)求：http://www.aaaaa.com/download.*?file=../../../etc/passwd取逾，當(dāng)用戶提交以上連接耗绿，可以下載/etc/passwd 文件，導(dǎo)致安全隱患砾隅。

4.1.4.2 危害性

任意文件下載漏洞為高風(fēng)險(xiǎn)漏洞误阻，可以讀取服務(wù)器配置文件，相關(guān)用戶名密碼等琉用，造成非常大的安全隱患堕绩。

4.1.4.3 開發(fā)原則

1. 要下載的文件地址保存至數(shù)據(jù)庫(kù)中，讓用戶提交文件對(duì)應(yīng)ID下載文件邑时。

2. 下載文件之前做權(quán)限判斷奴紧。

3. 文件放在web無(wú)法直接訪問的目錄下。

4. 記錄文件下載日志晶丘。

5. 不允許提供目錄遍歷服務(wù)黍氮。所有涉及路徑的操作驗(yàn)證路徑安全性。

4.1.4.4 解決方案

1. 【輔助】限定文件讀寫權(quán)限（java SecurityManager）

2. 【首選】以下解決方案二選一

• • 驗(yàn)證外部輸入的文件下載地址（文件名）浅浮，驗(yàn)證合法性沫浆，可借鑒操作系統(tǒng)對(duì)文件名稱的要求：不能包含下列字符：""、"/"滚秩、":"专执、"*"、"?"郁油、" " "本股、"<"、">"桐腌、"|"拄显。

  • 使用與下載地址有映射關(guān)系的md5串進(jìn)行映射下載，下載地址存儲(chǔ)于數(shù)據(jù)庫(kù)案站，如下鏈接：

    http://www. aaaaaa.com/download.php?file=(32 位md5 串)

<pre style="margin: 10px 0px 0px 30px; color: rgb(23, 43, 77); font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"> [圖片上傳失敗...(image-c457e5-1607912037169)] </pre>

4.1.5 服務(wù)器端請(qǐng)求偽造(SSRF)

4.1.5.1 表現(xiàn)形式

SSRF(Server-Side Request Forgery：服務(wù)器端請(qǐng)求偽造躬审，由攻擊者構(gòu)造形成由服務(wù)端發(fā)起請(qǐng)求的安全漏洞。也可稱為：未驗(yàn)證的重定向或轉(zhuǎn)發(fā)。

當(dāng)服務(wù)端向內(nèi)網(wǎng)或第三方服務(wù)請(qǐng)求資源的時(shí)候承边，URL部分或全部可控遭殉，此時(shí)沒有對(duì)目標(biāo)地址做過濾與限制，漏洞引發(fā)炒刁。

一般情況下恩沽，SSRF攻擊的目標(biāo)是從外網(wǎng)無(wú)法訪問的內(nèi)部系統(tǒng)。

由于它是由服務(wù)端發(fā)起的翔始，所以它能夠請(qǐng)求到與它相連而與外網(wǎng)隔離的內(nèi)部系統(tǒng)罗心。

4.1.5.2 危害性

1. 對(duì)服務(wù)器所在內(nèi)網(wǎng)、本地進(jìn)行端口掃描城瞎，獲取一些服務(wù)的banner信息;

2. 攻擊運(yùn)行在內(nèi)網(wǎng)或本地的應(yīng)用程序（比如溢出）;

3. 對(duì)內(nèi)網(wǎng)web應(yīng)用進(jìn)行指紋識(shí)別渤闷，通過訪問默認(rèn)文件實(shí)現(xiàn);

4. 攻擊內(nèi)外網(wǎng)的web應(yīng)用，主要是使用get參數(shù)就可以實(shí)現(xiàn)的攻擊（比如struts2脖镀，sqli等）;

5. 利用file協(xié)議讀取本地文件等飒箭。

4.1.5.3 開發(fā)原則

1. 解析目標(biāo)URL，獲取其Host

2. 解析Host蜒灰，獲取Host指向的IP地址

3. 檢查IP地址是否為內(nèi)網(wǎng)IP

4. 請(qǐng)求URL

5. 如果有跳轉(zhuǎn)弦蹂，拿出跳轉(zhuǎn)URL，執(zhí)行1

4.1.5.4 解決方案

1. 內(nèi)網(wǎng)請(qǐng)求：

• • 【首選】設(shè)置內(nèi)網(wǎng)可請(qǐng)求地址白名單强窖，并將地址存于數(shù)據(jù)庫(kù)凸椿，設(shè)置映射關(guān)系標(biāo)識(shí)，前端用戶必須通過標(biāo)識(shí)來(lái)選擇要請(qǐng)求的地址翅溺∧月或者設(shè)置黑名單內(nèi)網(wǎng) IP，判斷請(qǐng)求地址咙崎，限制在黑名單之外优幸。以上方案原則上可二選一，實(shí)際應(yīng)用推薦白名單
  • 【強(qiáng)制輔助】統(tǒng)一錯(cuò)誤信息褪猛，避免用戶根據(jù)錯(cuò)誤信息來(lái)判斷遠(yuǎn)程服務(wù)器端口狀態(tài)网杆。
  • 【推薦輔助】限制請(qǐng)求的端口為 HTTP 常用端口，比如 80伊滋、443碳却、8080、8090新啼。
  • 【強(qiáng)制輔助】禁用不需要的協(xié)議追城。僅僅允許 HTTP 和 HTTPS 請(qǐng)求刹碾≡镒玻可以防止類似于file://、gopher://和ftp://等引起的問題。

2. 外網(wǎng)請(qǐng)求：以下驗(yàn)證至少存在一種物舒，并且首選白名單

• • 【首選】根據(jù)需求設(shè)置外網(wǎng)請(qǐng)求地址白名單并驗(yàn)證色洞。
  • 【次選】無(wú)法設(shè)置白名單的情況，更需謹(jǐn)慎對(duì)待當(dāng)前頁(yè)面冠胯，對(duì)XSS火诸、cookie安全此類的安全策略應(yīng)更嚴(yán)格≤欤可在需要考慮SSRF攻擊但又無(wú)法設(shè)置白名單的位置添加url防篡改機(jī)制置蜀。如果有數(shù)據(jù)返回，需過濾或驗(yàn)證返回?cái)?shù)據(jù)悉盆《⒒纾可根據(jù)業(yè)務(wù)需求判斷返回包是否包含預(yù)期以外的風(fēng)險(xiǎn)數(shù)據(jù)。

3. 【推薦輔助】禁止302跳轉(zhuǎn)焕盟。

4.1.6 跨站請(qǐng)求偽造(CSRF)

4.1.6.1 表現(xiàn)形式

攻擊者在用戶瀏覽網(wǎng)頁(yè)時(shí)秋秤，利用頁(yè)面元素（例如img，的src）脚翘，強(qiáng)迫受害者的瀏覽器向Web應(yīng)用程序發(fā)送一個(gè)改變用戶信息的請(qǐng)求灼卢。

一句話理解：攻擊者借你的cookie（登陸權(quán)限）讓你親自完成attacker布置的操作(添加/刪除/修改)并且你并不知道這個(gè)過程。

4.1.6.2 危害性

攻擊者利用被攻擊者的身份發(fā)起了某些被攻擊者原本不知情的網(wǎng)絡(luò)請(qǐng)求来农。包括以被攻擊者的身份發(fā)布一條微博鞋真，以被攻擊者的身份發(fā)布一條留言，以被攻擊者的身份關(guān)注某個(gè)用戶的微博等备图。著名的微博蠕蟲就是利用這種漏洞灿巧，造成了較大的影響。

4.1.6.3 解決方案

1. 【強(qiáng)制輔助】所有敏感請(qǐng)求揽涮，都使用POST方式提交

2. 【強(qiáng)制策略】重要操作做二次驗(yàn)證抠藕，如短信認(rèn)證，二次密碼認(rèn)證蒋困，驗(yàn)證碼盾似、生物驗(yàn)證等。

注：所有的驗(yàn)證碼必須與實(shí)際參與業(yè)務(wù)的參數(shù)在同一請(qǐng)求內(nèi)提交服務(wù)端雪标，例：修改密碼時(shí)零院，需要確保驗(yàn)證碼、新密碼村刨、舊密碼在同一請(qǐng)求內(nèi)提交告抄，避免驗(yàn)證碼繞過。

所有驗(yàn)證碼不能傳遞到客戶端嵌牺，指標(biāo)：客戶端右鍵“查看源碼”看不到驗(yàn)證碼打洼。

3. 【強(qiáng)制】使用token防御

用戶交互時(shí)龄糊，設(shè)置一個(gè)具有超時(shí)機(jī)制的隨機(jī)token，種植在用戶的cookie 中募疮。當(dāng)用戶提交表單時(shí)炫惩，生成隱藏域，值為cookie中隨機(jī)token阿浓，用戶提交表單后匹配兩處token值他嚷，來(lái)判斷是否為用戶提交。

• • 使用ESAPI框架生成token

    [圖片上傳失敗...(image-34c58-1607912037170)]

4. 【錯(cuò)誤示例】不要靠驗(yàn)證referer的方式預(yù)防CSRF

驗(yàn)證用戶提交數(shù)據(jù)的referer 信息芭毙，當(dāng)為提交頁(yè)時(shí)筋蓖，說(shuō)明為用戶提交，當(dāng)為其他頁(yè)面時(shí)退敦，說(shuō)明為csrf 攻擊扭勉。但是，****referer****是很容易被篡改的苛聘。所以涂炎，不要靠驗(yàn)證referer****的方式預(yù)防CSRF****。

5. 【參考】二次驗(yàn)證设哗、token驗(yàn)證唱捣、referer驗(yàn)證，三種驗(yàn)證的安全度：二次驗(yàn)證>token驗(yàn)證>referer驗(yàn)證网梢，正常請(qǐng)求使用token驗(yàn)證震缭，重要請(qǐng)求使用二次驗(yàn)證。

4.1.7 XML外部實(shí)體攻擊(XXE)

4.1.7.1 表現(xiàn)形式

XXE漏洞全稱XML External Entity Injection 即xml外部實(shí)體注入漏洞战虏，XXE漏洞發(fā)生在應(yīng)用程序解析XML輸入時(shí)拣宰，沒有禁止外部實(shí)體的加載，導(dǎo)致可加載惡意外部文件和代碼烦感，造成任意文件讀取巡社、命令執(zhí)行、內(nèi)網(wǎng)端口掃描手趣、攻擊內(nèi)網(wǎng)網(wǎng)站晌该、發(fā)起Dos攻擊等危害。

XXE漏洞觸發(fā)的點(diǎn)往往是可以上傳xml文件的位置绿渣，沒有對(duì)上傳的xml文件進(jìn)行過濾朝群，導(dǎo)致可上傳惡意xml文件。

DTD實(shí)體是用于定義引用普通文本或特殊字符的快捷方式的變量中符，可以內(nèi)部聲明或外部引用姜胖。

• • 內(nèi)部聲明實(shí)體

    [圖片上傳失敗...(image-5b74a3-1607912037170)]

• • 引用外部實(shí)體

    [圖片上傳失敗...(image-6c1331-1607912037170)]

• • 或者

    [圖片上傳失敗...(image-9f65a2-1607912037170)]

4.1.7.2 危害性

1. 任意文件讀取

2. 命令執(zhí)行

3. 內(nèi)網(wǎng)端口掃描

4. 攻擊內(nèi)網(wǎng)網(wǎng)站

5. 發(fā)起Dos攻擊

4.1.7.3 開發(fā)原則

1. 使用開發(fā)語(yǔ)言提供的禁用外部實(shí)體的方法

2. 過濾用戶提交的XML數(shù)據(jù)

4.1.7.4 解決方案

1. 【推薦】使用開發(fā)語(yǔ)言提供的禁用外部實(shí)體的方法

• • Php：

    [圖片上傳失敗...(image-2f6914-1607912037170)]

• • JAVA：

    [圖片上傳失敗...(image-93e0cf-1607912037170)]

• • Python：

    [圖片上傳失敗...(image-d78ad9-1607912037170)]

2. 【強(qiáng)制】過濾用戶提交的XML數(shù)據(jù)

過濾關(guān)鍵詞：<!DOCTYPE和<!ENTITY，或者SYSTEM和PUBLIC

參考資料：https://security.tencent.com/index.php/blog/msg/69

4.1.8 實(shí)體（Bean淀散、JSON）注入

4.1.8.1 表現(xiàn)形式

在前后端進(jìn)行數(shù)據(jù)交互時(shí)右莱，數(shù)據(jù)形式以JSON堵第、Bean為主。其中JSON可通過API直接轉(zhuǎn)換成Bean實(shí)體隧出；Bean可以通過spring mvc或struts等框架由前臺(tái)表單參數(shù)自動(dòng)填充屬性值，組成Bean實(shí)體阀捅。如果沒有對(duì)這兩種類型參數(shù)做限制胀瞪，可能產(chǎn)生Bean的屬性數(shù)據(jù)被篡改或者覆蓋的情況，嚴(yán)重時(shí)可更改用戶密碼等私密數(shù)據(jù)饲鄙。

同樣凄诞，用于顯示在前端的Bean屬性如果沒有做限制，那么默認(rèn)所有屬性都將返回前端忍级，暴露給用戶帆谍，間接造成敏感數(shù)據(jù)泄露。

綜上轴咱，對(duì)于實(shí)體注入漏洞汛蝙，根據(jù)數(shù)據(jù)流方向及數(shù)據(jù)格式可做以下分類：

Bean操作：

1. 后端Bean返回前端：敏感數(shù)據(jù)泄露

2. 前端表單填充后端Bean：實(shí)體屬性值篡改/覆蓋

JSON注入：前端JSON傳入后端轉(zhuǎn)換為Bean，實(shí)體屬性值篡改/覆蓋

錯(cuò)誤代碼示例：

1. Bean操作：以User對(duì)象在各個(gè)階段的屬性情況為例朴肺，說(shuō)明漏洞產(chǎn)生情況

      [圖片上傳失敗...(image-c1a65c-1607912037170)]
   

2. JSON注入：以下代碼窖剑，JSON中的“role”屬性值將被覆蓋，新建一個(gè)角色為管理員的用戶

   [圖片上傳失敗...(image-b4e050-1607912037170)]

4.1.8.2 危害性

1. 泄露bean中的屬性

2. 新建/更改用戶權(quán)限戈稿、角色及其他重要信息

3. 根據(jù)bean的功能不同引發(fā)其他類型漏洞：sql注入西土，XSS等

4.1.8.3 開發(fā)原則

1. Bean操作：無(wú)論bean由前端填充到后端還是由后端返回前端顯示，都禁止直接操作整個(gè)bean鞍盗，而是操作我們實(shí)際需要的那幾個(gè)屬性需了。

2. 對(duì)于JSON注入，需要對(duì)傳入的JSON key值做重復(fù)性驗(yàn)證般甲。

4.1.8.4 解決方案

1. 【首選】Bean操作：

a) 后端Bean返回前端顯示

以下方案二選一：

• • • • 使用vo的方式肋乍，每次數(shù)據(jù)返回前端組合一個(gè)新的vo實(shí)體。
      • 使用@JsonView注釋可過濾返回至前端的重要屬性敷存，@JsonView注釋可以自己定義視圖規(guī)則住拭，在controller層可隨意配置。示例代碼：

實(shí)體類：

      [圖片上傳失敗...(image-706000-1607912037170)]

Controller方法：

    [圖片上傳失敗...(image-d104e6-1607912037170)]

b) 前端表單填充后端Bean：

避免使用框架自動(dòng)填充整個(gè)實(shí)體历帚，只使其填充需要的某些屬性滔岳。否則，需要禁止填充不需要的重要屬性：

• • • Spring框架使用@ModelAttribute 注釋的 Spring MVC 應(yīng)用程序中挽牢，使用@InitBinder注釋方法來(lái)配置綁定器谱煤，決定禁止綁定屬性。示例代碼：

  [圖片上傳失敗...(image-d53c0d-1607912037170)]

• • • Spring框架使用@RequestBody注釋的 Spring MVC 應(yīng)用程序中禽拔，綁定過程由 HttpMessageConverter 實(shí)例處理刘离，這些實(shí)例使用 Jackson 等庫(kù)將 HTTP 請(qǐng)求正文轉(zhuǎn)換為 Java 對(duì)象室叉，使用@JsonIgnore注釋以可阻止將某個(gè)字段綁定到請(qǐng)求。
    • Struts 僅將 HTTP 請(qǐng)求參數(shù)綁定到對(duì)應(yīng)公共 setter 訪問器的 Actions 或 ActionForms 屬性硫惕，可以將屬性的 setter 設(shè)置為私有來(lái)禁止填充茧痕。

c) 使用populate方法進(jìn)行bean操作時(shí)，理論上同樣具有被注入的風(fēng)險(xiǎn)恼除，實(shí)際開發(fā)過程中需要謹(jǐn)慎對(duì)待各參數(shù)踪旷。（示例代碼：BeanUtils.populate(user, map);）

2. 【首選】對(duì)于JSON注入，需要對(duì)傳入的JSON key值做充分驗(yàn)證豁辉。

a) 優(yōu)先選擇json-lib-2.1工具包令野，遇到JSON值覆蓋（key值重復(fù)）的情況會(huì)拋出異常，IllegalArgumentException徽级、JSONException气破，注意異常捕獲處理。

b) 特殊字符驗(yàn)證：":"餐抢、" ” "现使、","、""旷痕。

4.1.9 HTTP響應(yīng)截?cái)?/h3>

4.1.9.1 表現(xiàn)形式

與許多軟件安全漏洞一樣朴下，Header Manipulation是達(dá)到目的的手段，而不是目的本身苦蒿。

簡(jiǎn)單講殴胧，在以下情況下會(huì)出現(xiàn)HTTP頭操作漏洞：

1. 數(shù)據(jù)通過不受信任的來(lái)源進(jìn)入Web應(yīng)用程序，最常見的是HTTP請(qǐng)求佩迟。

2. 數(shù)據(jù)包含在發(fā)送給Web用戶的HTTP響應(yīng)頭中团滥，而不進(jìn)行驗(yàn)證。

最常見的HTTP頭操作漏洞是HTTP Response Splitting报强。假如應(yīng)用程序允許CR（回車符灸姊，也由％0d或\ r \ n）和LF（換行符，也由％0a或\ n）字符輸入秉溉，那么不僅使攻擊者能夠控制應(yīng)用程序打算發(fā)送的響應(yīng)的標(biāo)題和正文力惯，而且還允許它們完全在其控制下創(chuàng)建其他響應(yīng)。

例：如果攻擊者提交惡意字符串召嘶，例如“Wiley Hacker <u>\ r \ n \ n</u>HTTP / 1.1 200 OK<u> \ r \ n</u> ...”父晶，則HTTP響應(yīng)將被拆分為以下形式的兩個(gè)響應(yīng)：

     [圖片上傳失敗...(image-1d27dd-1607912037169)]

許多應(yīng)用程序服務(wù)器都會(huì)阻止將惡意字符注入HTTP響應(yīng)頭。例如Apache Tomcat弄跌，如果嘗試設(shè)置帶有禁止字符的響應(yīng)頭甲喝，tomcat會(huì)拋出IllegalArgumentException。

即使應(yīng)用程序服務(wù)器會(huì)阻止使用惡意回車/換行字符設(shè)置HTTP響應(yīng)頭铛只，我們也應(yīng)當(dāng)在可控的代碼中做相應(yīng)的處理埠胖。至少要防止正常用戶誤操作引起的業(yè)務(wù)問題糠溜，保證安全、用戶體驗(yàn)一個(gè)不能少直撤。

4.1.9.2 危害性

響應(yīng)截?cái)鄬?dǎo)致第二個(gè)響應(yīng)完全受攻擊者控制非竿，可能引發(fā)其他漏洞：XSS、頁(yè)面劫持谋竖、結(jié)合跨站請(qǐng)求偽造進(jìn)行cookie操作红柱，惡意重定向等。

4.1.9.3 開發(fā)原則

任何由用戶控制的即將加入HTTP響應(yīng)頭信息的輸入都需要經(jīng)過驗(yàn)證圈盔。

4.1.9.4 解決方案

【首選】所有請(qǐng)求都需過濾回車換行字符及其各種編碼形式。

4.1.10 日志偽造

4.1.10.1 表現(xiàn)形式

在以下情況下會(huì)發(fā)生日志偽造漏洞：

1. 數(shù)據(jù)從不受信任的來(lái)源進(jìn)入應(yīng)用程序悄雅。

2. 數(shù)據(jù)被寫入應(yīng)用程序或系統(tǒng)日志文件驱敲。

在理想的情況下，攻擊者可以通過向應(yīng)用程序提供包含特殊字符的輸入宽闲，將錯(cuò)誤信息插入日志文件中众眨，可能偽造日志信息，也可能會(huì)破壞文件格式甚至使文件無(wú)法使用容诬，損壞的日志文件可用于覆蓋攻擊者的蹤跡危害性娩梨。增加追蹤困難度。

4.1.10.2 開發(fā)原則

1. 避免將外部輸入直接記錄至日志中

2. 嚴(yán)格的輸入驗(yàn)證

4.1.10.3 解決方案

1. 【推薦】記錄至日志的信息做到開發(fā)人員完全可控

2. 【推薦】特殊字符過濾：回車換行符及其各種編碼形式览徒、"%"狈定、"="

4.1.11 其他注入

4.1.11.1 表現(xiàn)形式

根據(jù)代碼業(yè)務(wù)的不同，應(yīng)用系統(tǒng)可能還會(huì)面臨以下注入類漏洞的攻擊：

1. 命令注入：用戶輸入可能控制系統(tǒng)命令

2. 代碼注入：系統(tǒng)需要執(zhí)行一段由用戶控制的代碼习蓬，例：eval纽什、setTimOut等方法

3. 配置操縱：用戶輸入可能控制各種系統(tǒng)設(shè)置（例：各種配置文件中內(nèi)容，db躲叼、cache（Redis）芦缰、log、activeMQ等）

4. 資源注入：用戶可能控制用于訪問系統(tǒng)資源的標(biāo)識(shí)符和連接網(wǎng)絡(luò)資源的端口號(hào)枫慷。例如：根據(jù)用戶輸入的端口號(hào)建立一個(gè)socket让蕾。

5. LDAP注入：用戶輸入可能控制LDAP的語(yǔ)法、內(nèi)容或者命令或听，類似SQL注入

6. OGNL注入：存在于struts2框架探孝，struts將http的請(qǐng)求參數(shù)對(duì)應(yīng)為OGNL表達(dá)式，惡意用戶可能修改系統(tǒng)變量或執(zhí)行任意代碼等誉裆。

7. XPath注入：用戶輸入可能構(gòu)建動(dòng)態(tài)的XPath語(yǔ)法進(jìn)行惡意操作再姑，與SQL注入類似，只不過XPath注入的目標(biāo)是XML數(shù)據(jù)庫(kù)找御，語(yǔ)言是XPath元镀。

以上類型的注入漏洞不多見绍填，只是因?yàn)橐陨项愋偷拈_發(fā)不常用到，而不是不易被攻擊栖疑，所以只要應(yīng)用系統(tǒng)中包含了以上類型的代碼開發(fā)讨永，就可能產(chǎn)生對(duì)應(yīng)風(fēng)險(xiǎn)。

4.1.11.2 解決方案

1. 【推薦】禁止由用戶輸入來(lái)動(dòng)態(tài)構(gòu)成系統(tǒng)命令遇革、各種script執(zhí)行代碼卿闹、系統(tǒng)配置桑逝、資源鏈接等昆禽。

2. 【首選】針對(duì)以上注入類型，例如命令注入事富、代碼注入揪漩、配置操縱這種類型可以通過設(shè)置白名單的方式旋恼，或者通過代碼與標(biāo)識(shí)映射關(guān)系提供給用戶選擇；不能夠設(shè)置白名單的奄容，需要進(jìn)行相應(yīng)的冰更、嚴(yán)格的輸入驗(yàn)證。以下說(shuō)明：

a) 命令注入：";"昂勒、"&"蜀细、" " "、" ' "戈盈、"\xOA"奠衔、"\xFF"、"|"

b) 代碼注入：根據(jù)語(yǔ)言不同塘娶，確定需要驗(yàn)證的特殊字符涣觉，例：javaScript、php

c) 配置操縱血柳、資源注入：設(shè)立用戶可操作白名單官册。（強(qiáng)制）

d) LDAP注入：用戶輸入可能控制LDAP的語(yǔ)法、內(nèi)容或者命令难捌，類似SQL注入

e) OGNL注入：升級(jí)框架版本膝宁，最低：OGNL3.0.21、Struts2.3.35根吁，或驗(yàn)證特殊字符："#"员淫、"\u0023"、" " "击敌、" ' "介返、"%"、"="、"["圣蝎、"]"

f) XPath注入："/"刃宵、"@"、" " "徘公、" ' "牲证、"%"、"="关面、"["坦袍、"]"、"："等太、"http://"捂齐、" "("、" ')"缩抡、","

4.2 安全特性

4.2.1 失效的身份認(rèn)證和會(huì)話管理

4.2.1.1 表現(xiàn)形式

1. 失效的身份認(rèn)證：

• • 使用容易猜測(cè)的用戶名奠宜、用戶名對(duì)大小寫不敏感、用Email做用戶名時(shí)缝其，未驗(yàn)證注冊(cè)Email的有效性

  • 只使用密碼做認(rèn)證挎塌、不安全的認(rèn)證錯(cuò)誤提示信息徘六、實(shí)現(xiàn)不當(dāng)?shù)尿?yàn)證碼機(jī)制

  • 使用過于簡(jiǎn)單的密碼内边、實(shí)現(xiàn)不當(dāng)?shù)拿艽a恢復(fù)機(jī)制、密碼安全存儲(chǔ)(不安全客戶端存儲(chǔ)等)待锈，弱密碼破解時(shí)間參考：

      [圖片上傳失敗...(image-1d559b-1607912037169)]
    

• • 脆弱Token的實(shí)現(xiàn)機(jī)制漠其，如使用易被破解的信息生成SessionID
  • 配置不當(dāng)?shù)膯吸c(diǎn)登錄系統(tǒng)SSO

2. 失效的會(huì)話管理：

• • 會(huì)話超時(shí)利用：

    沒有會(huì)話超時(shí)機(jī)制、公共計(jì)算機(jī)中的瀏覽器存儲(chǔ)了用戶憑證

• • 脆弱的/可預(yù)測(cè)的會(huì)話ID

    使用帶有邏輯性竿音，易被猜測(cè)的ID和屎、使用脆弱的加密

• • 會(huì)話固定攻擊(Session Fixation)

    攻擊者把已知的SessionID誘使受害者去使用，使之成為有效的會(huì)話ID

• • 會(huì)話劫持

    如SessionID沒有添加HTTPOnly標(biāo)簽春瞬，導(dǎo)致XSS劫持會(huì)話

4.2.1.2 危害性

攻擊者可以利用認(rèn)證或會(huì)話管理功能中的泄露或漏洞（比如暴露的賬戶柴信、密碼、或會(huì)話ID）來(lái)假冒用戶, 這些漏洞可能會(huì)導(dǎo)致部分或全部賬戶遭受攻擊宽气。一旦成功随常，攻擊者能執(zhí)行受害用戶的任何操作。

4.2.1.3 開發(fā)原則

1. 失效的身份認(rèn)證

a) 強(qiáng)制性的強(qiáng)密碼策略認(rèn)證

• • • 密碼長(zhǎng)度：不小于8位長(zhǎng)度

    • 密碼復(fù)雜性：

      [圖片上傳失敗...(image-c49af4-1607912037169)]
      

b) 防止短期內(nèi)密碼重用萄涯，比如新密碼和老密碼一樣

c) 密碼有效期绪氛，比如設(shè)置3個(gè)月更換一次密碼

d) 當(dāng)?shù)卿浭〈螖?shù)超過限定值時(shí)，需賬戶鎖定涝影，如自動(dòng)鎖定30分鐘或人工申請(qǐng)解鎖

e) 不要使用與個(gè)人隱私相關(guān)的數(shù)據(jù)枣察，如生日，妻子生日，姓名縮寫序目，英文名臂痕，手機(jī)號(hào)碼QQ號(hào)碼等

f) 重要應(yīng)用要求強(qiáng)密碼策略，并考慮雙因素認(rèn)證

g) 密碼必須以不可逆的加密算法宛琅，如Hash算法等刻蟹，加密之后存儲(chǔ)在數(shù)據(jù)庫(kù)，使用高級(jí)的密碼哈希算法嘿辟，如Bcrypt

2. 失效的會(huì)話管理

a) 使用應(yīng)用容器提供的標(biāo)準(zhǔn)的SessionID機(jī)制

b) 使用推薦使用的加密機(jī)制舆瘪，比如SHA1 SHA2等

c) 確保用戶憑證和SessionID在使用過程中，都處于SSL/TLS的保護(hù)下

d) 會(huì)話Cookie在瀏覽器端 的安全配置红伦，如HTTPOnly英古、Secure、限定域和作用范圍昙读、最大存活時(shí)間

e) 針對(duì)敏感操作召调，需要使用二次認(rèn)證的機(jī)制來(lái)確保安全

f) 在任何權(quán)限變更之后，需重置新的會(huì)話蛮浑，如多用戶登錄或賬戶切換

g) 設(shè)置登出功能唠叛，并在登出操作之后，確保該用戶Session被銷毀

h) 自動(dòng)會(huì)話過期機(jī)制

i) 空閑超時(shí)沮稚，比如30分鐘未使用艺沼，進(jìn)行過期操作

4.2.1.4 解決方案

1. 失效的身份認(rèn)證：

a) 【推薦】驗(yàn)證密碼強(qiáng)度，可使用ESAPI Authenticator去驗(yàn)證密碼的強(qiáng)度

• • • 檢查新密碼不會(huì)中出現(xiàn)一個(gè)子字符串包包含3個(gè)字符與舊密碼中相同
    • 檢查密碼中是否包含以下字符：CHAR_LOWERS, CHAR_UPPERS, CHAR_DIGITS, CHAR_SPECIALS
    • 計(jì)算密碼強(qiáng)度：新密碼的復(fù)雜度和長(zhǎng)度

    [圖片上傳失敗...(image-1e6522-1607912037169)]

b) 【強(qiáng)制】生成強(qiáng)壯的初始密碼：可使用ESAPI Authenticator

• • • 隨機(jī)生成器生成的密碼蕴掏，包含大寫字符障般，小寫字符，數(shù)字盛杰，特殊字符

    [圖片上傳失敗...(image-d5b0e2-1607912037169)]

2. 失效的會(huì)話管理：

a) 【強(qiáng)制】確保會(huì)話超時(shí)機(jī)制得以實(shí)現(xiàn)或正確配置

     [圖片上傳失敗...(image-d46cf4-1607912037169)]

b) 【強(qiáng)制】在完成認(rèn)證之后挽荡，改變SessionID。

c) 【強(qiáng)制】在以下情況下即供，確保會(huì)話失效：

• • • 用戶登出
    • 會(huì)話超時(shí)

d) 【強(qiáng)制】嚴(yán)格對(duì)待Session可信邊界：存入seesion的數(shù)據(jù)一定是可信的定拟，而不是直接從用戶處獲取的。例：可根據(jù)用戶傳入的數(shù)據(jù)逗嫡，去數(shù)據(jù)庫(kù)查找與之對(duì)應(yīng)的數(shù)據(jù)青自，再存入session，無(wú)論是對(duì)象還是簡(jiǎn)單的標(biāo)識(shí)串祸穷。

4.2.2 敏感信息泄露

4.2.2.1 表現(xiàn)形式

敏感信息：

• • 客戶個(gè)人信息：姓名性穿、身份證號(hào)碼、聯(lián)系方式雷滚、住址需曾、財(cái)務(wù)賬號(hào)等
  • 商業(yè)秘密：經(jīng)營(yíng)策略或戰(zhàn)略、經(jīng)營(yíng)渠道、經(jīng)營(yíng)數(shù)據(jù)呆万、業(yè)務(wù)規(guī)劃與計(jì)劃
  • 知識(shí)成果：自有研發(fā)的業(yè)務(wù)知識(shí)成果商源、包括教材、課件等
  • 薪資信息：?jiǎn)T工薪資谋减、職級(jí)等相關(guān)信息
  • 合同信息：涉及合同相關(guān)的信息數(shù)據(jù)
  • 業(yè)績(jī)數(shù)據(jù)：涉及業(yè)務(wù)牡彻、業(yè)績(jī)相關(guān)的報(bào)表及信息數(shù)據(jù)
  • 財(cái)務(wù)數(shù)據(jù)：涉及業(yè)務(wù)收入、支出出爹、預(yù)算等相關(guān)的財(cái)務(wù)數(shù)據(jù)
  • 系統(tǒng)配置：信息系統(tǒng)運(yùn)營(yíng)和維護(hù)相關(guān)的配置數(shù)據(jù)庄吼，包括系統(tǒng)架構(gòu)圖、配置文件严就、密碼密鑰等
  • 程序源代碼：具有自主產(chǎn)權(quán)的程序源代碼

表現(xiàn)形式舉例:

1. 應(yīng)用程序可能沒有對(duì)敏感數(shù)據(jù)進(jìn)行安全加密

2. http表單使用get方式提交

3. http表單中涉及私密信息的輸入框未設(shè)置禁止緩存功能总寻、對(duì)重要表單進(jìn)行默認(rèn)填充

4. 任何可能輸出用戶敏感信息以及應(yīng)用系統(tǒng)信息的日志代碼、debug代碼梢为、測(cè)試代碼渐行、未妥善處理的異常，同樣包括各種直接顯示給用戶的中間件及版本信息的不安全設(shè)置等

5. 密碼字段使用不可清除的String對(duì)象存儲(chǔ)

4.2.2.2 危害性

攻擊者通常不直接攻擊加密系統(tǒng)铸董。被正確加密的數(shù)據(jù)是難以破解的祟印。任何被忽略的記錄代碼及不安全代碼的都可能會(huì)將用戶及系統(tǒng)信息泄露給用戶，作為惡意用戶攻擊應(yīng)用系統(tǒng)的重要依據(jù)粟害。

4.2.2.3 解決方案

1. 【強(qiáng)制】重要數(shù)據(jù)使用強(qiáng)加密算法加密蕴忆，傳輸使用https（SSL）

2. 【強(qiáng)制】http表單提交選擇POST方式，servlet處理請(qǐng)求使用doPost()方法我磁；重要數(shù)據(jù)輸入框禁止填充孽文、禁止緩存：autocomplete="off"

3. 【強(qiáng)制】日志系統(tǒng)禁止記錄用戶信息驻襟，有關(guān)用戶信息的debug夺艰、測(cè)試代碼禁止遺留

4. 【強(qiáng)制】配置出現(xiàn)異常的統(tǒng)一訪問頁(yè)面，禁止系統(tǒng)異常信息流出

5. 【強(qiáng)制】登陸等認(rèn)證功能失敗后沉衣，要提供一般性提示信息郁副，禁止提供明確錯(cuò)誤信息，防止攻擊者“對(duì)癥下藥”豌习，例：登陸認(rèn)證失敗存谎，提示“用戶名密碼錯(cuò)誤”，而不是“用戶名不存在”肥隆。

6. 【推薦】密碼字段優(yōu)先選擇StringBuffer既荚、數(shù)組存儲(chǔ)，使用后清除

7. 【強(qiáng)制】永遠(yuǎn)不要相信隱藏域栋艳，禁止將敏感信息毫無(wú)保留的明文放于隱藏域

8. 【強(qiáng)制】涉及敏感信息的頁(yè)面都需要禁止頁(yè)面緩存恰聘。

4.2.3 訪問控制（數(shù)據(jù)越權(quán)訪問）

4.2.3.1 表現(xiàn)形式

場(chǎng)景：界面上有個(gè)連接，點(diǎn)擊該連接指向張三的詳細(xì)信息，url中有張三的id為參數(shù)晴叨，在地址欄中將張三的id修改為李四的id就看到了李四的數(shù)據(jù)凿宾。嚴(yán)重的情況會(huì)導(dǎo)致看到隱私的數(shù)據(jù)。

前提：id可預(yù)測(cè)性較高兼蕊，例：純數(shù)字

http://www.xxxxx.com?isCompleted=1&activityID=4208&careId=1

http://www.xxxxxxx.com/Recruiting/ApplicantManage/InitFilter?JobId=19500&PhaseId=1&IdType=1&formjob=true

4.2.3.2 危害性

只要是通訊中明文的東西初厚，就一定會(huì)被惡意地修改。即使你僅僅是傳遞一個(gè)123456（客戶端根本不知道什么意思）孙技，也可以被改成abcdefg（胡亂修改）而成為邏輯炸彈产禾，同時(shí)會(huì)成為水平權(quán)限攻擊的方便條件。

4.2.3.3 開發(fā)原則

1. 禁止出現(xiàn)以下的數(shù)據(jù)處理形式：僅僅通過一個(gè)容易預(yù)測(cè)的字段便能決定數(shù)據(jù)處理的集合（id牵啦、is_admin等狀態(tài)下愈、字典字段）

2. url參數(shù)必須要通過urlDecode和urlEncode處理或者加密處理

3. 增加url參數(shù)的不可預(yù)測(cè)性或者每個(gè)url 進(jìn)行驗(yàn)權(quán)

4. 如果可能設(shè)計(jì)url參數(shù)防篡改策略

4.2.3.4 解決方案

1. 【首選】服務(wù)端應(yīng)獲取當(dāng)前用戶輸入的id而非當(dāng)前登錄用戶id去驗(yàn)證數(shù)據(jù)處理權(quán)限。

2. 【次選】設(shè)計(jì)URL參數(shù)防篡改策略

目標(biāo)：防止篡改參數(shù)蕾久。若發(fā)現(xiàn)參數(shù)已通過客戶端驗(yàn)證势似，但在提交服務(wù)端請(qǐng)求過程中被篡改，那么服務(wù)端中止任何響應(yīng)僧著。此策略不僅可以預(yù)防此漏洞履因，還可預(yù)防其他只能靠篡改參數(shù)攻擊的漏洞。

防參數(shù)篡改的基本策略：所有參數(shù)及值加密盹愚，并且秘鑰栅迄、加密方式在服務(wù)端。

3. 【輔助】降低URL參數(shù)的可預(yù)測(cè)性

• • 針對(duì)重要標(biāo)識(shí)皆怕，先加密然后存儲(chǔ)到客戶端標(biāo)識(shí)中（cookie或自定義標(biāo)識(shí)）毅舆，數(shù)據(jù)處理時(shí)獲取此加密標(biāo)識(shí)。
  • 數(shù)據(jù)庫(kù)表id和一般業(yè)務(wù)的標(biāo)識(shí)位或數(shù)據(jù)字典code愈腾，加密或者使用32位uuid憋活。

4.2.4 不安全的加密存儲(chǔ)

4.2.4.1 表現(xiàn)形式

1. 密碼、秘鑰硬編碼

2. 使用不安全的密鑰生成或存儲(chǔ)方式

3. 使用弱加密算法虱黄，如使用弱的哈希算法來(lái)保護(hù)密碼

4. 使用加密算法中的不安全填充模式或工作模式

4.2.4.2 危害性

攻擊者通常不直接攻擊加密系統(tǒng)悦即，被正確加密的數(shù)據(jù)是難以破解的。

不安全的加密算法或方式更容易被預(yù)測(cè)或破解從而被攻擊者獲取重要數(shù)據(jù)橱乱。

4.2.4.3 解決方案

1. 【強(qiáng)制】用于加密或者數(shù)據(jù)模糊化的隨機(jī)數(shù)生成器要選擇SecuRandom

2. 【強(qiáng)制】所有密碼禁止在代碼中硬編碼辜梳，在代碼或配置文件中明文存儲(chǔ)

3. 【參考】各種加密表現(xiàn)形式及安全度

• • 最基本加密：對(duì)密碼做hash+salt處理，確保salt安全存儲(chǔ)以及做完善的訪問控制泳叠，選擇SHA2哈希算法系列作瞄。

  • 高級(jí)加密：hash算法有一定的安全性，但不能代替加密算法危纫。對(duì)密碼應(yīng)該使用更高級(jí)的加密算法宗挥。

              [圖片上傳失敗...(image-70fb09-1607912037169)]
    
              [圖片上傳失敗...(image-e3febc-1607912037169)]
    

4. 【強(qiáng)制】選擇使用高安全性加密算法的組件节预，并且密鑰存儲(chǔ)于數(shù)據(jù)庫(kù)進(jìn)行隔離，若在配置文件中存儲(chǔ)密鑰需加密或混淆保存属韧，秘鑰長(zhǎng)度也要滿足需求安拟。其中AES秘鑰最低128位，RSA最低2048位宵喂。

推薦的算法和秘鑰長(zhǎng)度： AES(256) ****糠赦、RSA(2048)****、SHA-2

參考：各種加密組件信息如下：

              [圖片上傳失敗...(image-640eaa-1607912037169)]

5. 【推薦】使用高安全度的工作方式或填充模式：

使用CBC工作模式而非默認(rèn)或ECB模式锅棕，最直觀區(qū)別：ECB模式下拙泽，同樣的明文將生成一樣的密文，而CBC模式每次密文都不同裸燎。

對(duì)于RSA算法顾瞻，要顯示指定QAEP填充模式，可防止一些針對(duì) RSA 的攻擊德绿。

4.3 時(shí)間和狀態(tài)

4.3.1 競(jìng)爭(zhēng)條件

4.3.1.1 表現(xiàn)形式

常用框架spring mvc中的servlet默認(rèn)為單例模式荷荤，在多線程的訪問模式下，全局變量的訪問會(huì)產(chǎn)生競(jìng)爭(zhēng)關(guān)系（struts2中servlet默認(rèn)為多例模式）移稳。

4.3.1.2 危害性

全局變量的競(jìng)爭(zhēng)會(huì)導(dǎo)致一個(gè)用戶會(huì)看到其他用戶的數(shù)據(jù)蕴纳，包括訂單、合同等私密信息个粱，只要是單例servlet中的全局變量古毛，都會(huì)產(chǎn)生此漏洞。

4.3.1.3 解決方案

1. 【強(qiáng)制】顯示配置servlet為多例模式

為controller添加@Scope("prototype")注釋都许，將默認(rèn)的單例模式改為多例稻薇，使用xml定義bean的情況，同樣顯示配置scope屬性為prototype胶征。

2. 【備選】單例servlet中不要設(shè)置全局變量塞椎，使用局部變量或者將變量封裝。

4.4 API不恰當(dāng)使用

4.4.1 開發(fā)框架與組件黑名單

4.4.1.1 表現(xiàn)形式

應(yīng)用中使用的一些組件弧烤，比如：庫(kù)文件忱屑、框架和其他軟件模塊等蹬敲，如果這些組件有漏洞暇昂，且以最高權(quán)限運(yùn)行，可以造成嚴(yán)重的數(shù)據(jù)泄露或完全控制服務(wù)器伴嗡。

4.4.1.2 危害性

服務(wù)器組件里的后門急波，遠(yuǎn)程執(zhí)行漏洞，反序列化漏洞等等瘪校。

4.4.1.3 開發(fā)原則

【強(qiáng)制】開發(fā)框架及組件不能采用存在漏洞的組件：

黑名單類/vulhub.org

1) ****原生反序列化澄暮，即ObjectInputStream.readObject ****會(huì)觸發(fā)的漏洞名段，需要黑名單的類：

  [圖片上傳失敗...(image-93cc0e-1607912037169)]

2) **** xml****解析器對(duì)象重組，如xstream****漏洞泣懊，需要黑名單的類：

 [圖片上傳失敗...(image-e86c44-1607912037169)]

 [圖片上傳失敗...(image-70fad9-1607912037169)]

3) **** json****解析器對(duì)象重組伸辟，如fastjson****、jackson****馍刮，需要黑名單的類：

[圖片上傳失敗...(image-aa8b12-1607912037169)]

[圖片上傳失敗...(image-688183-1607912037169)]

4) **** hessian****黑名單類：

[圖片上傳失敗...(image-96ae84-1607912037169)]

4.4.1.4 解決方案

1. 【建議】移除不使用的依賴信夫，不需要的功能、組件和文檔卡啰；

2. 【建議】利用工具如 versions静稻、DependencyCheck、retire.js

3. 【建議】等來(lái)持續(xù)的記錄客戶端和服務(wù)器以及它們的依賴庫(kù)的版本信息匈辱；

4. 【建議】對(duì)使用的組件持續(xù)監(jiān)控如CVE和NVD等漏洞中心振湾，可以使用自動(dòng)化工具來(lái)完成此功能；

5. 【建議】?jī)H從官網(wǎng)渠道獲取組件并且在有條件的情況下盡可能采用單一包來(lái)避免被惡意篡改的風(fēng)險(xiǎn)亡脸；

6. 【建議】很多老的不再支持的庫(kù)和組件并沒有安全升級(jí)押搪，這種情況下，可以考慮使用虛擬補(bǔ)丁技術(shù)去檢查

6 支持性文件

• 《應(yīng)用安全管理規(guī)定》
• 《WEB開發(fā)安全基線》
• 《WEB應(yīng)用安全架構(gòu)威脅建那衬耄》

7 有效期限

本管理文件有效期自發(fā)布之日起至下一版文件發(fā)布時(shí)止嵌言。

8 附件1：

• ? ESAPI提供全面安全防護(hù)函數(shù)。

已有項(xiàng)目中使用的某些應(yīng)用程序或框架可能已經(jīng)具有類似的功能及穗，因此摧茴，可以只使用所需的，以彌補(bǔ)現(xiàn)有安全的不足埂陆。

調(diào)用實(shí)例： 

    [圖片上傳失敗...(image-29e3b3-1607912037169)]

• ? 驗(yàn)證系統(tǒng)安全漏洞苛白，以上線前安全評(píng)估為準(zhǔn)

ESAPI下載地址:

.Net：https://code.google.com/archive/p/owasp-esapi-dotnet/downloads

PHP：https://github.com/OWASP/PHP-ESAPI

JAVA：https://github.com/ESAPI/esapi-java