SQL注入

在服務器端要對所有的輸入數(shù)據(jù)驗證有效性。
在處理輸入之前，驗證所有客戶端提供的數(shù)據(jù)，包括所有的參數(shù)、URL和HTTP頭的內(nèi)容。
驗證輸入數(shù)據(jù)的類型、長度和合法的取值范圍。
使用白名單驗證允許的輸入字符而不是黑名單。
在危險字符輸入后進行轉(zhuǎn)義或編碼。
明確所有輸入正確的字符集。
不使用動態(tài)拼接的SQL語句，如果使用對特殊字符進行轉(zhuǎn)義。
設置最小權限運行程序

OS命令注入

不僅要在客戶端過濾，也要在服務器端過濾。
要用最小權限去運行程序，不要給予程序多余的權限，最好只允許在特定的路徑下運行，可以通過使用明確運行命令。
在程序執(zhí)行出錯時，不要顯示與內(nèi)部實現(xiàn)相關的細節(jié)。
如果只允許運行有限的命令、使用白名單方式過濾。
對于需要運行命令的請求，盡可能減小需要從外部輸入的數(shù)據(jù)。比如：傳參數(shù)的地方不要傳命令行。
有下載文件，給文件分配一個ID號來訪問文件，拒絕文件名訪問。如果需要用文件名，嚴格檢測文件的合法性。

XPath注入

在服務器端開始處理用戶提交的請求數(shù)據(jù)之前，對輸入的數(shù)據(jù)進行驗證，驗證每一個參數(shù)的類型、長度和格式。
對于系統(tǒng)出現(xiàn)的錯誤信息，以IE錯誤編碼信息替換，屏蔽系統(tǒng)本書的出錯信息，這樣可以向攻擊者提供更少的信息進行下一步注入攻擊。
檢查是否有特殊字符，如果有特殊字符 ，就轉(zhuǎn)義特殊字符或者替換。例：單引號、雙音哈都轉(zhuǎn)義或者替換。
XPath查詢參數(shù)化，編譯構建XPath表達式，將數(shù)據(jù)輸入以 變量形式 傳遞。
敏感信息如密碼之類，使用哈希值較長的算法處理。

LDAP注入

使用轉(zhuǎn)義特殊字符和白名單來驗證輸入。

JSON注入

在特殊字符前加反斜杠()進行轉(zhuǎn)義
使用java script編碼
使用HTML編碼

XSS

在輸入過濾，在顯示的地方做輸出編碼。
使用一個統(tǒng)一的規(guī)則做輸出編碼
富文本框，使用白名單控制輸入。
使用HTTPOnly標志

CSRF

重要功能增加確認操作或重新認證，例如支付交易、修改手機號碼等
加驗證碼
每個會話中使用強隨機令牌（token）來保護。
檢驗HTTP Referer

會話攻擊

采用強算法生成會話ID，會話ID必須具有隨機性和不可預測性，長度至少為128位。
設定會話過期時間，如：在一定時間內(nèi)沒有與應用交互，設定在登錄一定時間內(nèi)要重新輸入驗證用戶名密碼，如一天等。
設置好Cookie的兩個屬性：secure和HttpOnly來防御嗅探和阻止JS操作。

身份認證

在用戶注冊時強制用戶輸入較高強度密碼、
登錄認證錯誤信息顯示登錄失敗，用戶名或 密碼錯誤。
防止撞庫等攻擊，應該登錄三次失敗后下一次登錄以5秒倍數(shù)，4次登錄失敗，讓用戶輸入驗證碼。
如果每分鐘進行幾十次嘗試登錄，應該被阻止一段時間（如20分鐘），給出清楚明白的信息，說明為什么會阻止登錄一段時間。
使用HTTPS請求傳輸身份驗證和密碼、身份證、手機號碼，郵箱等數(shù)據(jù)。
當密碼重置時，以短信方式通知用戶
用戶賬號上次使用信息在下一次成功登陸時向用戶報告。
在執(zhí)行關鍵操作（如：修改登錄密碼、支付密碼、郵箱、手機號碼等）使用多因子身份驗證。

直接對象引用

