javaWeb安全漏洞修復總結

時間 2019-11-17

標籤 javaweb 安全漏洞修復總結欄目 Java 简体版

原文原文鏈接

1 Web安全介紹1javascript

2 SQL注入、盲注1css

2.1 SQL注入、盲注概述 1html

2.2 安全風險及緣由 2java

2.3 AppScan掃描建議 2程序員

2.4 應用程序解決方案 4web

3 會話標識未更新7shell

3.1 會話標識未更新概述 7數據庫

3.2 安全風險及緣由分析 7編程

3.3 AppScan掃描建議 8後端

3.4 應用程序解決方案 8

4 已解密登陸請求8

4.1 已解密登陸請求概述 8

4.2 安全風險及緣由分析 8

4.3 AppScan掃描建議 9

4.4 應用程序解決方案 9

5 跨站點請求僞造11

5.1 跨站點請求僞造概述 11

5.2 安全風險及緣由分析 12

5.3 AppScan掃描建議 12

5.4 應用程序解決方案 12

6 不充分帳戶封鎖13

6.1 不充分帳戶封鎖概述 13

6.2 安全風險及緣由分析 13

6.3 AppScan掃描建議 13

6.4 應用程序解決方案 13

7 啓用不安全HTTP方法14

7.1 啓用不安全HTTP方法概述 14

7.2 安全風險及緣由分析 14

7.3 AppScan掃描建議 15

7.4 應用程序解決方案 15

8 HTTP註釋敏感信息16

8.1 HTTP註釋敏感信息概述 16

8.2 安全風險及緣由分析 16

8.3 AppScan掃描建議 16

8.4 應用程序解決方案 16

9 發現電子郵件地址模式16

9.1 發現電子郵件地址模式概述 16

9.2 安全風險及緣由分析 17

9.3 AppScan掃描建議 17

9.4 應用程序解決方案 17

10 經過框架釣魚20

10.1 經過框架釣魚概述 20

10.2 安全風險及緣由分析 20

10.3 AppScan掃描建議 20

10.4 應用程序解決方案 23

11 檢查到文件替代版本25

11.1 檢查到文件替代版本概述 25

11.2 安全風險及緣由分析 25

11.3 AppScan掃描建議 25

11.4 應用程序解決方案 26

1 Web安全介紹

　目前不少業務都依賴於互聯網，例如說網上銀行、網絡購物、網遊等，不少惡意攻擊者出於不良的目的對Web 服務器進行攻擊，千方百計經過各類手段獲取他人的我的帳戶信息謀取利益。正是由於這樣，Web業務平臺最容易遭受攻擊。同時，對Web服務器的攻擊也能夠說是形形色色、種類繁多，常見的有掛馬、SQL注入、緩衝區溢出、嗅探、利用IIS等針對Webserver漏洞進行攻擊。

　　一方面，因爲TCP/IP的設計是沒有考慮安全問題的，這使得在網絡上傳輸的數據是沒有任何安全防禦的。攻擊者能夠利用系統漏洞形成系統進程緩衝區溢出，攻擊者可能得到或者提高本身在有漏洞的系統上的用戶權限來運行任意程序，甚至安裝和運行惡意代碼，竊取機密數據。而應用層面的軟件在開發過程當中也沒有過多考慮到安全的問題，這使得程序自己存在不少漏洞，諸如緩衝區溢出、SQL注入等等流行的應用層攻擊，這些均屬於在軟件研發過程當中疏忽了對安全的考慮所致。

另外一方面，用戶對某些隱祕的東西帶有強烈的好奇心，一些利用木馬或病毒程序進行攻擊的攻擊者，每每就利用了用戶的這種好奇心理，將木馬或病毒程序捆綁在一些豔麗的圖片、音視頻及免費軟件等文件中，而後把這些文件置於某些網站當中，再引誘用戶去單擊或下載運行。或者經過電子郵件附件和QQ、MSN等即時聊天軟件，將這些捆綁了木馬或病毒的文件發送給用戶，利用用戶的好奇心理引誘用戶打開或運行這些文件、

