常見安全漏洞及整改建議[備忘]

引用：http://www.shangxueba.com/jingyan/1603262.html

1. HTML表單沒有CSRF保護

1.1 問題描述：

 

    CSRF（Cross-site request forgery），中文名稱：跨站請求偽造，也被稱為：one click attack/session riding，縮寫為：CSRF/XSRF。

    CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求。CSRF能夠做的事情包括：以你名義發送郵件，發消息，盜取你的賬號，甚至於購買商品，虛擬貨幣轉賬……造成的問題包括：個人隱私泄露以及財產安全。

1.2 整改建議：

 

    CSRF的防御可以從服務端和客戶端兩方面着手，防御效果是從服務端着手效果比較好，現在一般的CSRF防御也都在服務端進行。有以下三種方法：

    (1).Cookie Hashing(所有表單都包含同一個偽隨機值)：

    (2).驗證碼

    (3).One-Time Tokens(不同的表單包含一個不同的偽隨機值)

1.3 案例：

 

    1.服務端進行CSRF防御

    服務端的CSRF方式方法很多樣，但總的思想都是一致的，就是在客戶端頁面增加偽隨機數。

1.3.1 Cookie Hashing(所有表單都包含同一個偽隨機值)：

 

    這可能是最簡單的解決方案了，因為攻擊者不能獲得第三方的Cookie(理論上)，所以表單中的數據也就構造失敗.

   

    //構造加密的Cookie信息

    $value = “DefenseSCRF”;

    setcookie(”cookie”, $value, time()+3600);

    ?>

    在表單里增加Hash值，以認證這確實是用戶發送的請求。

   

    $hash = md5($_COOKIE['cookie']);

    ?>

   

    

    

    ”>

    

   

    然后在服務器端進行Hash值驗證

   

    if(isset($_POST['check'])) {

    $hash = md5($_COOKIE['cookie']);

    if($_POST['check'] == $hash) {

    doJob();

    } else {

    //…

    }

    } else {

    //…

    }

    ?>

    這個方法已經可以杜絕99%的CSRF攻擊了，那還有1%….由於用戶的Cookie很容易由於網站的XSS漏洞而被盜取，這就另外的1%。一般的攻擊者看到有需要算Hash值，基本都會放棄了，某些除外，所以如果需要100%的杜絕，這個不是最好的方法。

1.3.2 驗證碼

 

    這個方案的思路是：每次的用戶提交都需要用戶在表單中填寫一個圖片上的隨機字符串，這個方案可以完全解決CSRF，但在易用性方面似乎不是太好，還有是驗證碼圖片的使用涉及了一個被稱為MHTML的Bug，可能在某些版本的微軟IE中受影響。

1.3.3 One-Time Tokens(不同的表單包含一個不同的偽隨機值)

 

在實現One-Time Tokens時，需要注意一點：就是“並行會話的兼容”。如果用戶在一個站點上同時打開了兩個不同的表單，CSRF保護措施不應該影響到他對任何表單的提交。考慮一下如果每次表單被裝入時站點生成一個偽隨機值來覆蓋以前的偽隨機值將會發生什么情況：用戶只能成功地提交他最后打開的表單，因為所有其他的表單都含有非法的偽隨機值。必須小心操作以確保CSRF保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器窗口瀏覽一個站點。

    以下實現:

    1).先是令牌生成函數(gen_token())：

   

    function gen_token() {

    //這是貪方便，實際上單使用Rand()得出的隨機數作為令牌，也是不安全的。

    //這個可以參考寫的Findbugs筆記中的《Randomobject created and used only once》

    $token = md5(uniqid(rand(), true));

    return $token;

    }

    2).然后是Session令牌生成函數(gen_stoken())：

   

    function gen_stoken() {

    $pToken = “”;

    if($_SESSION[STOKEN_NAME] == $pToken){

    //沒有值，賦新值

    $_SESSION[STOKEN_NAME] = gen_token();

    }

    else{

    //繼續使用舊的值

    }

    }

    ?>

    3).WEB表單生成隱藏輸入域的函數：

   

    function gen_input() {

    gen_stoken();

    echo “

    value=\”” . $_SESSION[STOKEN_NAME] . “\”> “;

    }

    ?>

    4).WEB表單結構：

   

    session_start();

    include(”functions.php”);

    ?>

   

    

    

   

    

   

    5).服務端核對令牌：

