應(yīng)用安全開發(fā)規(guī)范(JAVA安全編碼指南)

1 目的

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

3 名詞解釋

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

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

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

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

2) SQL injection，SQL注入攻擊

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

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

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

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

4) 任意文件下載

當(dāng)用戶通過web 下載文件時，所下載文件及路徑為變量形式傳給程序，程序未對下載文件及路徑做檢測，導(dǎo)致用戶可隨意輸入下載地址，造成任意文件下載漏洞的出現(xiàn)。

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

4.1 輸入驗證

4.1.1 SQL注入

4.1.1.1 表現(xiàn)形式

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

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

4.1.1.2 危險性

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

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

  3. 可以修改任意文件

  4. 可以安裝木馬后門

4.1.1.3 開發(fā)原則

  1. 前端頁面部分

a) 最小輸入原則

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

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

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

4.1.1.4 解決方案

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

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

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

  1. 【首選】使用參數(shù)化方式創(chuàng)建SQL語句進(jìn)行數(shù)據(jù)處理
  1. 【推薦】使用第三方安全框架ESAPI處理參數(shù)

JAVA支持良好，代碼示例：

4.1.2 跨站腳本攻擊

4.1.2.1 表現(xiàn)形式

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

  1. 存儲型XSS / 持久型

  2. 反射型XSS / 非持久型

  3. DOM based XSS

4.1.2.2 危害性

  1. 盜取用戶cookie，偽造用戶身份登錄。

  2. 控制用戶瀏覽器。

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

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

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

  6. 蠕蟲攻擊

  7. 盜取客戶端鍵盤記錄

4.1.2.3 開發(fā)原則

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

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

  1. 驗證所有的headers, cookies, query strings, form fields, hidden fields。

  2. 對即將輸出到前端的用戶可控數(shù)據(jù)進(jìn)行編碼轉(zhuǎn)義。

  3. 不要在JS文件中編寫重要代碼。

  4. 在測試階段, 進(jìn)行必要的安全測試和檢驗。

4.1.2.4 解決方案

  1. 【輔助】輸入驗證：

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

  1. 【強(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中對數(shù)據(jù)部分做HTML轉(zhuǎn)義。示例代碼：

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


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

在Http響應(yīng)中，使用Set-Cookie時，添加額外的標(biāo)簽，該標(biāo)簽會保護(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屬性


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

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

以下舉例框架中常用的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)]
  1. 【強(qiáng)制】禁止引用第三方腳本，禁止iframe引用第三方頁面。

4.1.3 任意文件上傳

4.1.3.1 表現(xiàn)形式

Web應(yīng)用程序在處理用戶上傳的文件操作時，如果用戶上傳文件的路徑、文件名、擴(kuò)展名成為用戶可控數(shù)據(jù)，就會導(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ò)展名來保護(hù)系統(tǒng)。利用這個漏洞，攻擊者可以繞過保護(hù)把危險的可執(zhí)行文件上傳到服務(wù)器上。

上傳a.asp;.jpg,****服務(wù)器發(fā)現(xiàn)后綴為jpg****，允許上傳，但通過web****訪問時由;****自動截斷，執(zhí)行a.asp****木馬程序(iis6.0****解析漏洞)

b) 00截斷上傳漏洞

上傳文件名為x.php%00.jpg 時，php 驗證程序后綴名為JPG 允許上傳，當(dāng)php取文件名時，讀取到%00 會認(rèn)為是截斷符號，以x.php 進(jìn)行存儲，最終導(dǎo)致php 文件上傳。

4.1.3.2 危害性

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

4.1.3.3 開發(fā)原則

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

  2. 只接受指定類型的文件（如zip、圖片等），并驗證上傳文件類型。

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

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

  5. 所有涉及路徑的操作驗證路徑安全性。

4.1.3.4 解決方案

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

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

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

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

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

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

4.1.4 任意文件下載

4.1.4.1 表現(xiàn)形式

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

