等保2.0數據輸入有效性檢驗測評研究

林川

（海南正邦信息科技有限公司，海南?？?，570100）

0 引言

近年來，利用網絡安全漏洞實施攻擊的安全事件頻發，給網絡空間安全帶來了不可逆的危害。而漏洞產生的很大一個原因是程序員在軟件編碼時，未考慮對用戶提交的數據進行有效性校驗，應用系統程序直接使用用戶提交上來的數據[1]。導致攻擊者可通過瀏覽器或攻擊工具，在URL或其他輸入區域（如表單等），向服務器發送特殊請求，從中發現應用系統程序存在的漏洞，進而操縱和控制應用系統程序，竊取或修改用戶數據，甚至獲取服務器管理權限。因此，加強對數據輸入有效性校驗成為保障應用系統程序安全性的一個重要手段。但事實上，很多程序員缺乏安全編程知識和經驗，他們所理解的數據輸入有效性檢驗，更多的是基于軟件容錯的數據格式或邊界值的校驗，卻忽略了更為重要的惡意代碼檢驗[2]。本文作者曾長期從事軟件編碼工作，當前又主要從事等級測評工作。本文將結合軟件編碼和等級測評工作實踐，嘗試為測評人員提供一些數據輸入有效性檢驗辦法。

網絡安全行業對數據輸入有效性校驗內涵的理解變化，從等保1.0到等保2.0相關標準要求項內容的演變也可見一斑：

通過表1可以看出，等保1.0對數據有效性檢驗的要求主要是從傳統的應用軟件容錯角度出發，要求對輸入的數據格式或長度進行校驗。而等保2.0在等保1.0的基礎上提出了更高更合理的要求，從安全性的角度出發，要求對輸入的內容進行校驗，不再僅限于數據格式和長度，從而擴大了校驗范圍。同時把該要求項歸類到入侵防范控制點，更能體現數據輸入有效性檢驗對等保對象安全性的重要影響。

表1 等保1.0和等保2.0對數據有效性檢驗要求項比較

《GB/T 28448—2019信息安全技術 網絡安全等級保護測評要求》中針對第三級等級保護對象“應提供數據有效性檢驗功能，保證通過人機接口輸入或通過通信接口輸入的內容符合系統設定要求”要求項提出的測評實施要求包括以下兩項：（1）應核查系統設計文檔的內容是否包括數據有效性檢驗功能的內容或模塊；（2）應測試驗證是否對人機接口或通信接口輸入的內容進行有效性檢驗。

本文將圍繞第二項測評實施要求，從技術實施的角度，介紹常見的因為缺少數據輸入有效性校驗而導致的安全性漏洞及其測試驗證方法，并給出該要求項的單項測評方法及風險判定方法。

1 常見數據輸入類別

常見的數據輸入類別主要包括以下兩種類別：

（1）人機接口輸入：泛指通過人機交互界面輸入的數據，包含桌面應用、Web應用、手機APP應用等人機交互界面數據輸入；（2）通信接口輸入：泛指通過API（Application Programming Interface）接口向后臺服務器發送數據的數據輸入，包含中間件調用、公共類/函數調用、Web Service服務調用等。

2 常見漏洞分析及測試驗證方法

2.1 弱口令漏洞

2.1.1 漏洞分析

弱口令漏洞，就是應用系統程序存在容易被別人猜測到或被破解工具破解的口令。弱口令漏洞的產生通常是應用系統程序在用戶注冊時，沒有對用戶輸入的口令進行長度、復雜度等校驗，導致用戶可以設置弱口令[3]。該漏洞可能導致攻擊者利用互聯網公開的常見弱口令嘗試登錄管理后臺，進而利用后臺管理功能竊取或修改數據，甚至可能通過對后臺進行漏洞挖掘及利用，最終獲取服務器權限。

弱口令漏洞無論是人機接口輸入，還是通信接口輸入，都普遍存在。

2.1.2 測試驗證方法

（1）在用戶注冊頁面，嘗試使用弱口令注冊一個測試用戶?？词欠窨梢宰猿晒Α?/p>

（2）在用戶登錄頁面，嘗試使用已存在的用戶登錄，輸入常見弱口令。看是否可以登錄成功。

（3）使用暴力破解工具（如Burpsuite）抓取用戶登錄請求，通過加載弱口令字典進行暴力破解?？词欠窨梢云平獬晒Α?/p>

2.2 SQL注入漏洞

2.2.1 漏洞分析