2 SQL注入、盲注

2.1 SQL注入、盲注概述

Web 應用程序一般在後端使用數據庫，以與企業數據倉庫交互。查詢數據庫事實上的標準語言是 SQL（各大數據庫供應商都有本身的不一樣版本）。Web 應用程序一般會獲取用戶輸入（取自 HTTP 請求），將它併入 SQL 查詢中，而後發送到後端數據庫。接着應用程序便處理查詢結果，有時會向用戶顯示結果。
若是應用程序對用戶（攻擊者）的輸入處理不夠當心，攻擊者即可以利用這種操做方式。在此狀況下，攻擊者能夠注入惡意的數據，當該數據併入 SQL 查詢中時，就將查詢的原始語法更改得面目全非。例如，若是應用程序使用用戶的輸入（如用戶名和密碼）來查詢用戶賬戶的數據庫表，以認證用戶，而攻擊者可以將惡意數據注入查詢的用戶名部分（和/或密碼部分），查詢即可能更改爲徹底不一樣的數據複製查詢，多是修改數據庫的查詢，或在數據庫服務器上運行 Shell 命令的查詢。

2.2 安全風險及緣由

高風險漏洞，攻擊者可能會查看、修改或刪除數據庫條目和表

緣由：未對用戶輸入正確執行危險字符清理

2.3 AppScan掃描建議

若干問題的補救方法在於對用戶輸入進行清理。
經過驗證用戶輸入未包含危險字符，即可能防止惡意的用戶致使應用程序執行計劃外的任務，例如：啓動任意 SQL 查詢、嵌入將在客戶端執行的 Javascript 代碼、運行各類操做系統命令，等等。
建議過濾出全部如下字符：

[1] |（豎線符號）

[2] & （& 符號）

[3];（分號）

[4] $（美圓符號）

[5] %（百分比符號）

[6] @（at 符號）

[7] '（單引號）

[8] "（引號）

[9] \'（反斜槓轉義單引號）

[10] \"（反斜槓轉義引號）

[11] <>（尖括號）

[12] ()（括號）

[13] +（加號）

[14] CR（回車符，ASCII 0x0d）

[15] LF（換行，ASCII 0x0a）