代碼實例JAVA：

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

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

4.1.4.2 危害性

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

4.1.4.3 開發(fā)原則

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

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

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

  4. 記錄文件下載日志。

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

4.1.4.4 解決方案

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

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

    • 驗證外部輸入的文件下載地址（文件名），驗證合法性，可借鑒操作系統(tǒng)對文件名稱的要求：不能包含下列字符：""、"/"、":"、"*"、"?"、" " "、"<"、">"、"|"。

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

      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ù)器端請求偽造(SSRF)

4.1.5.1 表現(xiàn)形式

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

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

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

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

4.1.5.2 危害性

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

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

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

  4. 攻擊內(nèi)外網(wǎng)的web應(yīng)用，主要是使用get參數(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. 請求URL

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

4.1.5.4 解決方案

  1. 內(nèi)網(wǎng)請求：
    • 【首選】設(shè)置內(nèi)網(wǎng)可請求地址白名單，并將地址存于數(shù)據(jù)庫，設(shè)置映射關(guān)系標(biāo)識，前端用戶必須通過標(biāo)識來選擇要請求的地址?；蛘咴O(shè)置黑名單內(nèi)網(wǎng) IP，判斷請求地址，限制在黑名單之外。以上方案原則上可二選一，實際應(yīng)用推薦白名單
    • 【強(qiáng)制輔助】統(tǒng)一錯誤信息，避免用戶根據(jù)錯誤信息來判斷遠(yuǎn)程服務(wù)器端口狀態(tài)。
    • 【推薦輔助】限制請求的端口為 HTTP 常用端口，比如 80、443、8080、8090。
    • 【強(qiáng)制輔助】禁用不需要的協(xié)議。僅僅允許 HTTP 和 HTTPS 請求?？梢苑乐诡愃朴趂ile://、gopher://和ftp://等引起的問題。
  1. 外網(wǎng)請求：以下驗證至少存在一種，并且首選白名單
    • 【首選】根據(jù)需求設(shè)置外網(wǎng)請求地址白名單并驗證。
    • 【次選】無法設(shè)置白名單的情況，更需謹(jǐn)慎對待當(dāng)前頁面，對XSS、cookie安全此類的安全策略應(yīng)更嚴(yán)格。可在需要考慮SSRF攻擊但又無法設(shè)置白名單的位置添加url防篡改機(jī)制。如果有數(shù)據(jù)返回，需過濾或驗證返回數(shù)據(jù)?？筛鶕?jù)業(yè)務(wù)需求判斷返回包是否包含預(yù)期以外的風(fēng)險數(shù)據(jù)。
  1. 【推薦輔助】禁止302跳轉(zhuǎn)。

4.1.6 跨站請求偽造(CSRF)

4.1.6.1 表現(xiàn)形式

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

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

4.1.6.2 危害性

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

4.1.6.3 解決方案

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

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

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

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

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

用戶交互時，設(shè)置一個具有超時機(jī)制的隨機(jī)token，種植在用戶的cookie 中。當(dāng)用戶提交表單時，生成隱藏域，值為cookie中隨機(jī)token，用戶提交表單后匹配兩處token值，來判斷是否為用戶提交。

    • 使用ESAPI框架生成token

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

  1. 【錯誤示例】不要靠驗證referer的方式預(yù)防CSRF

驗證用戶提交數(shù)據(jù)的referer 信息，當(dāng)為提交頁時，說明為用戶提交，當(dāng)為其他頁面時，說明為csrf 攻擊。但是，****referer****是很容易被篡改的。所以，不要靠驗證referer****的方式預(yù)防CSRF****。

  1. 【參考】二次驗證、token驗證、referer驗證，三種驗證的安全度：二次驗證>token驗證>referer驗證，正常請求使用token驗證，重要請求使用二次驗證。

4.1.7 XML外部實體攻擊(XXE)

