Web安全常見漏洞修復建議

SQL注入

在服務器端要對所有的輸入數據驗證有效性。

在處理輸入之前，驗證所有客戶端提供的數據，包括所有的參數、URL和HTTP頭的內容。

驗證輸入數據的類型、長度和合法的取值范圍。

使用白名單驗證允許的輸入字符而不是黑名單。

在危險字符輸入后進行轉義或編碼。

明確所有輸入正確的字符集。

不使用動態拼接的SQL語句，如果使用對特殊字符進行轉義。

設置最小權限運行程序

OS命令注入

不僅要在客戶端過濾，也要在服務器端過濾。

要用最小權限去運行程序，不要給予程序多余的權限，最好只允許在特定的路徑下運行，可以通過使用明確運行命令。

在程序執行出錯時，不要顯示與內部實現相關的細節。

如果只允許運行有限的命令、使用白名單方式過濾。

對于需要運行命令的請求，盡可能減小需要從外部輸入的數據。比如：傳參數的地方不要傳命令行。

有下載文件，給文件分配一個ID號來訪問文件，拒絕文件名訪問。如果需要用文件名，嚴格檢測文件的合法性。

XPath注入

在服務器端開始處理用戶提交的請求數據之前，對輸入的數據進行驗證，驗證每一個參數的類型、長度和格式。

對于系統出現的錯誤信息，以IE錯誤編碼信息替換，屏蔽系統本書的出錯信息，這樣可以向攻擊者提供更少的信息進行下一步注入攻擊。

檢查是否有特殊字符，如果有特殊字符 ，就轉義特殊字符或者替換。例：單引號、雙音哈都轉義或者替換。

XPath查詢參數化，編譯構建XPath表達式，將數據輸入以 變量形式 傳遞。

敏感信息如密碼之類，使用哈希值較長的算法處理。

LDAP注入

使用轉義特殊字符和白名單來驗證輸入。

JSON注入

在特殊字符前加反斜杠()進行轉義

使用Javascript編碼

使用HTML編碼

XSS

在輸入過濾，在顯示的地方做輸出編碼。

使用一個統一的規則做輸出編碼

富文本框，使用白名單控制輸入。

使用HTTPOnly標志

CSRF

重要功能增加確認操作或重新認證，例如支付交易、修改手機號碼等

加驗證碼

每個會話中使用強隨機令牌（token）來保護。

檢驗HTTP Referer

會話攻擊

采用強算法生成會話ID，會話ID必須具有隨機性和不可預測性，長度至少為128位。

設定會話過期時間，如：在一定時間內沒有與應用交互，設定在登錄一定時間內要重新輸入驗證用戶名密碼，如一天等。

設置好Cookie的兩個屬性：secure和HttpOnly來防御嗅探和阻止JS操作。

身份認證

在用戶注冊時強制用戶輸入較高強度密碼、

登錄認證錯誤信息顯示登錄失敗，用戶名或 密碼錯誤。

防止撞庫等攻擊，應該登錄三次失敗后下一次登錄以5秒倍數，4次登錄失敗，讓用戶輸入驗證碼。

如果每分鐘進行幾十次嘗試登錄，應該被阻止一段時間（如20分鐘），給出清楚明白的信息，說明為什么會阻止登錄一段時間。

使用HTTPS請求傳輸身份驗證和密碼、身份證、手機號碼，郵箱等數據。

當密碼重置時，以短信方式通知用戶

用戶賬號上次使用信息在下一次成功登陸時向用戶報告。

在執行關鍵操作（如：修改登錄密碼、支付密碼、郵箱、手機號碼等）使用多因子身份驗證。

直接對象引用

使用的唯一標識可以通過隨機數生成以難以猜測。

在進行頁面顯示或做處理之前對用戶權限進行檢查。

權限信息保存在session中。

Tomcat安全配置

Tomcat以沒有特權的用戶賬戶和組運行，沒有執行交互shell命令權限。

Tomcat運行的版本必須打了所有安全補丁的版本。

Tomcat默認的例子相關路徑和文件必須刪除。

Tomcat管理員默認密碼必須被修改成復雜密碼。

頁面出現信息不能顯示Tomcat的版本信息和系統信息。

Tomcat配置文件執啟用安全的http方法，如：GET POST。

應用程序和管理程序使用不同的端口。

部署前刪除測試代碼文件。

刪除無用的文件如：備份文件、臨時文件等。

配置文件中沒有默認用戶和密碼。

不要在robot.txt中泄露目錄結構。

Apache安全配置

選擇漏洞較少的apache版本。

隱藏Apache版本號。

刪除Apache歡迎頁面。

配置只允許訪問Apache的Web目錄

應用程序和管理程序使用不同的端口。

管理額控制臺必須使用SSL協議。

部署前刪除測試代碼文件。

刪除無用的文件如：備份文件、臨時文件等。

配置文件中沒有默認用戶和密碼。

不要在robot.txt中泄露目錄結構。

數據庫通用配置

修改數據庫默認用戶名和密碼。

數據庫用戶的密碼要符合一定的復雜度。

訪問數據庫的用戶要賦予所需要的最小權限。

啟動應用的系統用戶必須是專用的，沒有系統級別權限的用戶和組。

繞過認證

對登錄后可以訪問的URL做是否登錄檢查，如果沒有登錄將跳轉到登錄頁面。

對于敏感信息的請求如登錄時、修改密碼等請求一定要用HTTPS協議。

越權訪問

驗證一切來自客戶端的參數，重點是和權限相關的參數，比如用戶ID或者角色權限ID等。

session ID 和認證的token做綁定，放在服務器的會話里，不發送給客戶端。

對于用戶登錄后涉及用戶唯一信息的請求，每次都要驗證檢查所有權，敏感信息頁面加隨機數的參數，防止瀏覽器緩存內容。

把程序分成匿名，授權和管理的區域，通過將角色和數據功能匹配。

不適用參數來區分管理員和普通用戶。

文件上傳

上傳的路徑要限制在固定路徑下。

上傳文件路徑只給只讀和寫權限，不需要執行權限。

服務端文件類型要使用白名單過濾，后臺不應有添加擴展名類型功能；通過配置文件添加文件類型。

文件上傳使用自己的命名規則重新命名上傳的文件。

文件目錄遍歷下載

使用ID替換文件夾和文件名。

網站重定向或轉發

驗證重定向的URL。

使用白名單驗證重定向目標。

網站內重定向使用相對路徑URL。

重定向或者轉發之前，要驗證用戶是否有權限訪問目標URL。

業務邏輯漏洞

應用系統必須確保所有輸入和傳遞的時候必須經過有效驗證，不僅僅是在剛進入應用系統的時候進行數據驗證。

應用程序應該有檢查功能，避免攻擊者可以通過預測、操作參數或者利用隱藏的功能（例如調試）來阻礙操作或者改變業務邏輯工作流程。

應用需要對輸入進行檢查，不允許用戶直接提交未經過驗證的數據到服務器，因為這些數據來不可編輯的控件，或者用戶沒有前端提交的權限，任何可編輯控件必須有阻止惡意的寫入或修改的功能。