使用的唯一標識可以通過隨機數(shù)生成以難以猜測。
在進行頁面顯示或做處理之前對用戶權限進行檢查。
權限信息保存在session中。

Tomcat安全配置

Tomcat以沒有特權的用戶賬戶和組運行，沒有執(zhí)行交互shell命令權限。
Tomcat運行的版本必須打了所有安全補丁的版本。
Tomcat默認的例子相關路徑和文件必須刪除。
Tomcat管理員默認密碼必須被修改成復雜密碼。
頁面出現(xiàn)信息不能顯示Tomcat的版本信息和系統(tǒng)信息。
Tomcat配置文件執(zhí)啟用安全的http方法，如：GET POST。
應用程序和管理程序使用不同的端口。
部署前刪除測試代碼文件。
刪除無用的文件如：備份文件、臨時文件等。
配置文件中沒有默認用戶和密碼。
不要在robot.txt中泄露目錄結(jié)構。

Apache安全配置

選擇漏洞較少的apache版本。
隱藏Apache版本號。
刪除Apache歡迎頁面。
配置只允許訪問Apache的Web目錄
應用程序和管理程序使用不同的端口。
管理額控制臺必須使用SSL協(xié)議。
部署前刪除測試代碼文件。
刪除無用的文件如：備份文件、臨時文件等。
配置文件中沒有默認用戶和密碼。
不要在robot.txt中泄露目錄結(jié)構。

數(shù)據(jù)庫通用配置

修改數(shù)據(jù)庫默認用戶名和密碼。
數(shù)據(jù)庫用戶的密碼要符合一定的復雜度。
訪問數(shù)據(jù)庫的用戶要賦予所需要的最小權限。
啟動應用的系統(tǒng)用戶必須是專用的，沒有系統(tǒng)級別權限的用戶和組。

繞過認證

對登錄后可以訪問的URL做是否登錄檢查，如果沒有登錄將跳轉(zhuǎn)到登錄頁面。
對于敏感信息的請求如登錄時、修改密碼等請求一定要用HTTPS協(xié)議。

越權訪問

驗證一切來自客戶端的參數(shù)，重點是和權限相關的參數(shù)，比如用戶ID或者角色權限ID等。
session ID 和認證的token做綁定，放在服務器的會話里，不發(fā)送給客戶端。
對于用戶登錄后涉及用戶唯一信息的請求，每次都要驗證檢查所有權，敏感信息頁面加隨機數(shù)的參數(shù)，防止瀏覽器緩存內(nèi)容。
把程序分成匿名，授權和管理的區(qū)域，通過將角色和數(shù)據(jù)功能匹配。
不適用參數(shù)來區(qū)分管理員和普通用戶。

文件上傳

上傳的路徑要限制在固定路徑下。
上傳文件路徑只給只讀和寫權限，不需要執(zhí)行權限。
服務端文件類型要使用白名單過濾，后臺不應有添加擴展名類型功能；通過配置文件添加文件類型。
文件上傳使用自己的命名規(guī)則重新命名上傳的文件。

文件目錄遍歷下載

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

網(wǎng)站重定向或轉(zhuǎn)發(fā)

驗證重定向的URL。
使用白名單驗證重定向目標。
網(wǎng)站內(nèi)重定向使用相對路徑URL。
重定向或者轉(zhuǎn)發(fā)之前，要驗證用戶是否有權限訪問目標URL。

業(yè)務邏輯漏洞