SQL注入漏洞，就是惡意攻擊者通過將SQL命令插入到Web表單提交、輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意SQL命令。具體來說，它是利用應用系統程序對惡意SQL語句缺乏檢驗的缺陷，將惡意SQL命令注入到后臺數據庫引擎執行，達到竊取、更改、刪除數據的目的。甚至進一步對服務器植入后門程序，獲取服務器權限。

通常情況下，容易注入SQL的位置包括：（1）URL參數提交，主要為GET請求參數；（2）表單提交，主要是POST請求，也包括GET請求；（3）Cookie參數提交；（4）HTTP請求頭部的一些可修改的值，比如Referer、User_Agent等。

2.2.2 測試驗證方法

傳入SQL語句可控參數分為以下三類：

（1）數字型：參數不用被引號括起來，如http://host/test.php?id=1

（2）字符型：參數要被引號括起來,如http://host/test.php?name=’張三’

（3）搜索型：搜索輸入框的參數

對于數字型可控參數，可以在參數后面添加and 1=1和and 1=2兩個字符串判斷是否存在注入點。如果http://host/test.php?id=1and1=1返回正常內容，而http://host/test.php?id=1 and 1=2返回空內容，則可以判定該點存在SQL注入漏洞。

對于字符型可控參數，可以在參數后面添加‘and‘1’=’1和‘and‘1’=’2兩個字符串判斷是否存在注入點。如果http://host/test.php?name=’張三’and‘1’=’1返回正常內容，而http://host/test.php?name=’張三’and‘1’=’2返回空內容，則可以判定該點存在SQL注入漏洞。

對于搜索型的可控參數，可以在搜索輸入框輸入’和%字符判斷是否存在注入點。如果輸入’返回錯誤，輸入%字符正常返回，則可以判定該點存在SQL注入漏洞。

2.3 XSS跨站腳本攻擊漏洞

2.3.1 漏洞分析

XSS跨站腳本攻擊漏洞，就是惡意攻擊者利用Web應用程序對惡意腳本語句缺乏檢驗的缺陷，往Web頁面里插入惡意Js代碼，當用戶打開有惡意代碼的鏈接或頁面時，惡意代碼通過瀏覽器自動執行，從而達到進行竊取隱私、釣魚欺騙、竊取密碼、傳播惡意代碼等目的。

XSS跨站腳本攻擊漏洞包括以下兩種類型：

（1）反射型跨站腳本攻擊：這是目前最普遍的跨站類型。跨站代碼一般存在于鏈接中，請求這樣的鏈接時，跨站代碼經過服務端反射回來，這類跨站的代碼不存儲到服務端（比如數據庫中）；

（2）存儲型跨站腳本攻擊：這是危害最直接的跨站類型，跨站代碼存儲于服務端（比如數據庫中）。常見情況是某用戶在論壇發貼，如果論壇沒有過濾用戶輸入的Javascript代碼數據，就會導致其他瀏覽此貼的用戶的瀏覽器會執行發貼人所嵌入的Javascript代碼。

2.3.2 測試驗證方法

（1）反射型跨站腳本攻擊驗證

容易出現反射型跨站腳本攻擊漏洞的功能點一般是URL參數需要在頁面顯示的功能點，例如站內搜索、查詢功能點。

測試時可以在輸入的參數后添加＜script＞alert（Test XSS）＜/script＞語句，比如http://host/test.php?name=＜script＞alert（TestXSS）＜/script＞。如果頁面彈出顯示TestXSS的告警框，則可以判定該點存在反射型跨站腳本攻擊漏洞。如果沒有彈出顯示TestXSS的告警框，則在返回的頁面上單擊鼠標右鍵，選擇“查看源文件”，查找網頁源文件中是否包含完整的字符串＜script＞alert（TestXSS）＜/script＞，如果有也可以判定該點存在反射型跨站腳本攻擊漏洞。

（2）存儲型跨站腳本攻擊驗證

容易出現存儲型跨站腳本攻擊漏洞的功能點一般是用戶輸入的文本信息保存到數據庫中，并能夠在頁面展示的功能點，例如用戶留言、發送站內消息、個人信息修改等功能點。

測試時可以在表單輸入框里輸入＜script＞alert（Test XSS）＜/script＞再保存表單。然后訪問該信息的展示頁面，如果頁面彈出顯示TestXSS的告警框，則可以判定該點存在存儲型跨站腳本攻擊漏洞。如果沒有彈出顯示TestXSS的告警框，則在頁面上單擊鼠標右鍵，選擇“查看源文件”，查找網頁源文件中是否包含完整的字符串＜script＞alert（Test XSS）＜/script＞，如果有也可以判定該點存在存儲型跨站腳本攻擊漏洞。