4.1.7.1 表現(xiàn)形式

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

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

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

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

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

    • 引用外部實體

      [圖片上傳失敗...(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ā)語言提供的禁用外部實體的方法

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

4.1.7.4 解決方案

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

    • Php：

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

    • JAVA：

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

    • Python：

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

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

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

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

4.1.8 實體（Bean、JSON）注入

4.1.8.1 表現(xiàn)形式

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

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

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

Bean操作：

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

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

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

錯誤代碼示例：

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

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

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

    [圖片上傳失敗...(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操作：無論bean由前端填充到后端還是由后端返回前端顯示，都禁止直接操作整個bean，而是操作我們實際需要的那幾個屬性。

  2. 對于JSON注入，需要對傳入的JSON key值做重復(fù)性驗證。

4.1.8.4 解決方案

  1. 【首選】Bean操作：

a) 后端Bean返回前端顯示

以下方案二選一：

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

實體類：

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

Controller方法：

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

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

避免使用框架自動填充整個實體，只使其填充需要的某些屬性。否則，需要禁止填充不需要的重要屬性：

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

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

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

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

  1. 【首選】對于JSON注入，需要對傳入的JSON key值做充分驗證。

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

b) 特殊字符驗證：":"、" ” "、","、""。

4.1.9 HTTP響應(yīng)截斷

4.1.9.1 表現(xiàn)形式

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

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

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

  2. 數(shù)據(jù)包含在發(fā)送給Web用戶的HTTP響應(yīng)頭中，而不進(jì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)將被拆分為以下形式的兩個響應(yīng)：

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

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

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

4.1.9.2 危害性

響應(yīng)截斷導(dǎo)致第二個響應(yīng)完全受攻擊者控制，可能引發(fā)其他漏洞：XSS、頁面劫持、結(jié)合跨站請求偽造進(jìn)行cookie操作，惡意重定向等。

4.1.9.3 開發(fā)原則

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

4.1.9.4 解決方案

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

4.1.10 日志偽造

4.1.10.1 表現(xiàn)形式

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

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

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

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

4.1.10.2 開發(fā)原則

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

  2. 嚴(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)可能還會面臨以下注入類漏洞的攻擊：

  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)識符和連接網(wǎng)絡(luò)資源的端口號。例如：根據(jù)用戶輸入的端口號建立一個socket。

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

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

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

以上類型的注入漏洞不多見，只是因為以上類型的開發(fā)不常用到，而不是不易被攻擊，所以只要應(yīng)用系統(tǒng)中包含了以上類型的代碼開發(fā)，就可能產(chǎn)生對應(yīng)風(fēng)險。

4.1.11.2 解決方案

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

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

a) 命令注入：";"、"&"、" " "、" ' "、"\xOA"、"\xFF"、"|"

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

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

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

e) OGNL注入：升級框架版本，最低：OGNL3.0.21、Struts2.3.35，或驗證特殊字符："#"、"\u0023"、" " "、" ' "、"%"、"="、"["、"]"

f) XPath注入："/"、"@"、" " "、" ' "、"%"、"="、"["、"]"、"："、"http://"、" "("、" ')"、","

4.2 安全特性

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

4.2.1.1 表現(xiàn)形式

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

    • 使用容易猜測的用戶名、用戶名對大小寫不敏感、用Email做用戶名時，未驗證注冊Email的有效性

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

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

        [圖片上傳失敗...(image-1d559b-1607912037169)]
    • 脆弱Token的實現(xiàn)機(jī)制，如使用易被破解的信息生成SessionID
    • 配置不當(dāng)?shù)膯吸c登錄系統(tǒng)SSO
  1. 失效的會話管理：

    • 會話超時利用：

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

    • 脆弱的/可預(yù)測的會話ID

      使用帶有邏輯性，易被猜測的ID、使用脆弱的加密

    • 會話固定攻擊(Session Fixation)

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

    • 會話劫持

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

4.2.1.2 危害性

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