2. jQuery 跨站腳本漏洞

2.1 問題描述

 

    jQuery是繼prototype之后又一個優秀的Javascrīpt框架。

    jQuery 1.6.3之前版本中存在跨站腳本漏洞。當使用location.hash選擇元素時，通過特制的標簽，遠程攻擊者利用該漏洞注入任意web腳本或HTML。

2.2 整改方法

 

    目前廠商已經發布了升級補丁以修復此安全問題，補丁獲取鏈接：

    http://www.ubuntu.com/usn/USN-1722-1/

2.3 整改案例

 

    升級jQuery版本。

3. 跨站腳本編制

3.1 問題描述：

 

    跨站腳本攻擊是通過在網頁中加入惡意代碼，當訪問者瀏覽網頁時惡意代碼會被執行或者通過給管理員發信息的方式誘使管理員瀏覽，從而獲得管理員權限，控制整個網站。攻擊者利用跨站請求偽造能夠輕松地強迫用戶的瀏覽器發出非故意的HTTP請求，如詐騙性的電匯請求、修改口令和下載非法的內容等請求。

    風險等級：高

    風險范圍：

    任何存在輸入/輸出方法（包括GET與POST）的頁面皆可能存在惡意符號輸入缺陷，主要影響應用包括留言板、在線通訊信息、文章發布頁面等。