2.4 越權漏洞

2.4.1 漏洞分析

越權漏洞，就是應用系統程序在檢查授權（Authorization）時存在紕漏，使得惡意攻擊者在獲得低權限用戶帳號權限后，可以利用一些方式繞過權限檢查，訪問或者操作到原本無權訪問的權限功能。

越權漏洞包括以下兩種類型：

（1）水平越權：攻擊者嘗試訪問與他擁有相同權限的用戶的資源。比如某系統中有個人資料這個功能，A賬號和B賬號都可以訪問這個功能，但是A賬號的個人信息和B賬號的個人信息不同，可以理解為A賬號和B賬號個人資料這個功能上具備水平權限的劃分。此時，A賬號通過攻擊手段訪問了B賬號的個人資料，就是水平越權漏洞。

（2）垂直越權：一個低權限用戶嘗試高權限用戶的資源。比如說某個系統分為普通用戶和管理員，管理員有系統管理功能，而普通用戶沒有，那我們就可以理解管理功能具備垂直權限劃分。如果普通用戶能利用某種攻擊手段訪問到管理功能，就是垂直越權漏洞。

2.4.2 測試驗證方法

越權漏洞包括以下兩種類型：

（1）水平越權驗證

常見的水平越權高發功能點有：根據訂單號查訂單、根據用戶ID查看帳戶信息、修改/找回密碼等。

測試時以普通用戶A身份登錄系統，找到一條只有A用戶可以查看的數據鏈接，比如："http://host/orderDetail.php?id=46"，復制此鏈接。再以另一具有相同權限的普通用戶B登錄系統,在地址欄輸入:"http://host/orderDetail.php?id=46"，如果可以查看到該條數據，則可以判定該點存在水平越權漏洞。

（2）垂直越權驗證

常見的垂直越權高發功能點為只有高權限用戶有權限可以操作的頁面。

測試時以超級管理員admin（高權限用戶）身份登錄系統，找到一個只有超級管理員（高權限）才有的功能的鏈接，比如:"http://host/userManage/userList.php",顯示出所有的用戶，并復制此鏈接。再以普通用戶登錄系統,在地址欄輸入:"http://host/userManage/userList.php"，如果可以查看到其所有的user，則可以判定該點存在垂直越權漏洞。

2.5 任意文件上傳漏洞

2.5.1 漏洞分析

任意文件上傳漏洞，就是惡意攻擊者利用Web應用的文件上傳功能上傳任意文件，包括網站后門文件（webshell），進而獲取服務器權限。其本質是應用系統程序代碼沒有嚴格限制和校驗用戶上傳的文件后綴以及文件類型，導致被攻擊者利用。

文件上傳是web中最為常見的一種功能需求，關鍵是文件上傳之后服務器端的處理、解釋文件的過程是否安全。一般的情況有：

（1）上傳文件WEB腳本語言，服務器的WEB容器解釋并執行了用戶上傳的腳本，導致代碼執行；

（2）上傳文件FLASH策略文件crossdomain.xml，以此來控制Flash在該域下的行為；

（3）上傳文件是病毒、木馬文件，攻擊者用以誘騙用戶或管理員下載執行；

（4）上傳文件是釣魚圖片或包含了腳本的圖片，某些瀏覽器會作為腳本執行，可用于實施釣魚或欺詐；

2.5.2 測試驗證方法

找到Web應用中可以上傳圖片、文件的功能點，嘗試上傳跟該Web應用開發語言對應的后綴名文件（例如該Web應用是用PHP語言開發的，則可以上傳一個test.php文件）。如果可以上傳成功，則可以判定該點存在任意文件上傳漏洞。要注意的是有一些Web應用可能會對上傳的文件做校驗，但是校驗方法不夠嚴謹，此時可以采取一些繞過方法來規避這些校驗。

2.6 任意文件下載漏洞

2.6.1 漏洞分析

任意文件下載漏洞，就是對用戶輸入的文件名稱的安全性驗證不足而導致的一種安全漏洞。漏洞使得惡意攻擊者通過輸入一些特殊字符，可以繞過服務器的安全限制，獲取服務器的配置文件及系統文件（web根目錄以外的文件），甚至執行系統命令。其本質是應用系統程序在代碼實現上沒有充分過濾用戶輸入的../之類的目錄跳轉符，導致攻擊者可以通過提交目錄跳轉來遍歷服務器上的任意文件。

2.6.2 測試驗證方法