應用系統(tǒng)必須確保所有輸入和傳遞的時候必須經(jīng)過有效驗證，不僅僅是在剛進入應用系統(tǒng)的時候進行數(shù)據(jù)驗證。
應用程序應該有檢查功能，避免攻擊者可以通過預測、操作參數(shù)或者利用隱藏的功能（例如調(diào)試）來阻礙操作或者改變業(yè)務邏輯工作流程。
應用需要對輸入進行檢查，不允許用戶直接提交未經(jīng)過驗證的數(shù)據(jù)到服務器，因為這些數(shù)據(jù)來不可編輯的控件，或者用戶沒有前端提交的權限，任何可編輯控件必須有阻止惡意的寫入或修改的功能。
開發(fā)應用的時候需要注意時間處理問題。攻擊者可以簡單地通過了解不同的處理時間、結(jié)果來獲取一些參數(shù)，所以雖然他們提交的結(jié)果也在相同的時間，符合規(guī)則，但卻添加了其他步驟或者處理。
應用程序需要有阻止攻擊者通過延長允許的交易時間的功能，這種情況可以在操作超過規(guī)定的時間后通過取消或者重置交易。
應用程序需要能夠過濾檢測的業(yè)務邏輯：當一個功能或者操作只允許被執(zhí)行有限的幾次 或者用戶不再能夠執(zhí)行這個功能的時候，應用需要能夠檢測出來。為了阻止用戶過多次的執(zhí)行某個功能， 應用程序可以通過類似緩存這種機制來控制，或者使用不允許用戶過多次執(zhí)行功能的機制。
應有用戶正確的按照業(yè)務流程來完成每一個步驟的檢測機制，這樣可以阻止黑客在業(yè)務流程中通過跳過、繞過、重復任何業(yè)務流程中的工序檢查。開發(fā)這部分業(yè)務邏輯的時候應該測試一些無用或者誤用的測試用例，當沒有按照正確的順序完成正確的步驟的時候，就不能成功完成業(yè)務流程。

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

目錄

• SQL注入

• OS命令注入

• XPath注入

• LDAP注入

• JSON注入

• XSS

• CSRF

• 會話攻擊

• 身份認證

• 直接對象引用

• Tomcat安全配置

• Apache安全配置

• 數(shù)據(jù)庫通用配置

• 繞過認證

• 越權訪問

• 文件上傳

• 文件目錄遍歷下載

• 網(wǎng)站重定向或轉(zhuǎn)發(fā)

• 業(yè)務邏輯漏洞

• 
  

問題歸納#
1.1 web安全#
1.1.1 sql注入#
1.1.1.1 漏洞描述#
SQL注入攻擊主要是由于程序員在開發(fā)過程中沒有對客戶端所傳輸?shù)椒�務器端的參�?shù)進行嚴格的安全檢查，同時SQL語句的執(zhí)行引用了該參數(shù)，并且SQL語句采用字符串拼接的方式執(zhí)行時，攻擊者將可能在參數(shù)中插入惡意的SQL查詢語句，導致服務器執(zhí)行了該惡意SQL語句。SQL注入漏洞主要影響是攻擊者可利用該漏洞竊取數(shù)據(jù)庫中的任意內(nèi)容，在某些場景下，攻擊者將有可能獲得數(shù)據(jù)庫服務器的完全控制權限。

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

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

[1] ' 單引號

[2] " 雙引號

[3] ' 反斜杠單引號

[4] " 反斜杠雙引號

[5] ) 括號

[6] ; 分號

[7] -- 雙減號

[8] + 加號

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

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

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

1.1.2.2 修復建議#
建議過濾的關鍵字為：

[1] ' 單引號

[2] " 雙引號

[3] / 斜杠

[4] \ 反斜杠

[5] ) 括號

[6] ; 分號

