Web安全常見漏洞修複建議

大家好，我是老李。最近工作有點忙，沒有怎麼更新内容了，趁今天周末休息，正好和大家聊聊常見的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。

業務邏輯漏洞

應用系統必須確定所有輸入和傳遞的時候必須經過有效驗證，不僅僅是在剛進入應用系統的時候進行資料驗證。應用程式應該有檢查功能，避免攻擊者可以通過預測、操作參數或者利用隐藏的功能（例如調試）來阻礙操作或者改變業務邏輯工作流程。

應用需要對輸入進行檢查，不允許使用者直接送出未經過驗證的資料到伺服器，因為這些資料來不可編輯的控件，或者使用者沒有前端送出的權限，任何可編輯控件必須有阻止惡意的寫入或修改的功能。開發應用的時候需要注意時間處理問題。攻擊者可以簡單地通過了解不同的處理時間、結果來擷取一些參數，是以雖然他們送出的結果也在相同的時間，符合規則，但卻添加了其他步驟或者處理。

應用程式需要有阻止攻擊者通過延長允許的交易時間的功能，這種情況可以在操作超過規定的時間後通過取消或者重置交易。應用程式需要能夠過濾檢測的業務邏輯：當一個功能或者操作隻允許被執行有限的幾次 或者使用者不再能夠執行這個功能的時候，應用需要能夠檢測出來。為了阻止使用者過多次的執行某個功能， 應用程式可以通過類似緩存這種機制來控制，或者使用不允許使用者過多次執行功能的機制。

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

轉載自https://www.secquan.org/Share/1071270

看見最新的漏洞建議是18年的，是以自己也發一個最新的，整理不易。#

目錄

• SQL注入
• OS指令注入
• XPath注入
• LDAP注入
• JSON注入
• XSS
• CSRF
• 會話攻擊
• 身份認證
• 直接對象引用
• Tomcat安全配置
• Apache安全配置
• 資料庫通用配置
• 繞過認證
• 越權通路
• 檔案上傳
• 檔案目錄周遊下載下傳
• 網站重定向或轉發
• 業務邏輯漏洞
• 轉載自https://www.secquan.org/Share/1071270

問題歸納#

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\n)進而對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.的通路權限：

<FilesMatch ".(php.|php3.|php4.|php5.)">

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屬性。

轉載位址：https://security.pingan.com/blog/17.html