1.1 AppScan掃描建議
若干問題的補救方法在於對用戶輸入進行清理。
通過驗證用戶輸入未包含危險字符，便可能防止惡意的用戶導致應用程序執行計划外的任務，例如：啟動任意 SQL 查詢、嵌入將在客戶端執行的 Javascript 代碼、運行各種操作系統命令，等等。
建議過濾出所有以下字符：
[1] |（豎線符號）
[2] & （& 符號）
[3];（分號）
[4] $（美元符號）
[5] %（百分比符號）
[6] @（at 符號）
[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 應用程序解決方案
1、我們為了調試方便，在頁面上會拋出數據庫異常信息，如果入侵工具獲取了這些信息，就可以獲取系統的一些配置信息，如web系統框架、采用的數據庫等，從而找出系統漏洞。所以不要在頁面上拋出異常的詳細信息，這些信息對客戶並沒有用，只是方便技術人員調試罷了，處理方法是在異常處理頁面把打印異常代碼刪除即可；
2、新建一個過濾器，通過過濾器過濾SQL注入特殊字符，配置成功后，重啟服務，用Appsan工具掃描，漏洞得到解決，通過過濾器可以解決SQL注入、跨站點腳本編制及通過框架釣魚等問題，具體實現方式如下：
1、在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>
2、過濾器過濾代碼
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