開發應用的時候需要注意時間處理問題。攻擊者可以簡單地通過了解不同的處理時間、結果來獲取一些參數，所以雖然他們提交的結果也在相同的時間，符合規則，但卻添加了其他步驟或者處理。

應用程序需要有阻止攻擊者通過延長允許的交易時間的功能，這種情況可以在操作超過規定的時間后通過取消或者重置交易。

應用程序需要能夠過濾檢測的業務邏輯：當一個功能或者操作只允許被執行有限的幾次 或者用戶不再能夠執行這個功能的時候，應用需要能夠檢測出來。為了阻止用戶過多次的執行某個功能， 應用程序可以通過類似緩存這種機制來控制，或者使用不允許用戶過多次執行功能的機制。

應有用戶正確的按照業務流程來完成每一個步驟的檢測機制，這樣可以阻止黑客在業務流程中通過跳過、繞過、重復任何業務流程中的工序檢查。開發這部分業務邏輯的時候應該測試一些無用或者誤用的測試用例，當沒有按照正確的順序完成正確的步驟的時候，就不能成功完成業務流程。

問題歸納#

1.1 web安全#

1.1.1 sql注入#

1.1.1.1 漏洞描述#

SQL注入攻擊主要是由于程序員在開發過程中沒有對客戶端所傳輸到服務器端的參數進行嚴格的安全檢查，同時SQL語句的執行引用了該參數，并且SQL語句采用字符串拼接的方式執行時，攻擊者將可能在參數中插入惡意的SQL查詢語句，導致服務器執行了該惡意SQL語句。SQL注入漏洞主要影響是攻擊者可利用該漏洞竊取數據庫中的任意內容，在某些場景下，攻擊者將有可能獲得數據庫服務器的完全控制權限。

1.1.1.2 修復建議#

修改Web應用服務的軟件部分，增加對客戶端提交數據的合法性驗證，至少嚴格過濾SQL語句中的關鍵字，并且所有驗證都應該在服務器端實現，以防客戶端（IE頁面代碼部分）控制被繞過。

驗證GET、POST、COOKIE等方法中URL后面跟的參數，需過濾的關鍵字為：

[1] ' 單引號

[2] " 雙引號

[3] ' 反斜杠單引號

[4] " 反斜杠雙引號

[5] ) 括號

[6] ; 分號

[7] -- 雙減號

[8] + 加號

[9]SQL關鍵字，如select，delete，drop等等，注意對于關鍵字要對大小寫都識別，如:select ;SELECT;seLEcT等都應識別

建議降低Web應用訪問使用較低權限的用戶訪問數據庫。不要使用數據庫管理員等高權限的用戶訪問數據庫。

1.1.2 跨站腳本攻擊（xss）#

1.1.2.1 漏洞描述#

跨站腳本攻擊(Cross Site Scripting)，為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站腳本攻擊縮寫為XSS。惡意攻擊者往Web頁面里插入惡意Script代碼，當用戶瀏覽該頁之時，嵌入其中Web里面的Script代碼會被執行，從而達到惡意攻擊用戶的目的。在不同場景下，XSS有相應不同的表現形式，主要分為反射型、存儲型以及DOM型的跨站腳本攻擊，所造成的影響主要是竊取用戶登錄憑證（Cookies）、掛馬攻擊、頁面訪問挾持等。

1.1.2.2 修復建議#

建議過濾的關鍵字為：

[1] ' 單引號

[2] " 雙引號

[3] / 斜杠

[4] \ 反斜杠

[5] ) 括號

[6] ; 分號