通過判斷的網站編程語言，并根據其url中部分提供的參數，構造相關的路徑信息。例如，收集到網站中間件版本為apache，則想辦法構造../../../WEB-INF/web.xml等，然后查看其是否可被下載下來。如果可以下載，則可以判定該點存在任意下載文件漏洞。注意應用系統程序代碼可能已經對下載文件的后綴做了限制，即已經在代碼固定了可以下載的文件后綴名，這時可以嘗試使用截斷符號%00對后綴名限制進行繞過，看是否還能下載任意文件。

2.7 文件包含漏洞

2.7.1 漏洞分析

文件包含漏洞，就是程序員出于靈活性考慮，使用文件包含函數包含公共代碼文件，同時將被包含的文件設置為可控參數，用來進行動態調用。由于加載的可控參數沒有經過檢驗或者嚴格定義，惡意攻擊者可以修改可控參數，來實現調用惡意代碼文件，從而獲取服務器管理權限。其大多出現在PHP代碼中，PHP中文件包含的函數包括：include（）、include_once（）、require（）、require_once（）。如果傳入這些函數的參數可控則可能引發文件包含漏洞。

文件包含漏洞包含以下兩種類型：（1）本地文件包含：只能包含當前服務器上的文件；（2）遠程文件包含：可以包含本地和遠程服務器上的文件，是否為遠程文件包含取決于php.ini配置里的allow_url_fopen是否開啟。

2.7.2 測試驗證方法

通過觀察參數特征猜測是否使用文件包含，看文件包含參數后面為具體文件名（如：http://host/test.php?filename=include.php）。再通過../目錄跳轉符嘗試讀取系統文件、服務器日志文件或者配置文件。如讀取Linux的/etc/passwd文件:http://host/test.php?filename=../../../../etc/passwd。如果可以讀取到文件內容，則可以判定該點存在文件包含漏洞。

3 單項測評與風險判定

3.1 單項測評

《測評要求》中針對第三級等級保護對象“應提供數據有效性檢驗功能，保證通過人機接口輸入或通過通信接口輸入的內容符合系統設定要求”要求項提出的測評實施要求包括以下兩項：（1）應核查系統設計文檔的內容是否包括數據有效性檢驗功能的內容或模塊；（2）應測試驗證是否對人機接口或通信接口輸入的內容進行有效性檢驗。

單元判定為：如果1）-2）均為肯定，則符合本測評單元指標要求，否則不符合或部分符合本測評單元指標要求。

3.1.1“測評實施要求2）”實施分析

如果測試驗證發現系統存在前面第三節所列出的常見安全漏洞或者其它可能導致系統被入侵的漏洞，則可以判定“測評實施要求2）”不符合要求。否則判定“測評實施要求2）”符合要求。

3.1.2 單項測評結論

“測評實施要求1）”測評方法比較簡單，只需核查系統設計文檔是否包括數據有效性檢驗功能的內容或模塊，有則判定“測評實施要求1）”符合要求，無則判定不符合要求。再結合“測評實施要求2）”的符合性結論，可以得出以下四種可能的單項測評結論：

表2 單項測評結論判定

3.2 風險判定

要求項“應提供數據有效性檢驗功能，保證通過人機接口輸入或通過通信接口輸入的內容符合系統設定要求”的風險判定，主要通過測試驗證，依據所發現的漏洞引發的后果嚴重程度來進行。

如果應用系統程序存在SQL注入、跨站腳本攻擊、任意文件上傳等可能導致敏感數據泄露、網頁篡改、服務器被入侵等嚴重后果的漏洞，且未采取其他技術手段對漏洞進行防范的，可判定為高風險。存在后果不嚴重的漏洞或者系統設計文檔的內容未包括數據有效性檢驗功能的內容或模塊的可酌情判定為中低風險。

在進行整體測評時，如果發現存在以下兩種補償措施，可酌情降低風險等級：

（1）應用系統程序存在SQL注入、跨站腳本等高危漏洞，但系統部署了WAF、云盾等應用防護產品，在防護體系下無法成功利用，可酌情降低風險等級；

（2）不與互聯網交互的內網系統，可根據系統重要程度、漏洞危害情況、內部網絡的防護措施等情況，酌情判斷風險等級。

4 結束語

本文僅介紹常見的因為缺少數據輸入有效性校驗而引申的安全性漏洞及其測試驗證方法。在現場測評時，除了測試驗證這些常見的漏洞以外，其它有可能被攻擊者利用的漏洞也應一并測試驗證。測試驗證方法也不必完全拘泥于上述測試驗證方法，可以配合漏洞掃描工具，結合漏洞特點進行深入挖掘，以便全面發現應用系統程序的安全問題。