[7] [ 中括號

[8] < 尖括號

[9] > 尖括號

比如把<編碼為<

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

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

1.1.3.2 修復建議#
對于PHP，常見的XML解析方法有：DOMDocument、SimpleXML、XMLReader，這三者都基于 libxml 庫解析 XML，所以均受影響，xml_parse 函數(shù)則基于 expact 解析器，默認不載入外部 DTD ，不受影響�？梢栽趐hp解析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，跨站點偽造請求）是一種網(wǎng)絡攻擊方式，該攻擊可以在用戶毫不知情的情況下以用戶自身的名義偽造請求發(fā)送給受攻擊站點，從而在未授權的情況下執(zhí)行在權限保護之下的操作。具體來講，可以這樣理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發(fā)送惡意請求，對服務器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作，比如以你的名義發(fā)送郵件、發(fā)消息，盜取你的賬號，添加系統(tǒng)管理員，甚至于購買商品、虛擬貨幣轉(zhuǎn)賬等。

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

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

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

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

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

統(tǒng)一錯誤信息，避免用戶可以根據(jù)錯誤信息來判斷遠端服務器的端口狀態(tài)。

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

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

過濾內(nèi)網(wǎng)ip，限制訪問內(nèi)網(wǎng)

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

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

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

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

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

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

文件內(nèi)容服務端校驗。

上傳文件重命名。

隱藏上傳文件路徑。

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

1.1.7.2 修復建議#
對path參數(shù)進行過濾，依次過濾“.”、“..”、“/”、“\”等字符。

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

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

1.1.8.2 修復建議#
對參數(shù)進行過濾，依次過濾“.”、“..”、“/”、“\”等字符。
1.1.9 .svn/.git源代碼泄露#
1.1.9.1 漏洞概述#
.svn/.git源代碼泄露主要原因是由于應用系統(tǒng)開發(fā)人員或運維管理人員在對應用系統(tǒng)進行版本迭代更新時，沒有及時對代碼版本維護程序(svn或git)中所產(chǎn)生的代碼索引或代碼庫文件進行及時清理，攻擊者可通過讀取該代碼索引或代碼庫文件訪問并下載應用系統(tǒng)的源代碼信息，最終導致應用系統(tǒng)的源代碼信息遭到泄露，攻擊者可進一步通過源代碼審計的方式挖掘應用系統(tǒng)中存在的安全隱患。

1.1.9.2 修復建議#
開發(fā)人員在使用 SVN/Git 時，嚴格使用導出功能，禁止直接復制代碼部署上線。

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

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

1.1.10.2 修復建議#
對身份驗證時傳輸?shù)挠脩裘�密碼等作加密處理，為了防止重放攻擊可以在驗證時加個隨機數(shù)，以保證驗證單次有效。

關閉錯誤輸出，防止調(diào)試信息泄露，或者當web應用程序出錯時，統(tǒng)一返回一個錯誤頁面或直接跳轉(zhuǎn)至首頁

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

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

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

1.1.11.2 修復建議#
開發(fā)人員在使用phpinfo界面時，嚴格使用導出功能，禁止直接復制代碼部署上線。

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

1.1.12 IIS短文件名泄露#
1.1.12.1 漏洞概述#
Internet Information Services（IIS，互聯(lián)網(wǎng)信息服務）是由微軟公司提供的基于運行Microsoft Windows的互聯(lián)網(wǎng)基本服務。Microsoft IIS在實現(xiàn)上存在文件枚舉漏洞，攻擊者可利用此漏洞枚舉網(wǎng)絡服務器根目錄中的文件。危害：攻擊者可以利用“~”字符猜解或遍歷服務器中的文件名，或?qū)�IIS服務器中的.Net Framework進行拒絕服務攻擊。

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

1.1.12.2 修復建議#
修改Windows配置，關閉短文件名功能。

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

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

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

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

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

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

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

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

1.1.13.2 修復建議#
對于 Apache 可以做以下優(yōu)化：

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

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

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

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

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

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

1.1.15.2 修復建議#
限制用戶輸入的CR和LF，或者對CR和LF字符正確編碼后再輸出。CR、LF分別對應回車（%0d）、換行（%0a）字符。
1.1.16 命令執(zhí)行注入#
1.1.16.1 漏洞概述#
命令執(zhí)行注入主要是由于開發(fā)人員在處理應用系統(tǒng)發(fā)起操作系統(tǒng)命令時引用了客戶端參數(shù)，同時沒有對該參數(shù)進行合法性校驗，攻擊者可在參數(shù)中注入惡意的命令參數(shù)，致使執(zhí)行命令的過程中執(zhí)行了攻擊者所指定的惡意命令。通過該漏洞攻擊者可執(zhí)行任意的操作系統(tǒng)命令，在權限配置不當?shù)那闆r下可直接獲得操作系統(tǒng)的完全控制權限。

1.1.16.2 修復建議#
盡量避免使用exec、system、passthru、popen、shell_exec、eva l、execute、assert等此類執(zhí)行命令/執(zhí)行代碼相關函數(shù)。

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

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