[7] [ 中括號

[8] < 尖括號

[9] > 尖括號

比如把<編碼為<

在cookie中加入httponly屬性可以在一定程度上保護用戶的cookie，減少出現XSS時損失。

1.1.3 XML外部實體（XXE）注入#

1.1.3.1 漏洞概述#

XXE Injection即XML External Entity Injection,也就是XML外部實體注入攻擊。漏洞是在對非安全的外部實體數據進?行處理時引發的安全問題。在XML1.0標準?里,XML文檔結構里定義了實體(entity)這個概念，實體可以通過預定義在文檔中調用,實體的標識符可訪問本地或遠程內容。如果在這個過程中引入了“污染”源,在對XML文檔處理后則可能導致信息泄漏、文件讀取、命令執行等安全問題。

1.1.3.2 修復建議#

對于PHP，常見的XML解析方法有：DOMDocument、SimpleXML、XMLReader，這三者都基于 libxml 庫解析 XML，所以均受影響，xml_parse 函數則基于 expact 解析器，默認不載入外部 DTD ，不受影響。可以在php解析xml文件之前使用libxml_disable_entity_loader(true)來禁止加載外部實體（對上述三種 XML 解析組件都有效），并使用libxml_use_internal_errors()禁止報錯；

對于Java，設置

DocumentBuilderFactory dbf =DocumentBuilderFactory.newInstance();

dbf.setExpandEntityReferences(false);

對用戶的輸入做過濾，如<、>、'、"、&等

1.1.4 跨站點偽造請求（CSRF）#

1.1.4.1 漏洞概述#

CSRF（Cross-Site Request Forgery，跨站點偽造請求）是一種網絡攻擊方式，該攻擊可以在用戶毫不知情的情況下以用戶自身的名義偽造請求發送給受攻擊站點，從而在未授權的情況下執行在權限保護之下的操作。具體來講，可以這樣理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求，對服務器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作，比如以你的名義發送郵件、發消息，盜取你的賬號，添加系統管理員，甚至于購買商品、虛擬貨幣轉賬等。

1.1.4.2 修復建議#

檢測HTTP header中的referer字段。服務器可以查看referer是否為自己的站點，如果不是，則拒絕服務。

在重要請求中的每一個URL和所有的表單中添加token

1.1.5 服務器端請求偽造（SSRF）#

1.1.5.1 漏洞概述#

SSRF(Server-Side Request Forgery:服務器端請求偽造) 是一種由攻擊者構造形成并由服務端發起請求的一個安全漏洞。一般情況下，SSRF攻擊的目標是從外網無法訪問的內部系統。（正是因為它是由服務端發起的，所以它能夠請求到與它相連而與外網隔離的內部系統）

SSRF 形成的原因大都是由于服務端提供了從其他服務器應用獲取數據的功能且沒有對目標地址做過濾與限制。比如從指定URL地址獲取網頁文本內容，加載指定地址的圖片，下載等等。最終將可能導致，攻擊者可通過外網服務器端利用該漏洞訪問內網服務器端的資源。

1.1.5.2 修復建議#

過濾返回信息，驗證遠程服務器對請求的響應是比較容易的方法。如果web應用是去獲取某一種類型的文件。那么在把返回結果展示給用戶之前先驗證返回的信息是否符合標準。

統一錯誤信息，避免用戶可以根據錯誤信息來判斷遠端服務器的端口狀態。

限制請求的端口為http常用的端口，比如80,443,8080,8090。

禁用不需要的協議。僅僅允許http和https請求。可以防止類似于file:///, gopher://,ftp://等引起的問題。

過濾內網ip，限制訪問內網

1.1.6 任意文件上傳#

1.1.6.1 漏洞概述#

任意文件上傳漏洞主要是由于程序員在開發文件上傳功能時，沒有考慮對文件格式后綴的合法性進行校驗或只考慮在應用前端（Web瀏覽器端）通過javascript進行后綴校驗，攻擊者可上傳一個包含惡意代碼的動態腳本（如jsp、asp、php、aspx文件后綴）到服務器上，攻擊者訪問該腳本時服務器將對包含惡意代碼的動態腳本解析，最終執行相應的惡意代碼。該漏洞最終將可能直接影響應用系統的服務器安全，攻擊者可通過所上傳的腳本完全控制服務器。

1.1.6.2 修復建議#

對上傳文件格式進行嚴格校驗及安全掃描，防止上傳惡意腳本文件；

設置權限限制，禁止上傳目錄的執行權限；

嚴格限制可上傳的文件類型；

嚴格限制上傳的文件路徑。

文件擴展名服務端白名單校驗。

文件內容服務端校驗。

上傳文件重命名。

隱藏上傳文件路徑。

1.1.7 任意文件下載或讀取#

1.1.7.1 漏洞概述#

任意文件下載或讀取漏洞主要是由于應用系統在提供文件下載或讀取功能時，在文件路徑參數中直接指定文件路徑的同時并沒有對文件路徑的合法性進行校驗，導致攻擊者可通過目錄跳轉(..\或../)的方式下載或讀取到原始指定路徑之外的文件。攻擊者最終可通過該漏洞下載或讀取系統上的任意文件，如數據庫文件、應用系統源代碼、密碼配置信息等重要敏感信息，造成系統的敏感信息泄露。

1.1.7.2 修復建議#

對path參數進行過濾，依次過濾“.”、“..”、“/”、“\”等字符。

或者對于下載文件的目錄做好限制，只能下載指定目錄下的文件，或者將要下載的資源文件路徑存入數據庫，附件下載時指定數據庫中的id即可，id即對應的資源。

1.1.8 任意目錄遍歷#

1.1.8.1 漏洞概述#

任意目錄遍歷主要原因是由于應用系統所提供的目錄瀏覽或文件瀏覽功能中，在處理當前路徑參數時沒有對參數進行合法性校驗，攻擊者可通過目錄跳轉的方式（../或..\）瀏覽預想之外的目錄信息。攻擊者將可能利用該漏洞訪問應用系統的任意文件目錄，導致可瀏覽敏感目錄下的文件信息，造成敏感信息泄露。

1.1.8.2 修復建議#

對參數進行過濾，依次過濾“.”、“..”、“/”、“\”等字符。

1.1.9 .svn/.git源代碼泄露#

1.1.9.1 漏洞概述#

.svn/.git源代碼泄露主要原因是由于應用系統開發人員或運維管理人員在對應用系統進行版本迭代更新時，沒有及時對代碼版本維護程序(svn或git)中所產生的代碼索引或代碼庫文件進行及時清理，攻擊者可通過讀取該代碼索引或代碼庫文件訪問并下載應用系統的源代碼信息，最終導致應用系統的源代碼信息遭到泄露，攻擊者可進一步通過源代碼審計的方式挖掘應用系統中存在的安全隱患。

1.1.9.2 修復建議#

開發人員在使用 SVN/Git 時，嚴格使用導出功能，禁止直接復制代碼部署上線。

在不影響代碼運行的情況下，刪除線上代碼中所有目錄下的 .svn/.git 目錄。

1.1.10 信息泄露#

1.1.10.1 漏洞概述#

信息泄露主要是由于開發人員或運維管理人員的疏忽所導致。如未及時刪除調試頁面、未關閉程序調試功能、未屏蔽程序錯誤信息、備份文件未刪除、數據庫備份文件未刪除、未屏蔽敏感數據信息等多個方面所導致的不同嚴重程度的信息泄露。攻擊者可通過所掌握的信息進一步分析攻擊目標，從而有效發起下一步的有效攻擊。

1.1.10.2 修復建議#

對身份驗證時傳輸的用戶名密碼等作加密處理，為了防止重放攻擊可以在驗證時加個隨機數，以保證驗證單次有效。

關閉錯誤輸出，防止調試信息泄露，或者當web應用程序出錯時，統一返回一個錯誤頁面或直接跳轉至首頁

合理設置服務器端各種文件的訪問權限

盡量避免跨域的數據傳輸，對于同域的數據傳輸使用xmlhttp的方式作為數據獲取的方式，依賴于javascript在瀏覽器域里的安全性保護數據。如果是跨域的數據傳輸，必須要對敏感的數據獲取做權限認證，例如對referer的來源做限制，加入token等

1.1.11 PHPinfo界面發現#

1.1.11.1 漏洞概述#

phpinfo泄露主要是由于開發人員或運維管理人員的疏忽所導致。如未及時刪除調試頁面、未關閉程序調試功能、未屏蔽程序錯誤信息、備份文件未刪除、數據庫備份文件未刪除、未屏蔽敏感數據信息等多個方面所導致的不同嚴重程度的信息泄露。Web站點的某些測試頁面可能會使用到PHP的phpinfo()函數，會輸出服務器的關鍵信息，從而造成信息泄露，攻擊者可通過所掌握的信息進一步分析攻擊目標，從而有效發起下一步的有效攻擊。

1.1.11.2 修復建議#

開發人員在使用phpinfo界面時，嚴格使用導出功能，禁止直接復制代碼部署上線。

在不影響代碼運行的情況下，刪除線上代碼中所有目錄下的phphinfo目錄。

1.1.12 IIS短文件名泄露#

1.1.12.1 漏洞概述#

Internet Information Services（IIS，互聯網信息服務）是由微軟公司提供的基于運行Microsoft Windows的互聯網基本服務。Microsoft IIS在實現上存在文件枚舉漏洞，攻擊者可利用此漏洞枚舉網絡服務器根目錄中的文件。危害：攻擊者可以利用“~”字符猜解或遍歷服務器中的文件名，或對IIS服務器中的.Net Framework進行拒絕服務攻擊。

黑客可通過該漏洞嘗試獲取網站服務器下存放文件的文件名，達到獲取更多信息來入侵服務器的目的。

1.1.12.2 修復建議#

修改Windows配置，關閉短文件名功能。

關閉NTFS 8.3文件格式的支持。該功能默認是開啟的，對于大多數用戶來說無需開啟。

如果是虛擬主機空間用戶,可采用以下修復方案：

1） 修改注冊列表HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation的值為1(此修改只能禁止NTFS8.3格式文件名創建,已經存在的文件的短文件名無法移除)。

2）如果你的web環境不需要asp.net的支持你可以進入Internet 信息服務(IIS)管理器 --- Web 服務擴展 - ASP.NET 選擇禁止此功能。

3）升級net framework 至4.0以上版本。

將web文件夾的內容拷貝到另一個位置，比如D:\www到D:\www.back，然后刪除原文件夾

D:\www，再重命名D:\www.back到D:\www。如果不重新復制，已經存在的短文件名則是不會消失的。

1.1.13 slow http Dos拒絕服務#

1.1.13.1 漏洞概述#

按照設計，HTTP協議要求服務器在處理之前完全接收請求。如果HTTP請求沒有完成，或者傳輸速率非常低，服務器會保持其資源忙于等待其余數據。如果服務器保持太多的資源忙，這將造成一個拒絕服務。嚴重者一臺主機即可讓web運行緩慢甚至是崩潰！

1.1.13.2 修復建議#

對于 Apache 可以做以下優化：

設置合適的 timeout 時間（Apache 已默認啟用了 reqtimeout 模塊），規定了 Header 發送的時間以及頻率和 Body 發送的時間以及頻率

增大 MaxClients(MaxRequestWorkers)：增加最大的連接數。根據官方文檔，兩個參數是一回事，版本不同，MaxRequestWorkers was called MaxClients before version 2.3.13.Theold name is still supported.

默認安裝的 Apache 存在 Slow Attack 的威脅，原因就是雖然設置的 timeoute，但是最大連接數不夠，如果攻擊的請求頻率足夠大，仍然會占滿Apache的所有連接

1.1.14 T甲骨文Javaserver faces的多個漏洞#

1.1.14.1 漏洞概述#

甲骨文的JavaServer Faces包含多個漏洞，可能允許攻擊者獲得敏感信息。亞歷克斯Kouzemtchenko和Coverity的安全研究實驗室漏洞報告的喬恩Passki指出甲骨文的JavaServer Faces包含以下漏洞：偏目錄遍歷通過資源標識符（CWE-22）：存在缺陷，其允許在應用程序內的目錄遍歷。目錄遍歷是有限的，它不能被用來從應用逃脫和訪問應用服務器上的任意文件。偏目錄遍歷通過庫名稱（CWE-22）。存在缺陷，其允許在應用程序內的目錄遍歷。目錄遍歷是有限的，它不能被用來從應用逃脫和訪問應用服務器上的任意文件。

1.1.14.2 修復建議#

建議更新版本，更新公告中列出的建議關鍵路徑的更新 - 2013年10月為CVE-2013-3827

1.1.15 CRLF注入#

1.1.15.1 漏洞概述#

CRLF注入即“HTTP響應頭拆分漏洞”，主要是由于應用系統在接收用戶瀏覽器發送的參數信息后，參數信息在HTTP響應頭中進行了輸出并未經過有效的校驗，攻擊者可提交惡意的參數信息(\r)從而對HTTP響應頭進行控制。攻擊者可通過該漏洞發起web緩存感染、用戶信息涂改、竊取敏感用戶頁面、跨站腳本漏洞等攻擊，從而造成普通用戶遭受到惡意攻擊。

1.1.15.2 修復建議#

限制用戶輸入的CR和LF，或者對CR和LF字符正確編碼后再輸出。CR、LF分別對應回車（%0d）、換行（%0a）字符。

1.1.16 命令執行注入#

1.1.16.1 漏洞概述#

命令執行注入主要是由于開發人員在處理應用系統發起操作系統命令時引用了客戶端參數，同時沒有對該參數進行合法性校驗，攻擊者可在參數中注入惡意的命令參數，致使執行命令的過程中執行了攻擊者所指定的惡意命令。通過該漏洞攻擊者可執行任意的操作系統命令，在權限配置不當的情況下可直接獲得操作系統的完全控制權限。

1.1.16.2 修復建議#

盡量避免使用exec、system、passthru、popen、shell_exec、eval、execute、assert等此類執行命令/執行代碼相關函數。

執行代碼/命令的參數，或文件名，不要使用外部獲取，禁止和用戶輸入相關，只能由開發人員定義代碼內容，用戶只能提交“1、2、3”參數，代表相應代碼，防止用戶構造。

1.1.17 URL重定向#

1.1.17.1 漏洞概述#

URL重定向主要是由于Web應用系統在處理URL重定向時沒有對接收到的URL參數進行合法性校驗，攻擊者可指定URL路徑為惡意URL或惡意域名，當用戶訪問該URL重定向頁面時將可能跳轉到攻擊者所指定的惡意頁面，從而造成用戶遭受到惡意代碼的攻擊。

1.1.17.2 修復建議#

避免使用重定向和轉發

如果使用了重定向和轉發，則不要在接受目標時涉及到用戶參數

如果無法避免使用用戶參數，則應確保其提供的值對于當前用戶是有效的，并已經授權

確定白名單及網絡邊界，限定協議以及可訪問的網絡

1.1.18 Json劫持#

1.1.18.1 漏洞概述#

Json劫持主要是由于網站頁面在響應用戶請求時采用Json數組的方式進行返回，而該頁面沒有進行相應的合法判斷，攻擊者可在惡意網站上構造訪問該頁面的URL并誘惑用戶進行點擊訪問，最終攻擊者可通過Javscript Hook的方式竊取用戶在該頁面上所返回的Json數組信息，從而造成用戶的敏感信息泄露。

1.1.18.2 修復建議#

嚴格安全的實現 CSRF 方式調用 JSON 文件：限制 Referer 、部署一次性 Token等。

嚴格按照JSON格式標準輸出 Content-Type 及編碼（ Content-Type : application/json; charset=utf-8）。

嚴格過濾 callback 函數名及 JSON 里數據的輸出。

嚴格限制對 JSONP 輸出 callback 函數名的長度。

1.1.19 第三方組件安全#

1.1.19.1 漏洞概述#

第三方組件主要包括Ewebeditor、FCKeditor、Ueditor、JQuery等常用第三方組件，開發人員在開發過程中調用第三方組件時并未考慮組件當前的安全狀況，攻擊者可通過第三方組件上的安全漏洞攻擊應用系統，從而影響應用系統自身的安全。

1.1.19.2 修復建議#

無

1.1.20 本地/遠程文件包含#

1.1.20.1 漏洞概述#

本地/遠程文件包含漏洞主要出現在采用PHP開發的應用系統中，在PHP代碼開發過程中較常采用文件包含的方式進行對代碼的引用從而提高編碼效率以及代碼擴展性，被包含的文件內容將被當作php代碼進行解析。當所需要包含的文件路徑通過客戶端瀏覽器進行提交時，攻擊者可指定文件路徑到本地或遠程的惡意代碼文件，應用系統將執行該文件中的惡意代碼，最終攻擊者可通過該方式獲取應用系統的控制權限。

1.1.20.2 修復建議#

保證參數用戶不可控/不可構造性。

使用 basename() 函數處理參數。

對所有的變量初始化。

1.1.21 任意代碼執行#

1.1.21.1 漏洞概述#

任意代碼執行主要是由于應用系統在處理動態代碼執行的過程中，部分代碼片段可由客戶端瀏覽器提交參數到服務器進行指定，從而攻擊者可通過提交惡意的代碼參數到服務器，應用系統將執行所提交的惡意代碼，最終攻擊者可通過該漏洞直接獲得應用系統的控制權限。

1.1.21.2 修復建議#

盡量避免使用exec、system、passthru、popen、shell_exec、eval、execute、assert等此類執行命令/執行代碼相關函數。

執行代碼/命令的參數，或文件名，不要使用外部獲取，禁止和用戶輸入相關，只能由開發人員定義代碼內容，用戶只能提交“1、2、3”參數，代表相應代碼，防止用戶構造。

1.1.22 Struts2遠程命令執行#

1.1.22.1 漏洞概述#

Struts2遠程命令執行主要是由于網站采用較低版本的Strut2框架，該框架低版本在處理遠程客戶端參數名、參數值、文件名參數等參數內容時沒有經過嚴格的過濾，導致可注入到OGNL表達式中，從而造成任意代碼執行漏洞。攻擊者可通過構造惡意的OGNL表達式從而實現任意命令執行，最終可通過該漏洞完全獲得網站權限甚至操作系統權限。

1.1.22.2 修復建議#

Struts2遠程命令執行漏洞涉及多個漏洞編號，如S2-005、S2-008、S2-009、S2-016、S2-020、S2-029、S2-032、S2-037、S2-045、S2-046、S2-052、S2-055等等，根據實際情況，建議升級Struts2框架至最新版本即可。如：

系統存在S2-016 Struts2遠程命令執行漏洞，建議升級升級Struts2框架至最新版本。

1.1.23 Spring遠程命令執行#

1.1.23.1 漏洞概述#

Spring遠程命令執行主要是由于網站采用較低版本的Spring框架，該框架低版本在處理Spring標簽時沒有進行合法性校驗，導致可將標簽內容信息注入到表達式中，從而造成任意代碼執行漏洞。攻擊者可通過構造惡意的標簽內容到表達式從而實現任意命令執行，最終可通過該漏洞完全獲得網站權限甚至操作系統權限。

1.1.23.2 修復建議#

該漏洞為Spring標簽EL表達式注入，CVE編號為CVE-2011-2730。

建議升級Spring至Spring3.1以后版本，或修改web.xml配置關閉對EL表達式的支持：

Spring Expression Language SupportspringJspExpressionSupportfalse

1.1.24 反序列化命令執行#

1.1.24.1 漏洞概述#

反序列化命令執行主要是由于應用系統在通過反序列的方式處理字節序列時沒有對該序列信息進行校驗，攻擊者可偽造惡意的字節序列并提交到應用系統時，應用系統將對字節序列進行反序列處理時將執行攻擊者所提交的惡意字節序列，從而導致任意代碼或命令執行，最終可完成獲得應用系統控制權限或操作系統權限。

1.1.24.2 修復建議#

無

1.2 業務邏輯安全#

1.2.1 用戶名枚舉#

1.2.1.1 漏洞概述#

在應用系統登錄過程中，當輸入錯誤的用戶名信息時，應用程序將反饋相應的諸如“用戶不存在”的錯誤提示，攻擊者可通過該提示為依據進行對用戶名的枚舉，猜解出已存在于應用系統的用戶名信息，最終攻擊者可進行一步發起對已有用戶的密碼猜解。

1.2.1.2 修復建議#

模糊登陸錯誤信息，對用戶名錯誤及密碼錯誤均提示”用戶名或密碼錯誤，請重新輸入”。

戶登錄后需要對初始口令進行修改，防止攻擊者利用初始口令進行暴力破解。

系統設置強密碼策略，建議用戶密碼采用10位以上數字加大小寫字母。

對密碼暴力猜解行為進行圖靈驗證，一旦發現用戶口令破解行為及時對賬戶進行限時封停處理。

1.2.2 用戶密碼枚舉#

1.2.2.1 漏洞概述#

在應用系統登錄過程中，由于并未限制用戶的密碼輸入錯誤次數，攻擊者可通過密碼字典不斷枚舉指定用戶的密碼信息，最終用戶密碼將可能遭受到破解，攻擊者可通過所破解的用戶密碼進入應用系統并發起進一步的攻擊。

1.2.2.2 修復建議#

模糊登陸錯誤信息，對用戶名錯誤及密碼錯誤均提示”用戶名或密碼錯誤，請重新輸入”。

用戶登錄后需要對初始口令進行修改，防止攻擊者利用初始口令進行暴力破解。

系統設置強密碼策略，建議用戶密碼采用10位以上數字加大小寫字母。

對密碼暴力猜解行為進行圖靈驗證，一旦發現用戶口令破解行為及時對賬戶進行限時封停處理。

1.2.3 用戶弱口令#

1.2.3.1 漏洞概述#

由于應用系統的相關用戶的安全意識薄弱，同時應用系統并未有效的強制性密碼策略要求，從而將可能存在弱口令用戶，攻擊者可輕易通過字典猜解的方式獲得用戶的密碼并進入應用系統發起進一步攻擊。

1.2.3.2 修復建議#

用戶登錄后需要對初始口令進行修改，防止攻擊者利用初始口令進行暴力破解。

系統設置強密碼策略，建議用戶密碼采用10位以上數字加大小寫字母。

對密碼暴力猜解行為進行圖靈驗證，一旦發現用戶口令破解行為及時對賬戶進行限時封停處理。

1.2.4 網站后臺弱口令#

1.2.4.1 漏洞概述#

由于網站后臺管理員密碼強度低，容易被攻擊者暴力破解。攻擊者可利用弱口令獲得網站管理員權限，進入網站后臺，嚴重者可導致服務器淪陷

1.2.4.2 修復建議#

用戶用戶登錄后需要對初始口令進行修改，防止攻擊者利用初始口令進行暴力破解。

系統設置強密碼策略，建議用戶密碼采用10位以上數字加大小寫字母。

對密碼暴力猜解行為進行圖靈驗證，一旦發現用戶口令破解行為及時對賬戶進行限時封停處理。

1.2.5 會話標志固定攻擊#

1.2.5.1 漏洞概述#

應用系統在用戶登錄成功或登錄失敗后并未對當前的會話標志（Session ID）進行更新，從而攻擊者可構造一個未登錄且帶有Session ID的URL并發送到用戶，用戶點擊該URL并進行登錄成功后，攻擊者可通過該Session ID冒充用戶并成功進入應用系統，從而可進一步發起對應用系統的攻擊。

1.2.5.2 修復建議#

用戶登錄成功后重新創建一個Sesssion ID，并銷毀該用戶之前登陸使用的Sesssion ID。

限制Sesssion ID的時效性，一段時間后銷毀Sesssion ID。

添加其他認證因素，如User-Agent驗證及Token校驗等。

1.2.6 平行越權訪問#

1.2.6.1 漏洞概述#

應用系統在處理同一業務功能數據時，并未對數據與當前用戶的權限進行合法性校驗，從而導致用戶可越權訪問、篡改、刪除、添加其他用戶的信息，造成越權操作。常見如：訪問任意用戶訂單、修改任意用戶密碼、刪除任意用戶信息等。

1.2.6.2 修復建議#

對于每個功能的訪問，需要明確授予特定角色的訪問權限。

如果某功能參與了工作流程，檢查并確保當前的條件是授權訪問此功能的合適狀態。

1.2.7 垂直越權訪問#

1.2.7.1 漏洞概述#

應用系統在處理各個角色業務功能時，并未對當前用戶角色與該業務功能的權限標志進行判斷，導致用戶可越權訪問非自身權限范圍內的業務功能，造成越權操作。常見如：越權添加、修改、刪除用戶以及權限、越權訪問系統管理功能等。

1.2.7.2 修復建議#

對于每個功能的訪問，需要明確授予特定角色的訪問權限。

如果某功能參與了工作流程，檢查并確保當前的條件是授權訪問此功能的合適狀態。

1.2.8 未授權訪問#

1.2.8.1 漏洞概述#

應用系統對業務功能頁面并未進行有效的身份校驗，在未登錄且獲知業務功能頁面的訪問地址前提下，可直接操作該頁面下的功能，將可能對應用系統的惡意破壞。

1.2.8.2 修復建議#

對于每個功能的訪問，需要明確授予特定角色的訪問權限。

如果某功能參與了工作流程，檢查并確保當前的條件是授權訪問此功能的合適狀態。

1.2.9 登錄繞過漏洞#

1.2.9.1 漏洞概述#

由于對登錄的賬號及口令校驗存在邏輯缺陷，或再次使用服務器端返回的相關參數作為最終登錄憑證，導致可繞過登錄限制，如服務器返回一個flag參數作為登錄是否成功的標準，但是由于代碼最后登錄是否成功是通過獲取這個flag參數來作為最終的驗證，導致攻擊者通過修改flag參數即可繞過登錄的限制！

1.2.9.2 修復建議#

修改驗證邏輯，如是否登錄成功服務器端返回一個參數，但是到此就是最終驗證，不需要再對返回的參數進行使用并作為登錄是否成功的最終判斷依據！

1.2.10 驗證碼缺陷#

1.2.10.1 漏洞概述#

常見于應用系統在登錄處理流程過程中，當用戶登錄失敗后并未對當前驗證碼進行注銷并重新刷新驗證碼，攻擊者可至始至終提交初始的驗證碼發起攻擊窮舉攻擊；同時部分應用系統驗證碼只在客戶端瀏覽器驗證，并未經過服務器遠程驗證，將可能存在繞過驗證碼缺陷，另一方面，在生成或獲取驗證碼的過程中存在缺陷，攻擊者將可能成功預測驗證碼內容或直接解析驗證碼內容，從而使驗證碼失去原有意義，最終導致一系列的窮舉或遍歷數據攻擊。

1.2.10.2 修復建議#

驗證碼使用一次后，立即銷毀該驗證碼Session，防止驗證碼被多次使用。

對驗證碼添加干擾線，對驗證碼字符隨機扭曲、粘連、翻轉等處理。

1.2.11 任意注冊他人手機號#

1.2.11.1 漏洞概述#

任意注冊他人電話號碼，先burp抓包，然后改成自己的電話號碼，就會收到本該發給別人的驗證碼，由此成功注冊他人手機號

1.2.11.2 修復建議#

無

1.2.12 短信轟炸#

1.2.12.1 漏洞概述#

由于沒有對短信或者郵件發送次數進行限制，在測試的過程中，對短信驗證碼接口進行重放，導致可無限次發送短信或郵件給用戶，造成短信轟炸，進而可能被大量用戶投訴，從而影響公司聲譽！

1.2.12.2 修復建議#

限制每個手機號的每日發送次數，超過次數則拒發送，提示超過當日次數。

每個ip限制最大限制次數。超過次數則拒發送，提示超過ip當日發送最大次數。

后臺限制每個手機號發送的時間間隔，不允許頻繁操作。

1.3 中間件安全#

1.3.1 中間件安全監測#

1.3.1.1 漏洞概述#

中間件配置缺陷主要是由于開發人員或運維人員在安裝部署中間件后，并未對默認的中間件配置進行安全加固，導致產生一系列諸如目錄遍歷、默認示例文件、錯誤信息泄露等缺陷，從而導致應用系統產生信息泄露隱患。

1.3.1.2 修復建議#

設置自定義錯誤跳轉頁，避免非200響應狀態返回默認錯誤信息

關閉調試信息、中間件版本信息等敏感信息的顯示

1.3.2 第三方插件檢測#

1.3.2.1 漏洞概述#

第三方插件主要使用在CMS網站（內容管理系統）中，由于一些插件的安裝量較大，且不需要認證或者對服務器進行操作，攻擊者可利用插件中的安全漏洞攻擊網站，例如SQL注入、文件上傳等漏洞，從而導致攻擊者可能獲得數據庫服務器的完全控制權限。

1.3.2.2 修復建議#

設置自定義及時更新插件版本

不使用非正規渠道下載的插件

1.3.3 默認配置文件檢測#

1.3.3.1 漏洞概述#

默認配置文件常見于系統或軟件安裝后默認生成的文件，由于這些文件中包含大量文件或系統的敏感信息，若被攻擊者竊取，可造成敏感信息泄露，從而導致服務器被滲透的風險。

1.3.3.2 修復建議#

設置自刪除不必要的配置文件

設置文件訪問權限

1.3.4 常見冗余文件檢測#

1.3.4.1 漏洞概述#

冗余文件常見于開發人員或管理員進行備份管理的文件，其中包含大量網站信息和數據庫信息，由于文件存在于服務器中，若被攻擊者竊取，可通過分析源碼，拿到服務器權限。

1.3.4.2 修復建議#

設置自刪除服務器中的冗余文件

設置文件訪問權限

1.3.5 系統層漏洞（CVE風險漏洞）檢測#

1.3.5.1 漏洞概述#

根據互聯網中發布的CVE漏洞報告，攻擊者可分析漏洞原理，使用腳本寫出POC進行批量攻擊。常見CVE漏洞如：遠程命令執行、反序列化等

1.3.5.2 修復建議#

設置自及時更新系統補丁

根據官網中的漏洞修復方案進行修復

1.3.6 中間件配置缺陷#

1.3.6.1 漏洞概述#

中間件配置缺陷主要是由于開發人員或運維人員在安裝部署中間件后，并未對默認的中間件配置進行安全加固，導致產生一系列諸如目錄遍歷、默認示例文件、錯誤信息泄露等缺陷，從而導致應用系統產生信息泄露隱患。

1.3.6.2 修復建議#

設置自定義錯誤跳轉頁，避免非200響應狀態返回默認錯誤信息

關閉調試信息、中間件版本信息等敏感信息的顯示

1.3.7 中間件弱口令#

1.3.7.1 漏洞概述#

中間件弱口令主要是由于開發人員或運維人員在部署中間件過程中，并未對中間件控制臺進行口令配置或修改默認口令，從而攻擊者可通過窮舉猜解的方式進行中間件控制臺，最終攻擊者可通過控制臺上傳惡意腳本并獲得應用系統權限。

1.3.7.2 修復建議#

用戶登錄后需要對初始口令進行修改，防止攻擊者利用初始口令進行暴力破解。

系統設置強密碼策略，建議用戶密碼采用10位以上數字加大小寫字母。

對密碼暴力猜解行為進行圖靈驗證，一旦發現用戶口令破解行為及時對賬戶進行限時封停處理。

1.3.8 Webloigc反序列化命令執行#

1.3.8.1 漏洞概述#

由于Weblogic版本并未進行及時更新，在低版本中的Commoncollections.jar程序包中存在反序列化命令執行漏洞，攻擊者可遠程構造惡意的字節序列發送到服務器端并執行，通過該漏洞攻擊者可直接獲得應用系統控制權限甚至操作系統權限。

1.3.8.2 修復建議#

Weblogic控制臺端口(默認TCP 7001)遷移至內網，不對互聯網開放。

Webloigc Java反序列化漏洞涉及多個CVE編號：CVE-2015-4852、CVE-2016-0638、CVE-2016-3510、CVE-2017-3248、CVE-2017-3506、CVE-2017-10352等，安裝相應補丁即可，或更新Weblogic至最新版。

1.3.9 Jboss反序列化命令執行#

1.3.9.1 漏洞概述#

由于Jboss版本并未進行及時更新，在低版本中的Commoncollections.jar程序包中存在反序列化命令執行漏洞，攻擊者可遠程構造惡意的字節序列發送到服務器端并執行，通過該漏洞攻擊者可直接獲得應用系統控制權限甚至操作系統權限。

1.3.9.2 修復建議#

JBoss控制臺端口（默認TCP 8080）遷移至內網，不對互聯網開放。

修改默認配置，關閉 EJB Invoker/JMXInvokerServlet對外開放接口。

升級JBoss至最新版。

1.3.10 Websphere反序列化命令執行#

1.3.10.1 漏洞概述#

由于Websphere版本并未進行及時更新，在低版本中的Commoncollections.jar程序包中存在反序列化命令執行漏洞，攻擊者可遠程構造惡意的字節序列發送到服務器端并執行，通過該漏洞攻擊者可直接獲得應用系統控制權限甚至操作系統權限。

1.3.10.2 修復建議#

Qwer1、該漏洞Weblogic官方已經發布補丁，建議升級Weblogic至最新版。

1.3.11 Jenkins反序列命令執行#

1.3.11.1 漏洞概述#

由于Jenkins版本并未進行及時更新，在低版本中的Commoncollections.jar程序包中存在反序列化命令執行漏洞，攻擊者可遠程構造惡意的字節序列發送到服務器端并執行，通過該漏洞攻擊者可直接獲得應用系統控制權限甚至操作系統權限。

1.3.11.2 修復建議#

Jenkins Java反序列化漏洞涉及多個CVE編號：

CVE-2015-4852

CVE-2015-8103

CVE-2016-0792

CVE-2017-1000353

CVE-2017-1000354

CVE-2017-1000355

CVE-2017-1000356等等，安裝相應補丁即可，或更新Jenkins至最新版。

1.3.12 JBoss遠程代碼執行#

1.3.12.1 漏洞概述#

由于Jboss版本未進行及時更新，在低版本中存在未授權訪問漏洞從而可直接訪問EJBInvokerServlet 或 JMXInvokerServlet功能模塊，通過該功能模塊攻擊者可遠程部署惡意的WAR應用程序包，最終攻擊者可成功部署惡意代碼到應用系統服務器上，從而獲得應用系統權限。

1.3.12.2 修復建議#

無

1.3.13 文件解析代碼執行#

1.3.13.1 漏洞概述#

由于網站所采用的中間件版本過低，不同的低版本中間件均存在文件解析執行漏洞，攻擊者可直接上傳包含惡意代碼的圖片文件或壓縮文件到網站服務器上，該圖片或壓縮文件將以動態腳本代碼的方式進行解析并執行，最終攻擊者可通過執行惡意代碼獲得網站的控制權限。

1.3.13.2 修復建議#

IIS6解析漏洞修復建議：

IIS6微軟已經不在維護，建議升級IIS至IIS8或更高版本。

IIS7.0/7.5解析漏洞修復建議：

修改php.ini中cgi.pathinfo為0，并重啟IIS。

在IIS里找到“處理程序映射”，然后對PHP這一項進行編輯，點擊“請求限制”，勾選“僅當請求映射至以下內容時才調用處理程序”。

Nginx解析漏洞修復建議：

升級Nginx版本

修改php.ini文件，將cgi.fix_pathinfo的值設置為0。完成后請重啟PHP和Nginx。

Apache解析漏洞修復建議：

在httpd.conf或httpd-vhosts.conf中加入以下語句，從而禁止文件名格式為.php.的訪問權限：

Order Deny,Allow

Deny from all

1.3.14 HTTP.sys遠程代碼執行漏洞#

1.3.14.1 漏洞描述:#

遠程代碼執行漏洞存在于 HTTP 協議堆棧 (HTTP.sys) 中，當 HTTP.sys 未正確分析經特殊設計的 HTTP 請求時會導致此漏洞。成功利用此漏洞的攻擊者可以在系統帳戶的上下文中執行任意代碼。若要利用此漏洞，攻擊者必須將經特殊設計的 HTTP 請求發送到受影響的系統。

1.3.14.2 修復建議:#

更新補丁KB3042553

1.4 服務器安全#

1.4.1 域傳送漏洞#

1.4.1.1 漏洞概述#

域傳送漏洞主要由于DNS服務器開啟了域傳送功能，同時并未采用有效的白名單機制指定域傳送的傳送范圍，導致攻擊者可遠程獲得DNS服務器上的DNS記錄，造成網站的域名以及IP地址信息的泄露。

1.4.1.2 修復建議#

DNS區域傳送（DNS zone transfer）指的是一臺備用服務器使用來自主服務器的數據刷新自己的域（zone）數據庫。這為運行中的DNS服務提供了一定的冗余度，其目的是為了防止主的域名服務器因意外故障變得不可用時影響到整個域名的解析。一般來說，DNS區域傳送操作只在網絡里真的有備用域名DNS服務器時才有必要用到，但許多DNS服務器卻被錯誤地配置成只要有client發出請求，就會向對方提供一個zone數據庫的詳細信息，所以說允許不受信任的因特網用戶執行DNS區域傳送（zone transfer）操作是后果最為嚴重的錯誤配置之一。解決域傳送問題只需allow-transfer限制可以進行同步的服務器，方式有兩種，限制IP或使用TSIG key認證：

針對于bind軟件，可以通過allowe-transfer指令來控制，

可以作為global選項或者zone選項的一個參數，我們可以使用地址列表如下：

allowe-transfer ｛192.168.1.1; 172.24.123.253;｝;

采用TSIG key來嚴格定義區域傳送的關系，如下

allowe-transfer ｛key "dns1-slave1"; key "dns1-slave2";｝;

1.4.2 Redis未授權訪問#

1.4.2.1 漏洞概述#

Redis未授權訪問主要是由于默認安裝的情況下并未對Redis配置身份校驗功能，導致攻擊者可非法訪問Redis下的數據信息，同時可進一步通過配置文件功能對服務器文件進行寫入，如寫入SSH密鑰或計劃任務，從而獲得服務器的控制權限。

1.4.2.2 修復建議#

以低權限運行Redis服務，嚴禁使用root用戶等高權限用戶運行Redis服務

為Redis添加密碼驗證

修改redis.conf，添加

requirepass mypassword

禁止外網訪問Redis

修改redis.conf，添加或修改，使得Redis服務只在當前主機可用

bind 127.0.0.1

1.4.3 Pivotal Software Redis<2.8.21/3.x/3.0.2 RCE#

1.4.3.1 漏洞概述#

遠程主機上安裝的Redis版本受遠程代碼執行漏洞的影響。攻擊者可以通過eval命令利用這個問題來執行任意Lua bytecote。

1.4.3.2 修復建議#

建議更新到Redis 2.8.21 / 3.0.2或更高版本。

1.4.4 MangoDB未授權訪問#

1.4.4.1 漏洞概述#

MangoDB未授權訪問主要是由于默認安裝的情況下并未對MangoDB配置身份校驗功能，導致攻擊者可非法訪問MangoDB下的數據信息，從而造成MangoDB中的數據庫信息泄露。

1.4.4.2 修復建議#

修改默認的 MongoDB 端口(默認為: TCP 27017)為其他端口

禁止外網訪問 MongoDB

修改 /etc/mongodb.conf，設置 bind_ip

bind_ip = 127.0.0.1

禁用 HTTP 和 REST 端口

MongoDB 自身帶有一個 HTTP 服務和并支持 REST 接口。在 2.6 以后這些接口默認是關閉的。MongoDB 默認會使用默認端口監聽 Web 服務，一般不需要通過 Web 方式進行遠程管理，建議禁用。修改配置文件或在啟動的時候選擇 –nohttpinterface 參數：nohttpinterface = false

MongoDB 授權

在 admin 數據庫中創建用戶，并設置強密碼，修改配置文件 /etc/mongodb.conf，開啟授權：

auth = true

1.4.5 操作系統弱口令#

1.4.5.1 漏洞概述#

操作系統弱口令主要由于運維管理員的安全意識薄弱，對管理員賬號設置了簡單密碼，攻擊者可通過字典窮舉的方式破解管理員密碼并完全獲得服務器控制權限。

1.4.5.2 修復建議#

用戶登錄后需要對初始口令進行修改，防止攻擊者利用初始口令進行暴力破解。

系統設置強密碼策略，建議用戶密碼采用10位以上數字加大小寫字母。

對密碼暴力猜解行為進行圖靈驗證，一旦發現用戶口令破解行為及時對賬戶進行限時封停處理。

1.4.6 數據庫弱口令#

1.4.6.1 漏洞概述#

數據庫弱口令主要由于運維管理員的安全意識薄弱，對數據庫管理員賬號設置了簡單密碼，攻擊者可通過字典窮舉的方式破解管理員密碼并完全獲得數據庫控制權限。在特定場景下，攻擊者可通過數據庫權限進行權限提升，從而進一步獲得數據庫所在服務器的控制權限。

1.4.6.1 修復建議#

用戶登錄后需要對初始口令進行修改，防止攻擊者利用初始口令進行暴力破解。

系統設置強密碼策略，建議用戶密碼采用10位以上數字加大小寫字母。

對密碼暴力猜解行為進行圖靈驗證，一旦發現用戶口令破解行為及時對賬戶進行限時封停處理。

1.4.7 數據庫結構泄露#

1.4.7.1 漏洞概述#

數據庫結構泄露主要是由于開發人員或運維管理人員的疏忽所導致。如未及時刪除調試頁面、未關閉程序調試功能、未屏蔽程序錯誤信息、備份文件未刪除、數據庫備份文件未刪除、未屏蔽敏感數據信息等多個方面所導致的不同嚴重程度的信息泄露。攻擊者可通過所掌握的信息進一步分析攻擊目標，從而有效發起下一步的有效攻擊。

1.4.7.2 修復建議#

關閉錯誤輸出，防止調試信息泄露，或者當web應用程序出錯時，統一返回一個錯誤頁面或直接跳轉至首頁

合理設置服務器端各種文件的訪問權限

1.4.8 本地權限提升#

1.4.8.1 漏洞概述#

本地權限提升漏洞主要是由于服務器沒有及時更新操作系統補丁、數據庫補丁或其他第三方應用程序補丁，導致攻擊者可利用存在的安全缺陷或配置缺陷進行普通權限到最高權限的權限提升，最終可直接獲得服務器的最高權限。

1.4.8.2 修復建議#

無

1.4.9 已存在的腳本木馬#

1.4.9.1 漏洞概述#

在滲透測試過程中發現非滲透測試人員所上傳的腳本木馬，主要是攻擊者此前對應用系統發起了攻擊并成功上傳腳本木馬并獲得了相應的權限。

1.4.9.2 修復建議#

刪除后門程序、對網站目錄進行后門查殺

查看Web日志，進行攻擊溯源

1.4.10 應用防護軟硬件缺陷#

1.4.10.1 漏洞概述#

應用防護軟硬件缺陷主要是由于第三方安全產品在安全設置或安全策略存在安全缺陷，導致攻擊者可通過特定的方式繞過該安全產品的防護策略，從而突破防護進一步發起對應用系統的攻擊。

1.4.10.2 修復建議#

無

1.4.10 Host頭攻擊#

1.4.10.1 漏洞描述#

Host首部字段是HTTP/1.1新增的，旨在告訴服務器，客戶端請求的主機名和端口號，主要用來實現虛擬主機技術。

運用虛擬主機技術，單個主機可以運行多個站點。

例如：hacker和usagidesign兩個站點都運行在同一服務器A上，不管我們請求哪個域名，最終都會被解析成服務器A的IP地址，這個時候服務器就不知道該將請求交給哪個站點處理，因此需要Host字段指定請求的主機名。

我們訪問hacker域名，經DNS解析，變成了服務器A的IP，請求傳達到服務器A，A接收到請求后，發現請求報文中的Host字段值為hacker，進而將請求交給hacker站點處理。

這個時候，問題就出現了。為了方便獲取網站域名，開發人員一般依賴于請求包中的Host首部字段。例如，在php里用_SERVER["HTTP_HOST"]，但是這個Host字段值是不可信賴的(可通過HTTP代理工具篡改)。

1.4.10.2 修復建議#

對Host字段進行檢測

Nginx，修改ngnix.conf文件，在server中指定一個server_name名單，并添加檢測。

Apache，修改httpd.conf文件，指定ServerName，并開啟UseCanonicalName選項。

Tomcat，修改server.xml文件，配置Host的name屬性。