3.2 整改建議：

 

    對用戶輸入的參數執行嚴格檢測：

    1、對產生漏洞模塊的傳入參數進行有效性檢測。int類型的只允許0-9的整型數字；string等字符類型的只允許(1-9，a-z，A-Z)的英文字母；

    2、當客戶端輸入限定值意外的字符后，立即轉向自定義的錯誤頁，而不能使用服務器默認的錯誤輸出方式；

    3、對穿入參數進行危險字符過濾，禁止('、"、+、%、&、<>、（）、;、,.等)特殊字符的傳入。

    4.web.config配置文件增加節點：<pages validateRequest="true" enableSessionState="true">

    5.關於存在Rich Text Editor的頁面應該如何處理?  引用：http://www.knowsky.com/887593.html


　　如果頁面有富文本編輯器的控件的，那么必然會導致有類的HTML標簽提交回來。在這種情況下，我們不得不將validateRequest="false"。那么安全性怎么處理?如何在這種情況下最大限度的預防跨站腳本攻擊呢?


　　根據微軟的建議，我們應該采取安全上稱為“默認禁止，顯式允許”的策略。


　　首先，我們將輸入字符串用 HttpUtility.HtmlEncode()來編碼，將其中的HTML標簽徹底禁止。


　　然后，我們再對我們所感興趣的、並且是安全標簽，通過Replace()進行替換。比如，我們希望有""標簽，那么我們就將""顯式的替換回""。


　　示例代碼如下：


以下是引用片段：
void submitBtn_Click(object sender, EventArgs e)
...{
// 將輸入字符串編碼，這樣所有的HTML標簽都失效了。
StringBuilder sb = new StringBuilder(
HttpUtility.HtmlEncode(htmlInputTxt.Text));
// 然后我們選擇性的允許<b> 和 <i>
sb.Replace("&lt;b&gt;", "<b>");
sb.Replace("&lt;/b&gt;", ""); 
sb.Replace("&lt;i&gt;", "<i>");
sb.Replace("&lt;/i&gt;", "");
Response.Write(sb.ToString());
}

 

使用了HttpUtility.HtmlEncode編碼輸入后，可以使用HttpUtility.HtmlDecode進行反編碼顯示

3.3 案例：

 

    加固范例（一）：

    /*將login.jsp中[String u =request.getParameter("u");]替換為如下內容：*/

    String u = request.getParameter("u");

    u = u.replace ('＜','_');

    u = u.replace ('＞','_');

    u = u.replace('"','_');

    u = u.replace('\'','_');

    u = u.replace ('%','_');

    u = u.replace(';','_');

    u = u.replace('(','_');

    u = u.replace(')','_');

    u = u.replace('&','_');

    u = u.replace('+','_');

    加固范例（二）：

    /*更積極的方式是利用正則表達式只允許輸入指定的字符：*/

    /*在[String u = request.getParameter("u");]后代入以下isValidInput函數作辨別*/

    public boolean isValidInput(Stringstr)

    {

    if(str.matches("[a-z0-9]+"))return true;

    else return false;

    }

4. URL重定向釣魚

4.1 3.1問題描述：

 

    通過構建URL，攻擊者可以使用戶重定向到任意URL，利用這個漏洞可以誘使用戶訪問某個頁面，掛馬、密碼記錄、下載任意文件等，常被用來釣魚。

4.2 3.2整改建議：

 

    對輸入參數進行做處理，建議過濾出所有以下字符：

    [1] |（豎線符號）

    [2] & （& 符號）

    [3];（分號）

    [4] $（美元符號）

    [5] %（百分比符號）

    [6] @（at 符號）

    [7] '（單引號）

    [8] "（引號）

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

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

    [11] <>（尖括號）

    [12] ()（括號）

    [13] +（加號）

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

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

    [16] ,（逗號）

    [17] \（反斜杠）

4.3 3.3案例：

 

    對輸入參數進行做處理。

    加固范例（一）：

    /*將login.jsp中[String u = request.getParameter("u");]替換為如下內容：*/

    String u =request.getParameter("u");

    u = u.replace ('＜','_');

    u = u.replace ('＞','_');

    u = u.replace ('"','_');

    u = u.replace ('\'','_');

    u = u.replace ('%','_');

    u = u.replace (';','_');

    u = u.replace ('(','_');

    u = u.replace (')','_');

    u = u.replace ('&','_');

    u = u.replace ('+','_');

    加固范例（二）：

    /*更積極的方式是利用正則表達式只允許輸入指定的字符：*/

    /*在[String u = request.getParameter("u");]后代入以下isValidInput函數作辨別*/

    public boolean isValidInput(String str)

    {

    if(str.matches("[a-z0-9]+")) returntrue;

    else return false;

    }

5. 不安全存儲

5.1 問題描述

 

    不安全存儲，在頁面上顯示密碼。

5.2 整改建議

 

    加密密碼或不在頁面及源碼上顯示密碼。

5.3 案例

 

    一切涉及敏感信息讀寫操作的頁面，如登陸頁面、登陸處理頁面等。

    風險范例：

    /*Add_user.jsp*/

    String sql;

    sql="insert into user(username,password) values (" + Username + "," + Password +")";

    Statement sm = cn.createStatement();

    sm.executeUpdate(sql);

    sm.close();

    加固范例：

    /*在生成sql變量內容前加入對Password變量的加密處理：*/

    <%@ pageimport="java.security.*" %>

    <%@ pageimport="java.util.*" %>

    …

    public String byte2hex(byte[] b)//二行制轉字符串

    {

    Stringhs="";

    Stringstmp="";

    for(int n=0;n<b.length;n++)< p="">

    {

    stmp=(java.lang.Integer.toHexString(b[n]& 0XFF));

    if(stmp.length()==1) hs=hs+"0"+stmp;

    elsehs=hs+stmp;

    //if(n<b.length-1) hs="hs+":";

    }

    returnhs.toUpperCase();

    }

    …

    java.security.MessageDigestalg=java.security.MessageDigest.getInstance("SHA-256");

    alg.update(Password.getBytes());

    byte[] digest=alg.digest();

    Password=byte2hex(digest);

6. 錯誤的頁面信息

6.1 問題描述：

 

    錯誤/警告消息，可能會泄露敏感信息。

6.2 整改建議：

 

    在編碼階段開發者對敏感頁面缺乏授權保護，導致相關URL頁面敏感信息泄露。建議修改錯誤信息。

    一切敏感或需要權限方可瀏覽的頁面，包括：敏感信息中轉處理頁面、上傳頁面、管理平台頁面、用戶自管理頁面等。

6.3 案例：

 

    風險范例：

    /*風險范例為一切需要敏感但編碼階段沒有進行授權鑒別的頁面*/

    加固范例：

    if((session.getValue("UserName")==null)||(session.getValue("UserClass")==null)||(!session.getValue("UserClass").equals("系統管理員")))

    {

    response.sendRedirect("err.jsp?id=14");

    return;

    }

web.config配置文件增加節點：

<system.web>

   <customErrors mode="On" defaultRedirect="ErrorPage.aspx" redirectMode="ResponseRewrite">
</customErrors>

</System.web>

 

7. 已解密的登陸請求

7.1 問題描述：

 

    用戶名、密碼輸入字段未經加密即進行了傳遞。

7.2 整改建議：

 

    確保所有登錄請求都以https加密方式發送到服務器。

7.3 案例：

 

    方法一：配置SSL加密傳輸

    【概念理解】keystore 是一個密碼保護的文件，用來存儲密鑰和證書

    (1)生成一個keystore文件（包含證書），文件位置/usr/local/tomcat/conf/.keystore

    # cd /usr/local/jdk/bin/

    # ./keytool -genkey -alias tomcat -keyalg RSA -keystore/usr/local/tomcat/conf/.keystore

    輸入密碼、提供你的信息即可。如果不是用來“玩”的話，請如實的填寫自己以及單位的信息吧。

    【注意】它會在前后問你兩次密碼，第二次直接回車就行了，如果兩個密碼不一樣，將會出現java.io.IOException錯誤。詳情請見：[url]http://issues.apache.org/bugzilla/show_bug.cgi?id=38217[/url]

    (2)修改tomcat/conf/server.xml

    啟用這一段：

   

    maxThreads="150" scheme="https" secure="true"

    clientAuth="false"sslProtocol="TLS" />

    並修改為：

   

    maxThreads="150" scheme="https" secure="true"

    keystoreFile="/usr/local/tomcat/conf/.keystore"

    keystorePass="snailwarrior"

    clientAuth="false" sslProtocol="TLS" />

    (3)重啟Tomcat

    # /usr/local/tomcat/bin/shutdown.sh

    # /usr/local/tomcat/bin/startup.sh

    (4)防火牆開啟8443端口

    瀏覽器輸入：[url]https://192.168.32.50:8443/[/url]

    方法二：把text="password"這個用其他的代替，就可以解決已解密的登錄請求，僅共參考

   

• 密  碼：

      nkeypress="javascript：hiddenPass(event)"onkeyup="this.value=this.value.replace(/./g,'*');"/>

 

   

• <inputid="password" type="hidden" name="password">

 

   

 

    js代碼

    functionhiddenPass(e){

    e = e ? e : window.event;

    var kcode = e.which ? e.which : e.keyCode;

    var pass =document.getElementByIdx_x("password1");

    var j_pass = document.getElementByIdx_x("password");

    if(kcode!=8)

    {

    var keychar=String.fromCharCode(kcode);

    j_pass.value=j_pass.value+keychar;

    j_pass.value=j_pass.value.substring(0,pass.length);

    }

    }

    獲取密碼：document.getElementByIdx_x("password").value;

8. HTTP拒絕服務

8.1 問題描述

 

    HTTP存在DOS漏洞。

    如果遠程攻擊者使用發包工具向Apache服務器發送了不完整的HTTP請求，服務器會打開連接等待接受完整的頭，但如果發包工具不再繼續發送完整請求而是發送無效頭的話，就會一直保持打開的連接。這種攻擊所造成的影響很嚴重，因為攻擊者不需要發送很大的通訊就可以耗盡服務器上的可用連接。也就是說，即使低帶寬的用戶也可以攻擊大流量的服務器。

8.2 整改方法

 

    臨時解決方法：

    更改默認的TimeOut選項少於7000ms，或使用mod_limitipconn模塊限制單個IP地址的連接數。

    廠商補丁：

    Apache Group

    ------------

    目前廠商還沒有提供補丁或者升級程序，我們建議使用此軟件的用戶隨時關注廠商的主頁以獲取最新版本：http://www.apache.org

8.3 案例

 

    關於HTTP版本低漏洞信息，如下：

    1）.漏洞的描述

    http://www.venustech.com.cn/NewsInfo/124/17205.Html

    2）.TOMCAT官網說這個不是一個漏洞，沒有打算出補丁，只有緩解方法

    詳細可以看，

    http://tomcat.apache.org/security-6.html#Not_a_vulnerability_in_Tomcat

    查找 CVE-2012-5568 會看到官網說明。

    緩解方法

    通過server.xml內定義的連接器的connectionTimeout屬性，配置一個合適的超時時間。

    https://blogs.oracle.com/jyrivirkki/entry/web_server_7_meets_slowloris

    3）.但CVE 的漏洞還是所有版本也存在。下面是一個CVE的詳細信息地址，此頁面最后更新為2013-03-07，當時6.0.35為最新版本。

    http://www.cvedetails.com/cve-details.php?t=1&cve_id=CVE-2012-5568

    4）.公開的漏洞測試代碼

    http://ha.ckers.org/slowloris/slowloris.pl

9. 跨站點請求偽造

 

    同“1.HTML表單沒有CSRF保護”。

10. 應用程序錯誤信息

 

    同“6.錯誤的頁面信息”

11. SQL注入

11.1 問題描述

 

    受外部影響的輸入來構造SQL 命令的全部或一部分，但是它對可能在所需 SQL 命令發送到數據庫時修改該命令的特殊元素未正確進行無害化處理。如果在用戶可控制的輸入中沒有對 SQL 語法充分地除去或引用，那么生成的 SQL 查詢可能會導致將這些輸入解釋為 SQL 而不是普通用戶數據。這可用於修改查詢邏輯以繞過安全性檢查，或者插入其他用於修改后端數據庫的語句，並可能包括執行系統命令。

11.2 整改建議

 

    public static String filterContent(Stringcontent){

    String flt ="'|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare|;|or|-|+|,";

    Stringfilter[] = flt.split("|");

    for(int i=0;i

    {

    content.replace(filter[i], "");

    }

    return content;

    }

    參考信息：http://www.owasp.org/index.php/Top_10_2010-A1

12. HTTP版本過低

12.1 問題描述

 

    Apache/IIS等版本過低存在眾多安全漏洞。

12.2 整改建議

 

    升級Apache/IIS等到最新版本。

13. 微軟IIS波狀目錄枚舉

13.1 問題描述

 

    攻擊者可以利用“~”字符猜解或遍歷服務器中的文件名，或對IIS服務器中的.Net Framework進行拒絕服務攻擊。

13.2 整改建議

 

    升級netframework 至4.0以上版本。

14. 未加密的__VIEWSTATE的參數

14.1 問題描述

 

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

14.2 整改建議

 

    在 Web.Config 文件的 元素之下，添加下面這一行：

    <system.web> <machinekey validation="3DES"></machinekey></system.web>

15. Unicode轉換問題

15.1 問題描述

 

    Unicode編碼未指定

15.2 整改建議

 

    在源碼內指定編碼類型即可解決如：UTF-8

16. 證書泄漏

16.1 問題描述

 

    發現SSL證書信息

16.2 整改建議

 

    使用公認第三方如CA的簽名證書。

17. 目錄列表

17.1 問題描述

 

    可能會查看和下載特定 Web應用程序虛擬目錄的內容，其中可能包含受限文件。

17.2 整改建議

 

    [1] 將 Web 服務器配置成拒絕列出目錄。

    [2] 根據 Web 服務器或 Web 應用程序上現有的問題來下載特定安全補丁。部分已知的目錄列表問題列在這個咨詢的“引用”字段中。

    [3] 利用“CERT”咨詢中的變通方法（在這項咨詢的“引用”字段中）來修訂短文件名（8.3 DOS 格式）問題：

    a. 想要完全由 Web 服務器來保護的文件僅用 8.3 標准短文件名。在FAT 文件系統（16 位）上，您可以啟用“Win31FileSystem”注冊表鍵（設為 1，注冊表路徑：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\）來強制這一點。

    b. 在 NTFS（32 位）上，您可以啟用“NtfsDisable8dot3NameCreation”注冊表鍵（設為 1，注冊表路徑：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\）來禁用創建長文件名文件的8.3 標准短文件名。不過，這個步驟可能會引起與 16 位應用程序的兼容性問題。

    c. 使用基於 NTFS 的 ACL（目錄或文件級別的訪問控制表）來擴增或替換基於 Web 服務器的安全。

18. 備份文件

18.1 問題描述

 

    存在不必要的備份殘留文件，可能會被信息采集進入步深入滲透。

18.2 整改建議

 

    刪除不必要的備份文件。

19. ASP.NET padding oracl攻擊

19.1 問題描述

 

    使用.NETFramework所編譯的ASP.Net應用中沒有正確地實現加密，攻擊者可以解密並篡改敏感數據。

    如果要理解這個漏洞，首先要了解加密系統中的提示機制，當你提出問題時提示機制會給出某種形式的答案。此漏洞涉及到ASP.NET對加密信息中填充數據的提示，攻擊者可以通過向Web服務器發送特定的密文文本，然后通過檢查所返回的出錯代碼來判斷數據是否被正確解密。通過反復上述操作，攻擊者就可以收集到足夠的信息用來解密剩余部分的密文文本。

19.2 整改建議

 

    打上MS10-070漏洞補丁。

20. 用戶得憑證信息以明文發送

20.1 問題描述

 

    不安全明文傳輸登錄請求。

20.2 整改建議

 

    使用SSL加密。

21. Web應用防火牆檢測從HTTP HTTPS后不安全的過渡形式

21.1 問題描述

 

    不安全明文傳輸方式。

21.2 整改建議

 

    使用所以頁面通過SSL加密。

22. struts2漏洞

22.1 問題描述

 

    struts2框架版本過低，存在遠程任意命令執行漏洞。

22.2 整改建議

 

    升級struts2框架到最新版本。

23. 弱口令

23.1 問題描述

 

    使用如：123456、test等弱口令。

23.2 整改建議

 

    按電信密碼規范要求配置口令。

24. 文件包含

24.1 問題描述

 

    可能會在 Web 服務器上運行遠程命令。這通常意味着完全破壞服務器及其內容。

24.2 整改建議

 

    假定所有輸入都是惡意的。使用“接受已知善意”輸入驗證策略：嚴格遵守規范的可接受輸入的白名單。拒絕任何沒有嚴格遵守規范的輸入，或者將其轉換為遵守規范的內容。不要完全依賴於將惡意或格式錯誤的輸入加入黑名單。但是，黑名單可幫助檢測潛在攻擊，或者確定哪些輸入格式不正確，以致應當將其徹底拒絕。

    執行輸入驗證時，請考慮所有潛在相關屬性，包括長度、輸入類型、可接受值的完整范圍、缺失或多余輸入、語法、跨相關字段的一致性以及業務規則一致性。以業務規則邏輯為例，“boat”可能在語法上有效，因為它僅包含字母數字字符，但如果預期為顏色（如“red”或“blue”），那么它無效。

    對於文件名，請使用限制要使用的字符集的嚴格白名單。如果可行，請僅允許文件名中出現單個“.”字符以避免 CWE-23 之類的弱點，並排除“/”之類的目錄分隔符以避免 CWE-36。請使用允許的文件擴展名的白名單，這有助於避免 CWE-434。

25. 源代碼暴露

25.1 問題描述

 

    源代碼暴露。

25.2 整改建議

 

    刪除源代碼文件或對需要的未解析的源代碼進行解析。

26. SSL證書無效

26.1 問題描述

 

    SSL證書過期或SSL證書不合法等。

26.2 整改建議

 

    重新生成配置SSL證書。

27. SSL加密方式弱

27.1 問題描述

 

    SSL證書加密方式弱，導致加密信息可能被解密。

27.2 整改建議

 

    重新生成SSL證書，加密算法選擇如：RSA-1024等。

28. Http請求頭的額外的回車換行符注入

28.1 問題描述

 

    攻擊者可能注入自定義HTTP頭。例如，攻擊者可以注入會話cookie或HTML代碼。這可能會進行類似的XSS(跨站點腳本)或會話固定漏洞。

28.2 整改建議

 

    這種現象往往表現在帶有參數傳遞的網頁，只要合理的過濾好就OK啦，提供PHP代碼：

    $post =trim($post);

    2 $post =strip_tags($post,""); //清除HTML如
等代碼

    3 $post =ereg_replace("\t","",$post); //去掉制表符號

    4 $post =ereg_replace("\r\n","",$post); //去掉回車換行符號

    5 $post =ereg_replace("\r","",$post); //去掉回車

    6 $post =ereg_replace("\n","",$post); //去掉換行

    7 $post =ereg_replace(" ","",$post); //去掉空格

    8 $post= ereg_replace("'","",$post); //去掉單引號

29. CRLF注入/ HTTP響應拆分

 

    同上：Http請求頭的額外的回車換行符注入。

30. MBean提交密碼字段中使用GET方法

30.1 問題描述

 

    使用GET方法MBean提交密碼字段。

30.2 整改建議

 

    更改為POST提交方法。

31. JBoss類漏洞

31.1 問題描述

 

    發現JBoss框架登錄管理后台等信息。

31.2 整改建議

 

    限制JBOSS控制台等目錄訪問權限。

32. Apache Tomcat版本低

32.1 問題描述

 

    Apache Tomcat版本過低

32.2 整改建議

 

    升級ApacheTomcat到最新版本。

33. Apache Tomcat類漏洞

33.1 問題描述

 

    發現存在ApacheTomcat的示例文件、控制台等信息。

33.2 整改建議

 

    刪除ApacheTomcat的示例文件及控制台相關文件。

34. 臨時應急加固方法

35. 非公眾訪問類

35.1 問題描述

 

    發現系統、數據庫類等漏洞沒法加固或暫時無法加固。

35.2 整改建議

 

    關閉不必要的應用或使用系統防火牆限制非公眾使用的端口進行來源綁定訪問。

36. WEB類

36.1 問題描述

 

    發現XSS、SQL等漏洞的應急加固辦法。

36.2 整改建議

 

    apache commons-lang工具包里的類，可以在工程中寫一個過濾器，使用該工具類去實現敏感字符的過濾。

    過濾器示例1參考地址：http://my.oschina.net/mousai/blog/88832

    過濾器示例2如下：

    使用JAVA過濾器對攻擊特征進行過濾如：

    一。寫一個過濾器

    代碼如下：

    package com.liufeng.sys.filter;

    import java.io.IOException;

    import java.io.PrintWriter;

    import javax.servlet.Filter;

    import javax.servlet.FilterChain;

    import javax.servlet.FilterConfig;

    import javax.servlet.ServletException;

    import javax.servlet.ServletRequest;

    import javax.servlet.ServletResponse;

    importjavax.servlet.http.HttpServletRequest;

    importjavax.servlet.http.HttpServletResponse;

    public class IllegalCharacterFilterimplements Filter {

    private String[] characterParams =null;

    private boolean K=true;

    public void destroy() {

    // TODO Auto-generated method stub

    }

    /**

    * 此程序塊主要用來解決參數帶非法字符等過濾功能

    */

    public void doFilter(ServletRequest request,ServletResponse response,

    FilterChain arg2) throwsIOException, ServletException {

    HttpServletRequest servletrequest =(HttpServletRequest) request;

    HttpServletResponse servletresponse= (HttpServletResponse) response;

    boolean status = false;

    java.util.Enumeration params =request.getParameterNames();

    String param="";

    String paramValue ="";

    servletresponse.setContentType("text/html");

    servletresponse.setCharacterEncoding("utf-8");

    while(params.hasMoreElements()) {

    param = (String)params.nextElement();

    String[] values =request.getParameterValues(param);

    paramValue = "";

    if(OK){//過濾字符串為0個時不對字符過濾

    for (int i = 0; i<values.length; i++)<="" p="">

    paramValue=paramValue+values[i];

    for(inti=0;i<characterparams.length;i++)< p="">

    if(paramValue.indexOf(characterParams[i]) >= 0) {

    status = true;

    break;

    }

    if(status)break;

    }

    }

    // System.out.println(param+"="+paramValue+";");

    if (status) {

    PrintWriter ut =servletresponse.getWriter();

    out

    .print("alert(\"對不起！您輸入內容含有非法字符。如：\\\"'\\\".等\");"

    // +servletrequest.getRequestURL()

    +"window.history.go(-1);");

    }else

    arg2.doFilter(request,response);

    }

    public void init(FilterConfig config)throws ServletException {

    if(config.getInitParameter("characterParams").length()<1)

    K=false;

    else

    this.characterParams = config.getInitParameter("characterParams").split(",");

    }

    }

    二。在web.xml文件中加入如下內容：

   

   

    IllegalCharacterFilter

   

    com.liufeng.sys.filter.IllegalCharacterFilter

   

   

    characterParams

    ',@

   

   

   

    IllegalCharacterFilter

    /*

   

    重啟你的服務器就OK了。

    這樣，增加此過濾器后能提高網站的安全，防止SQL注入，防止跨站腳本XSS等。