1.1.17.2 修復建議#
避免使用重定向和轉(zhuǎn)發(fā)

如果使用了重定向和轉(zhuǎn)發(fā)，則不要在接受目標時涉及到用戶參數(shù)

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

確定白名單及網(wǎng)絡邊界，限定協(xié)議以及可訪問的網(wǎng)絡

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

1.1.18.2 修復建議#
嚴格安全的實現(xiàn) CSRF 方式調(diào)用 JSON 文件：限制 Referer 、部署一次性 Token等。

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

嚴格過濾 callback 函數(shù)名及 JSON 里數(shù)據(jù)的輸出。

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

1.1.19 第三方組件安全#
1.1.19.1 漏洞概述#
第三方組件主要包括Ewebeditor、FCKeditor、Ueditor、JQuery等常用第三方組件，開發(fā)人員在開發(fā)過程中調(diào)用第三方組件時并未考慮組件當前的安全狀況，攻擊者可通過第三方組件上的安全漏洞攻擊應用系統(tǒng)，從而影響應用系統(tǒng)自身的安全。

1.1.19.2 修復建議#
無

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

1.1.20.2 修復建議#
保證參數(shù)用戶不可控/不可構造性。

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

對所有的變量初始化。

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

1.1.21.2 修復建議#
盡量避免使用exec、system、passthru、popen、shell_exec、eva l、execute、assert等此類執(zhí)行命令/執(zhí)行代碼相關函數(shù)。

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

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

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

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

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

1.1.23.2 修復建議#
該漏洞為Spring標簽EL表達式注入，CVE編號為CVE-2011-2730。

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

Spring Expression Language SupportspringJspExpressionSupportfalse

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

1.1.24.2 修復建議#
無

1.2 業(yè)務邏輯安全#
1.2.1 用戶名枚舉#
1.2.1.1 漏洞概述#
在應用系統(tǒng)登錄過程中，當輸入錯誤的用戶名信息時，應用程序?qū)⒎答佅鄳�的諸如“用戶不存在”的錯誤提示，攻擊者可通過該提示為依據(jù)進行對用戶名的枚舉，猜解出已存在于應用系統(tǒng)的用戶名信息，最終攻擊者可進行一步發(fā)起對已有用戶的密碼猜解。

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

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

系統(tǒng)設置強密碼策略，建議用戶密碼采用10位以上數(shù)字加大小寫字母。

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

1.2.2 用戶密碼枚舉#
1.2.2.1 漏洞概述#
在應用系統(tǒng)登錄過程中，由于并未限制用戶的密碼輸入錯誤次數(shù)，攻擊者可通過密碼字典不斷枚舉指定用戶的密碼信息，最終用戶密碼將可能遭受到破解，攻擊者可通過所破解的用戶密碼進入應用系統(tǒng)并發(fā)起進一步的攻擊。

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

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

系統(tǒng)設置強密碼策略，建議用戶密碼采用10位以上數(shù)字加大小寫字母。

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

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

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

系統(tǒng)設置強密碼策略，建議用戶密碼采用10位以上數(shù)字加大小寫字母。

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

1.2.4 網(wǎng)站后臺弱口令#
1.2.4.1 漏洞概述#
由于網(wǎng)站后臺管理員密碼強度低，容易被攻擊者暴力破解。攻擊者可利用弱口令獲得網(wǎng)站管理員權限，進入網(wǎng)站后臺，嚴重者可導致服務器淪陷

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

系統(tǒng)設置強密碼策略，建議用戶密碼采用10位以上數(shù)字加大小寫字母。

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

1.2.5 會話標志固定攻擊#
1.2.5.1 漏洞概述#
應用系統(tǒng)在用戶登錄成功或登錄失敗后并未對當前的會話標志（Session ID）進行更新，從而攻擊者可構造一個未登錄且?guī)в蠸ession ID的URL并發(fā)送到用戶，用戶點擊該URL并進行登錄成功后，攻擊者可通過該Session ID冒充用戶并成功進入應用系統(tǒng)，從而可進一步發(fā)起對應用系統(tǒng)的攻擊。

1.2.5.2 修復