4.2.1.3 開發(fā)原則

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

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

      • 密碼長度：不小于8位長度

      • 密碼復(fù)雜性：

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

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

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

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

e) 不要使用與個人隱私相關(guān)的數(shù)據(jù)，如生日，妻子生日，姓名縮寫，英文名，手機(jī)號碼QQ號碼等

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

g) 密碼必須以不可逆的加密算法，如Hash算法等，加密之后存儲在數(shù)據(jù)庫，使用高級的密碼哈希算法，如Bcrypt

  1. 失效的會話管理

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

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

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

d) 會話Cookie在瀏覽器端 的安全配置，如HTTPOnly、Secure、限定域和作用范圍、最大存活時間

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

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

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

h) 自動會話過期機(jī)制

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

4.2.1.4 解決方案

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

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

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

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

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

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

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

  1. 失效的會話管理：

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

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

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

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

      • 用戶登出
      • 會話超時

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

4.2.2 敏感信息泄露

4.2.2.1 表現(xiàn)形式

敏感信息：

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

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

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

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

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

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

  5. 密碼字段使用不可清除的String對象存儲

4.2.2.2 危害性

攻擊者通常不直接攻擊加密系統(tǒng)。被正確加密的數(shù)據(jù)是難以破解的。任何被忽略的記錄代碼及不安全代碼的都可能會將用戶及系統(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處理請求使用doPost()方法；重要數(shù)據(jù)輸入框禁止填充、禁止緩存：autocomplete="off"

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

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

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

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

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

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

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

4.2.3.1 表現(xiàn)形式

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

前提：id可預(yù)測性較高，例：純數(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 危害性

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

4.2.3.3 開發(fā)原則

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

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

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

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

4.2.3.4 解決方案

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

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

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

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

  1. 【輔助】降低URL參數(shù)的可預(yù)測性
    • 針對重要標(biāo)識，先加密然后存儲到客戶端標(biāo)識中（cookie或自定義標(biāo)識），數(shù)據(jù)處理時獲取此加密標(biāo)識。
    • 數(shù)據(jù)庫表id和一般業(yè)務(wù)的標(biāo)識位或數(shù)據(jù)字典code，加密或者使用32位uuid。

4.2.4 不安全的加密存儲

4.2.4.1 表現(xiàn)形式

  1. 密碼、秘鑰硬編碼

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

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

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

4.2.4.2 危害性

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

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

4.2.4.3 解決方案

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

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

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

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

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

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

          [圖片上傳失敗...(image-e3febc-1607912037169)]
  1. 【強(qiáng)制】選擇使用高安全性加密算法的組件，并且密鑰存儲于數(shù)據(jù)庫進(jìn)行隔離，若在配置文件中存儲密鑰需加密或混淆保存，秘鑰長度也要滿足需求。其中AES秘鑰最低128位，RSA最低2048位。

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

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

              [圖片上傳失敗...(image-640eaa-1607912037169)]
  1. 【推薦】使用高安全度的工作方式或填充模式：

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

對于RSA算法，要顯示指定QAEP填充模式，可防止一些針對 RSA 的攻擊。

4.3 時間和狀態(tài)

4.3.1 競爭條件

4.3.1.1 表現(xiàn)形式

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

4.3.1.2 危害性

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

4.3.1.3 解決方案

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

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

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

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

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

4.4.1.1 表現(xiàn)形式

應(yīng)用中使用的一些組件，比如：庫文件、框架和其他軟件模塊等，如果這些組件有漏洞，且以最高權(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 ****會觸發(fā)的漏洞，需要黑名單的類：

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

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

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

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

3) **** json****解析器對象重組，如fastjson****、jackson****，需要黑名單的類：

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

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

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

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

4.4.1.4 解決方案

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

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

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

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

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

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

6 支持性文件

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

7 有效期限

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

8 附件1：

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

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

調(diào)用實例： 

    [圖片上傳失敗...(image-29e3b3-1607912037169)]
  • ? 驗證系統(tǒ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

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容