1.1 AppScan掃描建議
若干問題的補救方法在於對用戶輸入進行清理。
經過驗證用戶輸入未包含危險字符，即可能防止惡意的用戶致使應用程序執行計劃外的任務，例如：啓動任意 SQL 查詢、嵌入將在客戶端執行的 Javascript 代碼、運行各類操做系統命令，等等。
建議過濾出全部如下字符：html
[1] |（豎線符號）java
[2] & （& 符號）程序員
[3];（分號）web
[4] $（美圓符號）算法
[5] %（百分比符號）spring
[6] @（at 符號）shell
[7] '（單引號）數據庫
[8] "（引號）編程
[9] \'（反斜槓轉義單引號）瀏覽器
[10] \"（反斜槓轉義引號）
[11] <>（尖括號）
[12] ()（括號）
[13] +（加號）
[14] CR（回車符，ASCII0x0d）
[15] LF（換行，ASCII0x0a）
[16] ,（逗號）
[17] \（反斜槓）
如下部分描述各類問題、問題的修訂建議以及可能觸發這些問題的危險字符：
SQL 注入和 SQL 盲注：
A. 確保用戶輸入的值和類型（如 Integer、Date 等）有效，且符合應用程序預期。
B. 利用存儲過程，將數據訪問抽象化，讓用戶不直接訪問表或視圖。當使用存儲過程時，請利用 ADO 命令對象來實施它們，以強化變量類型。
C. 清理輸入以排除上下文更改符號，例如：
[1] '（單引號）
[2] "（引號）
[3] \'（反斜線轉義單引號）
[4] \"（反斜槓轉義引號）
[5] )（結束括號）
[6] ;（分號）
跨站點腳本編制：
A. 清理用戶輸入，並過濾出 JavaScript 代碼。咱們建議您過濾下列字符：
[1] <>（尖括號）
[2] "（引號）
[3] '（單引號）
[4] %（百分比符號）
[5] ;（分號）
[6] ()（括號）
[7] &（& 符號）
[8] +（加號）
B. 若是要修訂 <%00script> 變體，請參閱 MS 文章 821349
C. 對於 UTF-7 攻擊： [-] 可能的話，建議您施行特定字符集編碼（使用 'Content-Type' 頭或 <meta> 標記）。
HTTP 響應分割：清理用戶輸入（至少是稍後嵌入在 HTTP 響應中的輸入）。
請確保輸入未包含惡意的字符，例如：
[1] CR（回車符，ASCII0x0d）
[2] LF（換行，ASCII0x0a）遠程命令執行：清理輸入以排除對執行操做系統命令有意義的符號，例如：
[1] |（豎線符號）
[2] & （& 符號）
[3];（分號）
執行 shell 命令：
A. 毫不將未檢查的用戶輸入傳遞給 eval()、open()、sysopen()、system() 之類的 Perl 命令。
B. 確保輸入未包含惡意的字符，例如：
[1] $（美圓符號）
[2] %（百分比符號）
[3] @（at 符號）
XPath 注入：清理輸入以排除上下文更改符號，例如：
[1] '（單引號）
[2] "（引號） 等
LDAP 注入：
A. 使用正面驗證。字母數字過濾（A..Z,a..z,0..9）適合大部分 LDAP 查詢。
B. 應該過濾出或進行轉義的特殊 LDAP 字符：
[1] 在字符串開頭的空格或「#」字符
[2] 在字符串結尾的空格字符
[3] ,（逗號）
[4] +（加號）
[5] "（引號）
[6] \（反斜槓）
[7] <>（尖括號）
[8] ;（分號）
[9] ()（括號）
MX 注入：
應該過濾出特殊 MX 字符：
[1] CR（回車符，ASCII0x0d）
[2] LF（換行，ASCII0x0a）記錄僞造：
應該過濾出特殊記錄字符：
[1] CR（回車符，ASCII0x0d）
[2] LF（換行，ASCII0x0a）
[3] BS（退格，ASCII0x08）
ORM 注入：
A. 確保用戶輸入的值和類型（如 Integer、Date 等）有效，且符合應用程序預期。
B. 利用存儲過程，將數據訪問抽象化，讓用戶不直接訪問表或視圖。
C. 使用參數化查詢 API
D. 清理輸入以排除上下文更改符號，例如： (*)：
[1] '（單引號）
[2] "（引號）
[3] \'（反斜線轉義單引號）
[4] \"（反斜槓轉義引號）
[5] )（結束括號）
[6] ;（分號）
1.2 應用程序解決方案
一、咱們爲了調試方便，在頁面上會拋出數據庫異常信息，若是入侵工具獲取了這些信息，就能夠獲取系統的一些配置信息，如web系統框架、採用的數據庫等，從而找出系統漏洞。因此不要在頁面上拋出異常的詳細信息，這些信息對客戶並無用，只是方便技術人員調試罷了，處理方法是在異常處理頁面把打印異常代碼刪除便可；
二、新建一個過濾器，經過過濾器過濾SQL注入特殊字符，配置成功後，重啓服務，用Appsan工具掃描，漏洞獲得解決，經過過濾器能夠解決SQL注入、跨站點腳本編制及經過框架釣魚等問題，具體實現方式以下：
一、在web.xml文件中配置過濾器
<filter-mapping>
<filter-name>requestEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter>
<filter-name>InjectFilter</filter-name>
<filter-class>com.sitech.ismp.util.context.InjectFilter</filter-class>
</filter>
二、過濾器過濾代碼
public class InjectFilter extendsIsmpServletFilter {
private String failPage ="/loginout.jsp";//發生注入時，跳轉頁面
publicvoid doFilter(ServletRequest request,ServletResponse response,
FilterChain filterchain)throwsIOException, ServletException {
//判斷是否有注入攻擊字符
HttpServletRequest req = (HttpServletRequest)request;
Stringinj = injectInput(req);
if(!inj.equals("")) {
request.getRequestDispatcher(failPage).forward(request,response);
return;
} else {
// 傳遞控制到下一個過濾器
filterchain.doFilter(request,response);
}
}
/**
* 判斷request中是否含有注入攻擊字符
* @param request
* @return
*/
publicString injectInput(ServletRequest request) {
Enumeration e =request.getParameterNames();
String attributeName;
String attributeValues[];
String inj = "";
while (e.hasMoreElements()) {
attributeName= (String)e.nextElement();
//不對密碼信息進行過濾，通常密碼中能夠包含特殊字符
if(attributeName.equals("userPassword")||attributeName.equals("confirmPassword")||attributeName.equals("PASSWORD")
||attributeName.equals("password")||attributeName.equals("PASSWORD2")||attributeName.equals("valiPassword")){
continue;
}
attributeValues= request.getParameterValues(attributeName);
for(int i = 0; i < attributeValues.length; i++) {
if(attributeValues[i]==null||attributeValues[i].equals(""))
continue;
inj= injectChar(attributeValues[i]);
if(!inj.equals("")) {
returninj;
}
}
}
return inj;
}
/**
* 判斷字符串中是否含有注入攻擊字符
* @param str
* @return
*/
publicString injectChar(String str) {
String inj_str = "\" ) \' * %";
String inj_stra[] = inj_str.split(" ");
for (int i = 0 ; i < inj_stra.length ; i++ )
{
if (str.indexOf(inj_stra[i])>=0)
{
return inj_stra[i];
}
}
return "";
}
}
2 會話標識未更新
2.1 會話標識未更新概述
「會話固定」是一種攻擊技術，會強制用戶的會話標識變成顯式值。 固定會話標識值的技術有許多種，會隨着目標Web 站點的功能而不一樣。從利用「跨站點腳本編制」到向Web 站點密集發出先前生成的 HTTP 請求，都在這些技術範圍內。用戶的會話標識固定以後，攻擊者會等待用戶登陸，而後利用預約義的會話標識值來假定用戶的聯機身份。
通常而言，對於標識值的會話管理系統有兩種類型。第一種類型是「寬容」系統，可以讓 Web 瀏覽器指定任何標識。第二種類型是「嚴格」系統，只接受服務器端生成的值。當使用寬容系統時，不須要聯繫 Web 站點，即可以維護任何會話標識。在嚴格系統中，攻擊者須要維護「陷阱會話」而且必須按期聯繫 Web 站點，才能防止閒置超時。對於會話固定，假若沒有活動保護，使用會話來識別已認證的用戶的任何 Web 站點均可能受到攻擊。使用會話標識的 Web 站點一般都是基於cookie 的站點，但也會使用 URL 和隱藏的表單字段。不幸的是，基於 cookie 的會話最容易受到攻擊。 目前已識別的大多數攻擊方法都是針對 cookie 的固定。 相對於在用戶登陸 Web 站點以後，再竊取用戶的會話標識，會話固定提供的機會多得多。
在用戶登陸以前，攻擊的活動部分便已啓動。
會話固定攻擊過程一般由三個步驟組成：
1) 安裝會話
攻擊者針對目標 Web 站點設下「陷阱會話」，並獲取這個會話的標識，攻擊者也能夠選擇攻擊中所用的任意會話標識。在某些狀況下，必須反覆聯繫 Web 站點，才能維護肯定好的陷阱會話值。
2) 固定會話
攻擊者將陷阱會話值引進用戶的瀏覽器中，固定用戶的會話標識。
3) 進入會話
用戶登陸目標 Web 站點以後，當使用固定會話標識值時，攻擊者即可加以接管。」
2.2 安全風險及緣由分析
高風險漏洞，可能會竊取或操縱客戶會話和 cookie，它們可能用於模仿合法用戶，從而使黑客可以以該用戶身份查看或變動用戶記錄以及執行事務
緣由：Web 應用程序編程或配置不安全
2.3 AppScan掃描建議
始終生成新的會話，供用戶成功認證時登陸。 防止用戶操縱會話標識。
請勿接受用戶瀏覽器登陸時所提供的會話標識
2.4 應用程序解決方案
會話標識未更新，Appscan給出的描述是建議用戶每次登陸時需使用新的會話標識。應用程序實現上就是在登陸模塊，添加如下代碼，即用戶登陸後，從新生成會話。
HttpSession session = request.getSession(false);
if(session!=null){//讓cookie過時
session.invalidate();
Cookie cookie = request.getCookies()[0];//獲取cookie
cookie.setMaxAge(0);//讓cookie過時
}
request.getSession(true);//生成新會話
通過測試，這段代碼只在weblogic和tomcat下才有效，在公司中間件webspeed及jboss6.0下問題都依然存在，但從掃描的結果信息分析看，漏洞已經解決，分析判斷應該只是session處理機制不一樣，AppScan工具仍認爲存在漏洞風險。在與電信溝通中咱們存在一個經驗教訓你們必定要吸收，不能過渡迷信流行的自動化測試工具，尤爲是對於Appscan這種判斷防護行爲的複雜軟件，僅靠有限的規則設置就當作是web安全的惟一標準這顯然不太合理，這種狀況必定要與測試方溝通解釋。
另外一方面，對於公司的產品webspeed，也想提點建議，商務項目採用公司的產品爲公司節約了很多成本，可是咱們產品後續升級維護也必須重視起來，當確認出是webspeed自己問題後，聯繫vasg相關人員進行協調解決，根本沒有很是瞭解該產品技術人員支持，只是一個剛入職的同事在配合測試。調試了一週時間仍不能解決，最後只能做爲一個遺留問題擱置。公司一直在向產品化轉變，可是自身的產品維護、升級、管理仍然須要改進。
3 已解密登陸請求
3.1 已解密登陸請求概述
在應用程序測試過程當中，檢測到將未加密的登陸請求發送到服務器。因爲登陸過程所用的部分輸入字段（例如：用戶名、密碼、電子郵件地址、社會保險號碼，等等）是我的敏感信息，建議經過加密鏈接（如 SSL）將其發送到服務器。任何以明文傳給服務器的信息均可能被竊，稍後可用來電子欺騙身份或假裝用戶。 此外，若干隱私權法規指出，用戶憑證之類的敏感信息一概以加密方式傳給網站。
3.2 安全風險及緣由分析
安全風險中，可能會竊取諸如用戶名和密碼等未經加密即發送了的用戶登陸信息
緣由：諸如用戶名、密碼和信用卡號之類的敏感輸入字段未經加密即進行了傳
遞
3.3 AppScan掃描建議
1. 確保全部登陸請求都以加密方式發送到服務器。
2. 請確保敏感信息，例如：
- 用戶名
- 密碼
- 社會保險號碼
- 信用卡號碼
- 駕照號碼
- 電子郵件地址
- 電話號碼
- 郵政編碼
一概以加密方式傳給服務器。
3.4 應用程序解決方案
已解密的登陸請求，要求就是數據要加密傳輸。最簡單有效的解決方式採用SSL加密協議傳輸，可是因爲EMA服務管理平臺業務的特殊性，採用SSL加密方式對現有的業務影響太大，因此最終沒有采用此種方式解決該問題，但我的在進行測試過程當中也嘗試在tomcat和jboss下SSL方式配置，寫下來供參考。
Jboss內核也是tomcat，因此二者配置基本都是同樣，都是在生成證書文件後，在service.xml 進行配置：
1. 進入到cmd 進入到jdk bin目錄下執行keytool-genkey -alias tomcat -keyalg RSA -keystore webspeed.keystore 生成證書
2. 在service.xml配置SSL
<Connector port="8443"maxHttpHeaderSize="8192"
maxThreads="150"minSpareThreads="25" maxSpareThreads="75"
enableLookups="false"disableUploadTimeout="true"
acceptCount="100"scheme="https" secure="true"
clientAuth="false"sslProtocol="TLS"
keystoreFile="C:\tomcat-5.5.26\conf\webspeed.keystore" keystorePass="1111aaaa"/>
這樣配置後雖然能夠經過https訪問，但仍然還能夠經過8080使用普通的http訪問，因此還必須禁止普通模式登陸。因此還得在web.xml添加配置。
| 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
<security-constraint>
<!-- Authorization setting for SSL -->
<web-resource-collection >
<web-resource-name >SSL</web-resource-name>
<url-pattern>*.jsp</url-pattern>
<url-pattern>*.action</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<!-- Authorization setting for SSL -->
<auth-method>CLIENT-CERT</auth-method>
<realm-name>Client Cert Users-only Area</realm-name>
</login-config> |
應注意，因爲項目的一些組件沒法經過https，所以url-pattern字段只對.jsp和.action進行了限制，若是不作特定限制，則系統默認是所有使用https傳輸。並且上述設置一旦在某個工程中出現，那麼當前tomcat將全局採用這一配置。
4 跨站點請求僞造
4.1 跨站點請求僞造概述
「跨站點僞造請求(CSRF)」攻擊可以讓黑客以受害者的名義在易受攻擊的站點上運行操做。當易受攻擊的站點未適當驗證請求來源時，即可能出現這個攻擊。這個漏洞的嚴重性取決於受影響的應用程序的功能，例如，對搜索頁面的 CSRF 攻擊，嚴重性低於對轉賬頁面或概要更新頁面的 CSRF 攻擊。
這項攻擊的執行方式，是強迫受害者的瀏覽器向易受攻擊的站點發出 HTTP 請求。若是用戶目前已登陸受害者站點，請求會自動使用用戶的憑證（如會話 Cookie、用戶的 IP 地址，以及其餘瀏覽器認證方法）。攻擊者利用這個方法來僞造受害者的身份，再代替他來提交操做。換句話來講，易受攻擊的站點未採起適當措施來驗證用戶實際是否想執行特定操做。
強迫受害者發送非預期的請求，方法有許多種：
- 經過電子郵件向受害者發送易受攻擊應用程序的惡意連接。 - 在黑客的 Web 頁面上，放置一個易受攻擊的 Web 站點的熱連接（如圖像或幀）。 - 在公共論壇中，張貼易受攻擊站點的連接。
- 利用站點（或另外一個站點）的「跨站點腳本編制」或「連接注入」漏洞，將瀏覽器自動重定向到易受攻擊的站點。
若是攻擊者利用易受攻擊的站點自己的「連接注入」漏洞，能夠增長用戶經過站點認證的可能性，進而增長攻擊成功的可能性。
例如，攻擊者能夠利用上述任何選項來誘惑受害者查看含有下列條目的頁面：
<img src="http://bank/transfer?destination=John&money=1000"style='visibility:hidden'>
這會使受害者的瀏覽器自動請求 URL 及瀏覽器的當前憑證。若是這個銀行業站點易受到 CSRF 攻擊，它會根據應用程序邏輯，從受害者的賬戶中，將 1000 美圓轉帳到 John 的銀行賬戶。「跨站點僞造請求」攻擊也稱爲 CSRF（發音爲 C-Serf）、XSRF、「跨站點僞造引用」、「單鍵攻擊」以及「會話騎乘」。
您能夠利用下列方式來驗證您的應用程序是否易受到 CSRF 攻擊：
[1] 檢查易受攻擊的連接/請求是否未包括攻擊者難以猜中的參數
[2] 檢查易受攻擊的連接/請求是否會執行只應自願執行的操做
含有用戶在不知不覺中提交的請求所能直接訪問的敏感操做的應用程序，被視爲很容易遭受 CSRF 攻擊。CSRF 也可能出如今登陸頁面和註銷頁面上。因爲攻擊者能夠僞造來自受害者的連續註銷請求，所以 CSRF 可能致使服務拒絕。在登陸頁面上，CSRF 能夠容許攻擊者使用包含攻擊者用戶名和密碼的僞造請求來將客戶機登陸到攻擊者的帳戶中。登陸 CSRF 攻擊會帶有嚴重的後果，這取決於其餘站點行爲。例如，若是站點保留了用戶操做的歷史記錄（例如搜索歷史記錄），那麼攻擊者將可以在易受攻擊的站點上查看受害者以前執行的操做。
4.2 安全風險及緣由分析
安全風險中，可能會竊取或操縱客戶會話和cookie，它們可能用於模仿合法用戶，從而使黑客可以以該用戶身份查看或變動用戶記錄以及執行事務
緣由：應用程序使用的認證方法不充分
4.3 AppScan掃描建議
若是要避免 CSRF 攻擊，每一個請求都應該包含惟一標識，它是攻擊者所沒法猜想的參數。建議的選項之一是添加取自會話 cookie 的會話標識，使它成爲一個參數。服務器必須檢查這個參數是否符合會話cookie，若不符合，便廢棄請求。 攻擊者沒法猜想這個參數的緣由是應用於 cookie 的「同源策略」，所以，攻擊者沒法僞造一個虛假的請求，讓服務器誤覺得真。攻擊者難以猜想且沒法訪問的任何祕密（也就是沒法從其餘域訪問），均可用來替換會話標識。這能夠防止攻擊者設計看似有效的請求。
登陸的跨站點請求解決代碼：
1 package com.tyky.cas.web.filter; 2 3 import java.security.MessageDigest; 4 import java.security.NoSuchAlgorithmException; 5 import java.util.HashMap; 6 import java.util.Map; 7 import java.util.UUID; 8 9 import javax.servlet.http.HttpServletRequest; 10 import javax.servlet.http.HttpSession; 11 12 import org.slf4j.Logger; 13 import org.slf4j.LoggerFactory; 14 import org.springframework.stereotype.Controller; 15 import org.springframework.util.StringUtils; 16 import org.springframework.web.bind.annotation.RequestMapping; 17 18 @Controller 19 @RequestMapping("/csrf/token") 20 public class CSRFTokenGeneration { 21 private static final Logger logger = LoggerFactory.getLogger(RegisterIndexSessionFilter.class); 22 // 獲取token值 23 public static String getTokenKey(HttpServletRequest request) { 24 25 String key = null; 26 27 try { 28 29 MessageDigest mDigest = MessageDigest.getInstance("MD5");// 摘要算法能夠本身選擇 30 logger.warn(" URL = " + request.getRequestURL().toString()); 31 32 byte[] result = mDigest.digest(request.getRequestURL().toString().getBytes()); 33 34 key = bytesToHexString(result); 35 36 // key = StringUtil.bytes2hex(result); 37 38 } catch (NoSuchAlgorithmException e) { 39 40 logger.error("get token key failed", e); 41 42 } 43 44 return key; 45 46 } 47 48 public static String bytesToHexString(byte[] src) { 49 StringBuilder stringBuilder = new StringBuilder(""); 50 if (src == null || src.length <= 0) { 51 return null; 52 } 53 for (int i = 0; i < src.length; i++) { 54 int v = src[i] & 0xFF; 55 String hv = Integer.toHexString(v); 56 if (hv.length() < 2) { 57 stringBuilder.append(0); 58 } 59 stringBuilder.append(hv); 60 } 61 return stringBuilder.toString(); 62 } 63 64 public static String getTokenValue(HttpServletRequest request) { 65 66 String key = getTokenKey(request); 67 68 Map<String, String> tokenMap = null; 69 70 Object obj = request.getSession().getAttribute("tokenMap"); 71 72 if (obj == null) { 73 74 tokenMap = new HashMap<String, String>(); 75 76 request.getSession().setAttribute("tokenMap", tokenMap); 77 78 } else { 79 80 tokenMap = (Map<String, String>) obj; 81 82 } 83 84 if (tokenMap.containsKey(key)) { 85 86 return tokenMap.get(key); 87 88 } 89 90 String value = UUID.randomUUID().toString();// GUID實現可自行百度，其實弄個僞隨機數也是能夠的... 91 92 tokenMap.put(key, value); 93 94 return value; 95 96 } 97 98 public static boolean verify(String key, String value, HttpServletRequest request) { 99 100 boolean result = false; 101 102 if (StringUtils.isEmpty(key) || StringUtils.isEmpty(value)) {// key或value只要有一個不存在就驗證不經過 103 104 return result; 105 106 } 107 108 if (request.getSession() != null) { 109 110 HttpSession session = request.getSession(); 111 Map<String, String> tokenMap = (Map<String, String>) session.getAttribute("tokenMap"); 112 // Map<String,String> tokenMap = getTokenMap(request); 113 114 if (null != tokenMap && value.equals(tokenMap.get(key))) { 115 116 result = true; 117 118 tokenMap.remove(key);// 成功一次就失效 119 120 } 121 122 } 123 124 return result; 125 126 } 127 128 }
html頁面添加隱藏信息：
1 <input type="hidden" name="token_key" value="<%=com.tyky.cas.web.filter.CSRFTokenGeneration.getTokenKey(request) %>"/> 2 <input type="hidden" name="token_value" value="<%=com.tyky.cas.web.filter.CSRFTokenGeneration.getTokenValue(request) %>"/>
添加過濾器：
1 <filter> 2 <filter-name>NewRegiseterIndxeFilter</filter-name> 3 <filter-class>com.tyky.cas.web.filter.RegisterIndexSessionFilter</filter-class> 4 </filter> 5 6 7 <filter-mapping> 8 <filter-name>NewRegiseterIndxeFilter</filter-name> 9 <url-pattern>/login</url-pattern> 10 </filter-mapping>
4.4 應用程序解決方案
已解密的登陸請求，要求就是數據要加密傳輸。最簡單有效的解決方式採用SSL加密協議傳輸，可是因爲EMA服務管理平臺業務的特殊性，採用SSL加密方式對現有的業務影響太大，因此最終沒有采用此種方式解決該問題，但我的在進行測試過程當中也嘗試在tomcat和jboss下SSL方式配置，寫下來供參考。
5 不充分帳戶封鎖
5.1 不充分帳戶封鎖概述
蠻力攻擊是指惡意用戶發送大量可能的密碼和/或用戶名以訪問應用程序的嘗試。 因爲該技術包含大量登陸嘗試，未限制容許的錯誤登陸請求次數的應用程序很容易遭到這類攻擊。 所以，強烈建議您對賬戶限制容許的錯誤登陸嘗試次數，超過該次數，便鎖定該賬戶。樣本利用：
下列請求說明密碼猜想請求：
http://site/login.asp?username=EXISTING_USERNAME&password=GUESSED_PASSWORD若是站點在若干次錯誤嘗試以後並不鎖定測試的賬戶，攻擊者最終可能會發現賬戶密碼，並使用它來假冒賬戶的合法用戶。
5.2 安全風險及緣由分析
安全風險高，可能會升級用戶特權並經過Web 應用程序獲取管理許可權
緣由：Web 應用程序編程或配置不安全
5.3 AppScan掃描建議
請肯定容許的登陸嘗試次數（一般是 3-5 次），確保超出容許的嘗試次數以後，便鎖定賬戶。 爲了不真正的用戶因賬戶被鎖定而致電支持人員的麻煩，能夠僅臨時性暫掛賬戶活動，並在特定時間段以後啓用賬戶。賬戶鎖定大約 10 分鐘，一般便足以阻止蠻力攻擊。
5.4 應用程序解決方案
根據掃描建議，web應用程序設定容許登陸嘗試次數，登陸連續失敗超過設定次數，就鎖定用戶，失敗次數靈活配置。
在用戶登陸時進行驗證：
if(!encrypter.encrypt(userPassword).equalsIgnoreCase(
user.getLOGIN_PASSWD()== null ? "" : user.getLOGIN_PASSWD()))
{
//更新此用戶登陸失敗次數
this.updateLoginFailTimes(userCode);
//若是用戶連續登陸失敗次數超過配置值則將其鎖定
intloginLockTimes=this.getLoginLockTimes();
if(this.getLoginFailTimes(userCode)>=loginLockTimes){
this.lockUser(userCode);
}
thrownew MySecurityException("密碼不正確! 用戶:" + userCode);
}
6 啓用不安全HTTP方法
6.1 啓用不安全HTTP方法概述
彷佛 Web 服務器配置成容許下列其中一個（或多個）HTTP 方法（動詞）：
- DELETE
- SEARCH
- COPY
- MOVE
- PROPFIND
- PROPPATCH
- MKCOL
- LOCK
- UNLOCK
這些方法可能表示在服務器上啓用了 WebDAV，可能容許未受權的用戶對其進行利用。
6.2 安全風險及緣由分析
| 安全風險中，可能會在 Web 服務器上上載、修改或刪除 Web 頁面、腳本和文件 |
|
|
緣由：Web 服務器或應用程序服務器是以不安全的方式配置的
6.3 AppScan掃描建議
若是服務器不須要支持 WebDAV，請務必禁用它，或禁止沒必要要的 HTTP 方法（動詞）。
6.4 應用程序解決方案
修改web工程中web.xml,增長安全配置信息，禁用沒必要要HTTP方法
<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>test</description>
<url-pattern>*.jsp</url-pattern>
<url-pattern>*.do</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection><!--
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
--></security-constraint>。
7 HTTP註釋敏感信息
7.1 HTTP註釋敏感信息概述
不少Web 應用程序程序員使用 HTML 註釋，以在須要時幫助調試應用程序。儘管添加常規註釋有助於調試應用程序，但一些程序員每每會遺留重要數據（例如：與 Web 應用程序相關的文件名、舊的連接或原非供用戶瀏覽的連接、舊的代碼片斷等）。
7.2 安全風險及緣由分析
安全風險低，能會收集有關 Web 應用程序的敏感信息，如用戶名、密碼、機器名和/或敏感文件位置
緣由：程序員在 Web 頁面上留下調試信息
7.3 AppScan掃描建議
[1] 請勿在 HTML 註釋中遺留任何重要信息（如文件名或文件路徑）。
[2] 從生產站點註釋中除去之前（或將來）站點連接的跟蹤信息。
[3] 避免在 HTML 註釋中放置敏感信息。
[4] 確保 HTML 註釋不包括源代碼片斷。
[5] 確保程序員沒有遺留重要信息。
。
7.4 應用程序解決方案
雖然這個漏洞爲低級別漏洞，但電信方也是要求必須修復，要修改此漏洞須要檢查工程中的每個jsp頁面，工做量仍是挺大。因此在後續開發過程當中註釋儘可能寫英文註釋，儘可能不要遺留敏感註釋信息在jsp代碼中，養成良好的編碼習慣纔是解決問題根本。
轉載自：http://blog.csdn.net/huoyunshen88/article/details/39181107