[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（回車符，ASCII 0x0d）

[2] LF（換行，ASCII 0x0a）遠程命令執行：清理輸入以排除對執行操做系統命令有意義的符號，例如：

[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（回車符，ASCII 0x0d）

[2] LF（換行，ASCII 0x0a）記錄僞造：

應該過濾出特殊記錄字符：

[1] CR（回車符，ASCII 0x0d）

[2] LF（換行，ASCII 0x0a）

[3] BS（退格，ASCII 0x08）

ORM 注入：
A. 確保用戶輸入的值和類型（如 Integer、Date 等）有效，且符合應用程序預期。
B. 利用存儲過程，將數據訪問抽象化，讓用戶不直接訪問表或視圖。
C. 使用參數化查詢 API
D. 清理輸入以排除上下文更改符號，例如： (*)：

[1] '（單引號）

[2] "（引號）

[3] \'（反斜線轉義單引號）

[4] \"（反斜槓轉義引號）

[5] )（結束括號）

[6] ;（分號）

2.4 應用程序解決方案

1、咱們爲了調試方便，在頁面上會拋出數據庫異常信息，若是入侵工具獲取了這些信息，就能夠獲取系統的一些配置信息，如web系統框架、採用的數據庫等，從而找出系統漏洞。因此不要在頁面上拋出異常的詳細信息，這些信息對客戶並無用，只是方便技術人員調試罷了，處理方法是在異常處理頁面把打印異常代碼刪除便可；

2、新建一個過濾器，經過過濾器過濾SQL注入特殊字符，配置成功後，重啓服務，用Appsan工具掃描，漏洞獲得解決，經過過濾器能夠解決SQL注入、跨站點腳本編制及經過框架釣魚等問題，具體實現方式以下：

1、在web.xml文件中配置過濾器

<filter-mapping>

<filter-name>requestEncodingFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

<filter-name>InjectFilter</filter-name>

<filter-class>com.sitech.ismp.util.context.InjectFilter</filter-class>

</filter>

2、過濾器過濾代碼

public class InjectFilter extends IsmpServletFilter {

private String failPage = "/loginout.jsp";//發生注入時，跳轉頁面

public void doFilter(ServletRequest request,ServletResponse response,

FilterChain filterchain)throws IOException, ServletException {

//判斷是否有注入攻擊字符

HttpServletRequest req = (HttpServletRequest) request;

String inj = injectInput(req);

if (!inj.equals("")) {

request.getRequestDispatcher(failPage).forward(request, response);

return;

} else {

// 傳遞控制到下一個過濾器

filterchain.doFilter(request, response);

}

/**

* 判斷request中是否含有注入攻擊字符

* @param request

* @return

public String 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("")) {

return inj;

}

return inj;

}

/**

* 判斷字符串中是否含有注入攻擊字符

* @param str

* @return

public String 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 "";

}

3 會話標識未更新

3.1 會話標識未更新概述

「會話固定」是一種攻擊技術，會強制用戶的會話標識變成顯式值。固定會話標識值的技術有許多種，會隨着目標 Web 站點的功能而不一樣。從利用「跨站點腳本編制」到向 Web 站點密集發出先前生成的 HTTP 請求，都在這些技術範圍內。用戶的會話標識固定以後，攻擊者會等待用戶登陸，而後利用預約義的會話標識值來假定用戶的聯機身份。
通常而言，對於標識值的會話管理系統有兩種類型。第一種類型是「寬容」系統，可以讓 Web 瀏覽器指定任何標識。第二種類型是「嚴格」系統，只接受服務器端生成的值。當使用寬容系統時，不須要聯繫 Web 站點，即可以維護任何會話標識。在嚴格系統中，攻擊者須要維護「陷阱會話」而且必須按期聯繫 Web 站點，才能防止閒置超時。對於會話固定，假若沒有活動保護，使用會話來識別已認證的用戶的任何 Web 站點均可能受到攻擊。使用會話標識的 Web 站點一般都是基於 cookie 的站點，但也會使用 URL 和隱藏的表單字段。不幸的是，基於 cookie 的會話最容易受到攻擊。目前已識別的大多數攻擊方法都是針對 cookie 的固定。相對於在用戶登陸 Web 站點以後，再竊取用戶的會話標識，會話固定提供的機會多得多。
在用戶登陸以前，攻擊的活動部分便已啓動。
會話固定攻擊過程一般由三個步驟組成：
1) 安裝會話
攻擊者針對目標 Web 站點設下「陷阱會話」，並獲取這個會話的標識，攻擊者也能夠選擇攻擊中所用的任意會話標識。在某些狀況下，必須反覆聯繫 Web 站點，才能維護肯定好的陷阱會話值。
2) 固定會話
攻擊者將陷阱會話值引進用戶的瀏覽器中，固定用戶的會話標識。
3) 進入會話
用戶登陸目標 Web 站點以後，當使用固定會話標識值時，攻擊者即可加以接管。」

修改

對於這類問題解決方案爲在用戶進入登陸頁面時清空session讓cookie過時

request.getSession(true).invalidate();//清空session

Cookie cookie = request.getCookies()[0];//獲取cookie

cookie.setMaxAge(0);//讓cookie過時

另一種方式利用JSP的一些特性，不讓登陸頁面產生Session

<% page session=」false」 %>

3.2 安全風險及緣由分析

高風險漏洞，可能會竊取或操縱客戶會話和 cookie，它們可能用於模仿合法用戶，從而使黑客可以以該用戶身份查看或變動用戶記錄以及執行事務

緣由：Web 應用程序編程或配置不安全

3.3 AppScan掃描建議

始終生成新的會話，供用戶成功認證時登陸。防止用戶操縱會話標識。
請勿接受用戶瀏覽器登陸時所提供的會話標識

3.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相關人員進行協調解決，根本沒有很是瞭解該產品技術人員支持，只是一個剛入職的同事在配合測試。調試了一週時間仍不能解決，最後只能做爲一個遺留問題擱置。公司一直在向產品化轉變，可是自身的產品維護、升級、管理仍然須要改進。

4 已解密登陸請求

4.1 已解密登陸請求概述

在應用程序測試過程當中，檢測到將未加密的登陸請求發送到服務器。因爲登陸過程所用的部分輸入字段（例如：用戶名、密碼、電子郵件地址、社會保險號碼，等等）是我的敏感信息，建議經過加密鏈接（如 SSL）將其發送到服務器。任何以明文傳給服務器的信息均可能被竊，稍後可用來電子欺騙身份或假裝用戶。此外，若干隱私權法規指出，用戶憑證之類的敏感信息一概以加密方式傳給網站。

4.2 安全風險及緣由分析

安全風險中，可能會竊取諸如用戶名和密碼等未經加密即發送了的用戶登陸信息

緣由：諸如用戶名、密碼和信用卡號之類的敏感輸入字段未經加密即進行了傳

遞

4.3 AppScan掃描建議

1. 確保全部登陸請求都以加密方式發送到服務器。
2. 請確保敏感信息，例如：

- 用戶名

- 密碼

- 社會保險號碼

- 信用卡號碼

- 駕照號碼

- 電子郵件地址

- 電話號碼

- 郵政編碼

一概以加密方式傳給服務器。

4.4 應用程序解決方案

已解密的登陸請求，要求就是數據要加密傳輸。最簡單有效的解決方式採用SSL加密協議傳輸，可是因爲EMA服務管理平臺業務的特殊性，採用SSL加密方式對現有的業務影響太大，因此最終沒有采用此種方式解決該問題，但我的在進行測試過程當中也嘗試在tomcat和jboss下SSL方式配置，寫下來供參考。

Jboss內核也是tomcat，因此二者配置基本都是同樣，都是在生成證書文件後，在service.xml 進行配置：

進入到cmd 進入到jdk bin目錄下執行keytool -genkey -alias tomcat -keyalg RSA -keystore webspeed.keystore 生成證書
在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添加配置。

<security-constraint>

<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>

<auth-method>CLIENT-CERT</auth-method>

<realm-name>Client Cert Users-only Area</realm-name>

</login-config>

應注意，因爲項目的一些組件沒法經過https，所以url-pattern字段只對.jsp和.action進行了限制，若是不作特定限制，則系統默認是所有使用https傳輸。並且上述設置一旦在某個工程中出現，那麼當前tomcat將全局採用這一配置。

5 跨站點請求僞造

5.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 攻擊會帶有嚴重的後果，這取決於其餘站點行爲。例如，若是站點保留了用戶操做的歷史記錄（例如搜索歷史記錄），那麼攻擊者將可以在易受攻擊的站點上查看受害者以前執行的操做。

5.2 安全風險及緣由分析

安全風險中，可能會竊取或操縱客戶會話和 cookie，它們可能用於模仿合法用戶，從而使黑客可以以該用戶身份查看或變動用戶記錄以及執行事務

緣由：應用程序使用的認證方法不充分

5.3 AppScan掃描建議

若是要避免 CSRF 攻擊，每一個請求都應該包含惟一標識，它是攻擊者所沒法猜想的參數。建議的選項之一是添加取自會話 cookie 的會話標識，使它成爲一個參數。服務器必須檢查這個參數是否符合會話 cookie，若不符合，便廢棄請求。攻擊者沒法猜想這個參數的緣由是應用於 cookie 的「同源策略」，所以，攻擊者沒法僞造一個虛假的請求，讓服務器誤覺得真。攻擊者難以猜想且沒法訪問的任何祕密（也就是沒法從其餘域訪問），均可用來替換會話標識。這能夠防止攻擊者設計看似有效的請求。

5.4 應用程序解決方案

6 不充分帳戶封鎖

6.1 不充分帳戶封鎖概述

蠻力攻擊是指惡意用戶發送大量可能的密碼和/或用戶名以訪問應用程序的嘗試。因爲該技術包含大量登陸嘗試，未限制容許的錯誤登陸請求次數的應用程序很容易遭到這類攻擊。所以，強烈建議您對賬戶限制容許的錯誤登陸嘗試次數，超過該次數，便鎖定該賬戶。樣本利用：
下列請求說明密碼猜想請求：

http://site/login.asp?username=EXISTING_USERNAME&password=GUESSED_PASSWORD 若是站點在若干次錯誤嘗試以後並不鎖定測試的賬戶，攻擊者最終可能會發現賬戶密碼，並使用它來假冒賬戶的合法用戶。

6.2 安全風險及緣由分析

安全風險高，可能會升級用戶特權並經過 Web 應用程序獲取管理許可權

緣由：Web 應用程序編程或配置不安全

6.3 AppScan掃描建議

請肯定容許的登陸嘗試次數（一般是 3-5 次），確保超出容許的嘗試次數以後，便鎖定賬戶。爲了不真正的用戶因賬戶被鎖定而致電支持人員的麻煩，能夠僅臨時性暫掛賬戶活動，並在特定時間段以後啓用賬戶。賬戶鎖定大約 10 分鐘，一般便足以阻止蠻力攻擊。

6.4 應用程序解決方案

根據掃描建議，web應用程序設定容許登陸嘗試次數，登陸連續失敗超過設定次數，就鎖定用戶，失敗次數靈活配置。

在用戶登陸時進行驗證：

if (!encrypter.encrypt(userPassword).equalsIgnoreCase(

user.getLOGIN_PASSWD() == null ? "" : user.getLOGIN_PASSWD()))

{

//更新此用戶登陸失敗次數

this.updateLoginFailTimes(userCode);

//若是用戶連續登陸失敗次數超過配置值則將其鎖定

int loginLockTimes=this.getLoginLockTimes();

if(this.getLoginFailTimes(userCode)>=loginLockTimes){

this.lockUser(userCode);

}

throw new MySecurityException("密碼不正確! 用戶:" + userCode);

}

7 啓用不安全HTTP方法

7.1 啓用不安全HTTP方法概述

彷佛 Web 服務器配置成容許下列其中一個（或多個）HTTP 方法（動詞）：
- DELETE
- SEARCH
- COPY
- MOVE
- PROPFIND
- PROPPATCH
- MKCOL
- LOCK
- UNLOCK

這些方法可能表示在服務器上啓用了 WebDAV，可能容許未受權的用戶對其進行利用。

7.2 安全風險及緣由分析

安全風險中，可能會在 Web 服務器上上載、修改或刪除 Web 頁面、腳本和文件

緣由：Web 服務器或應用程序服務器是以不安全的方式配置的

7.3 AppScan掃描建議

若是服務器不須要支持 WebDAV，請務必禁用它，或禁止沒必要要的 HTTP 方法（動詞）。

7.4 應用程序解決方案

修改web工程中web.xml,增長安全配置信息，禁用沒必要要HTTP方法

<security-constraint>

<web-resource-collection>

<web-resource-name>HtmlAdaptor</web-resource-name>

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

8 HTTP註釋敏感信息

8.1 HTTP註釋敏感信息概述

不少 Web 應用程序程序員使用 HTML 註釋，以在須要時幫助調試應用程序。儘管添加常規註釋有助於調試應用程序，但一些程序員每每會遺留重要數據（例如：與 Web 應用程序相關的文件名、舊的連接或原非供用戶瀏覽的連接、舊的代碼片斷等）。

8.2 安全風險及緣由分析

安全風險低，能會收集有關 Web 應用程序的敏感信息，如用戶名、密碼、機器名和/或敏感文件位置

緣由：程序員在 Web 頁面上留下調試信息

8.3 AppScan掃描建議

[1] 請勿在 HTML 註釋中遺留任何重要信息（如文件名或文件路徑）。
[2] 從生產站點註釋中除去之前（或將來）站點連接的跟蹤信息。
[3] 避免在 HTML 註釋中放置敏感信息。
[4] 確保 HTML 註釋不包括源代碼片斷。
[5] 確保程序員沒有遺留重要信息。

。

8.4 應用程序解決方案

雖然這個漏洞爲低級別漏洞，但電信方也是要求必須修復，要修改此漏洞須要檢查工程中的每個jsp頁面，工做量仍是挺大。因此在後續開發過程當中註釋儘可能寫英文註釋，儘可能不要遺留敏感註釋信息在jsp代碼中，養成良好的編碼習慣纔是解決問題根本。

9 發現電子郵件地址模式

9.1 發現電子郵件地址模式概述

Spambot 搜尋因特網站點，開始查找電子郵件地址來構建發送自發電子郵件（垃圾郵件）的郵件列表。 AppScan 檢測到含有一或多個電子郵件地址的響應，可供利用以發送垃圾郵件。並且，找到的電子郵件地址也多是專用電子郵件地址，對於通常大衆應是不可訪問的。

9.2 安全風險及緣由分析

安全風險低，能會收集有關 Web 應用程序的敏感信息，如用戶名、密碼、機器名和/或敏感文件位置

緣由：Web 應用程序編程或配置不安全

9.3 AppScan掃描建議

從 Web 站點中除去任何電子郵件地址，使惡意的用戶無從利用。

9.4 應用程序解決方案

根據掃描建議刪除註釋中出現email地址信息，若是頁面中要顯示mail地址轉爲圖片形式展現。如：ema服務管理平臺首頁須要展現客戶聯繫方式，而且聯繫方式、email等信息，這些信息用戶都是能夠自行修改的，由於包含了email地址，因此聯繫方式就轉爲圖片形式：

<%@ page language="java" contentType="text/html; charset=gb2312"%>

<%@ include file="/common/taglib.jsp" %>

<%@ include file="/common/chart.jsp" %>

<%@ page import="java.util.List,java.util.*,java.awt.*,java.awt.image.*,com.sun.image.codec.jpeg.*,java.util.*" %>

<%@ page import="com.sitech.ismp.informationService.publish.dao.TB_SYS_SUPPORT_STAFFDao" %>

<html:html locale="true">

<head>

<%@ include file="/common/link.jsp" %>

<%@ page import="com.sitech.ismp.util.context.CommUtil" %>

</head>

<body>

<html:form action="/homeContactShow" method="post" styleId="theForm">

<bean:define id="theForm" name="supportStaffForm"/>

<div>

<TBODY>

<tr>

<td class="tableheadbg">運營中心聯繫方式</td>

</tr>

<tr>

List typeList = (List)request.getAttribute("typeList");

out.clear();

out = pageContext.pushBody();

response.setContentType("image/jpeg");

response.addHeader("pragma","NO-cache");

response.addHeader("Cache-Control","no-cache");

response.addDateHeader("Expries",0);

int rowheight=20;

int width=135,height=rowheight*typeList.size();

TB_SYS_SUPPORT_STAFFDao dao= new TB_SYS_SUPPORT_STAFFDao();

String ty= "";

String mob="";

for(int i=0;i<typeList.size();i++){

HashMap hm=(HashMap)typeList.get(i);

ty=(String)hm.get("TYPE_ID");

List sta =(List)dao.findSupportStaffByTypeId(ty);

for(int k=0;k<sta.size();k++){

HashMap map = (HashMap)sta.get(k);

mob = (String)map.get("MOBILE");

height+=3*rowheight;

if(mob!=null)height+=rowheight;

}

BufferedImage image = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB);

Graphics g = image.getGraphics();

g.setColor(Color.white);

g.fillRect(0, 0, width, height);

g.setColor(Color.BLUE);

Font font=new Font("宋體",Font.PLAIN,13);

g.setFont(font);

int row=0;

String typeid = "";

String typename="";

String name = "";

String tel="";

String mail = "";

String mobile="";

for(int i=0;i<typeList.size();i++){

HashMap hm=(HashMap)typeList.get(i);

typeid=(String)hm.get("TYPE_ID");

typename=(String)hm.get("TYPE_NAME");

row++;

g.drawString(typename,0,(row-1)*rowheight+10);

List staffs =(List)dao.findSupportStaffByTypeId(typeid);

for(int k=0;k<staffs.size();k++){

HashMap map = (HashMap)staffs.get(k);

name = (String)map.get("NAME");

tel = (String)map.get("TEL");

mail = (String)map.get("MAIL");

mobile = (String)map.get("MOBILE");

row++;

g.drawString(name+":"+tel,0,(row-1)*rowheight+10);

row++;

g.drawString(mail,0,(row-1)*rowheight+10);

if(mobile !=null){

row++;

g.drawString(mail,0,(row-1)*rowheight+10);

}

g.dispose();

ServletOutputStream outStream = response.getOutputStream();

JPEGImageEncoder encoder =JPEGCodec.createJPEGEncoder(outStream);

encoder.encode(image);

outStream.close();

</td>

</tr>

</TBODY>

</table>

</div>

</DIV>

</html:form>

</body>

</html:html>

10 經過框架釣魚

10.1 經過框架釣魚概述

網絡釣魚是一個通稱，表明試圖欺騙用戶交出私人信息，以便電子欺騙身份。
攻擊者有可能注入 frame 或 iframe 標記，其中含有相似受攻擊之網站的惡意屬性。不當心的用戶有可能瀏覽它，但並不知道他正在離開原始網站，衝浪到惡意的網站。以後，攻擊者即可以誘惑用戶從新登陸，而後獲取他的登陸憑證。
僞造的網站嵌入在原始網站中，這個狀況對攻擊者有幫助，由於他的網絡釣魚企圖會披上更可信賴的外表。
樣本利用：
若是參數值未經適當清理，便反映在響應中，下列請求：http://[SERVER]/script.aspx?parameter=<frame name="evil" src="www.evil.com">
會使響應含有通往這個邪惡站點的框架。

10.2 安全風險及緣由分析

安全風險中，可能會勸說初級用戶提供諸如用戶名、密碼、信用卡號、社會保險號等敏感信息

緣由：對用戶輸入正確執行危險字符清理

10.3 AppScan掃描建議

[1] |（豎線符號）

[2] & （& 符號）

[3];（分號）

[4] $（美圓符號）

[5] %（百分比符號）

[6] @（at 符號）

[7] '（單引號）

[8] "（引號）

[9] \'（反斜槓轉義單引號）

[10] \"（反斜槓轉義引號）

[11] <>（尖括號）

[12] ()（括號）

[13] +（加號）

[14] CR（回車符，ASCII 0x0d）

[15] LF（換行，ASCII 0x0a）

[16] ,（逗號）

[17] \（反斜槓）

[1] '（單引號）

[2] "（引號）

[3] \'（反斜線轉義單引號）

[4] \"（反斜槓轉義引號）

[5] )（結束括號）

[6] ;（分號）

跨站點腳本編制：
A. 清理用戶輸入，並過濾出 JavaScript 代碼。咱們建議您過濾下列字符：

[1] <>（尖括號）

[2] "（引號）

[3] '（單引號）

[4] %（百分比符號）

[5] ;（分號）

[6] ()（括號）

[7] &（& 符號）

[8] +（加號）

[1] CR（回車符，ASCII 0x0d）

[2] LF（換行，ASCII 0x0a）遠程命令執行：清理輸入以排除對執行操做系統命令有意義的符號，例如：

[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（回車符，ASCII 0x0d）

[2] LF（換行，ASCII 0x0a）記錄僞造：

應該過濾出特殊記錄字符：

[1] CR（回車符，ASCII 0x0d）

[2] LF（換行，ASCII 0x0a）

[3] BS（退格，ASCII 0x08）

[1] '（單引號）

[2] "（引號）

[3] \'（反斜線轉義單引號）

[4] \"（反斜槓轉義引號）

[5] )（結束括號）

[6] ;（分號）

(*) 這適用於 SQL。高級查詢語言可能須要不一樣的清理機制。

。

10.4 應用程序解決方案

新建一個過濾器，經過過濾器過濾SQL注入特殊字符，配置成功後，重啓服務，用Appsan工具掃描，漏洞獲得解決，具體實現方式以下：

1、在web.xml文件中配置過濾器

<filter-mapping>

<filter-name>requestEncodingFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

<filter-name>InjectFilter</filter-name>

<filter-class>com.sitech.ismp.util.context.InjectFilter</filter-class>

</filter>

2、過濾器過濾代碼

public class InjectFilter extends IsmpServletFilter {

private String failPage = "/loginout.jsp";//發生注入時，跳轉頁面

public void doFilter(ServletRequest request,ServletResponse response,

FilterChain filterchain)throws IOException, ServletException {

//判斷是否有注入攻擊字符

HttpServletRequest req = (HttpServletRequest) request;

String inj = injectInput(req);

if (!inj.equals("")) {

request.getRequestDispatcher(failPage).forward(request, response);

return;

} else {

// 傳遞控制到下一個過濾器

filterchain.doFilter(request, response);

}

/**

* 判斷request中是否含有注入攻擊字符

* @param request

* @return

public String 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("")) {

return inj;

}

return inj;

}

/**

* 判斷字符串中是否含有注入攻擊字符

* @param str

* @return

public String 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 "";

}

11 檢查到文件替代版本

11.1 檢查到文件替代版本概述

開發者每每會將腳本文件的備用版本留在虛擬根目錄中，例如，開頭是「Copy of」、「_」、「.」、「~」和「Old」的文件。當請求這些文件時，它們會顯示在瀏覽器中。這些文件可能包含現有腳本的備用版本或舊版本。
請務必從虛擬目錄下除去這些文件，由於它們可能包含用於調試的敏感信息，也可能指向經過當前腳本不可查看的站點區域。

11.2 安全風險及緣由分析

安全風險低，能會收集有關 Web 應用程序的敏感信息，如用戶名、密碼、機器名和/或敏感文件位置

緣由：在生產環境中留下臨時文件

11.3 AppScan掃描建議

請勿將文件的備用版本存放在虛擬 Web 服務器的根目錄下。相反地，當更新站點時，請將文件刪除或移動到虛擬根目錄之外的目錄、在這個目錄中編輯文件，而後再將文件移動（或拷貝）回虛擬根目錄。請確保，在虛擬根目錄下，只有實際在使用的文件。

11.4 應用程序解決方案

這個問題反映出咱們編碼習慣和文檔版本管理方面的問題，從咱們工程中，能夠看到歷史遺留的一些「copy of」、」_」開頭jsp和java文件，甚至有些正式的文件也有命名成例如：a1.jsp,a2.jsp的，這些明顯不符合文件的命名規範，也會給系統帶來一些潛在漏洞，因此開發人員必定要注意命名規範性和歷史版本信息清除，養成良好的編碼習慣。

寫在最後：這是最近從過往文件存檔裏面找到的一份12年的文檔，是否是本身寫的，也記不清了。share出來

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。