914      阿裏雲  技術社區[雲棲]

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

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(理論上)，所以表單中的數據也就構造失敗.

<?php
//構造加密的Cookie信息
$value = “DefenseSCRF”;
setcookie(”cookie”, $value, time()+3600);
?>

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

<?php
$hash = md5($_COOKIE['cookie']);
?>
<form method=”POST” action=”transfer.php”>
<input type=”text” name=”toBankId”>
<input type=”text” name=”money”>
<input type=”hidden” name=”hash” value=”<?=$hash;?>”>
<input type=”submit” name=”submit” value=”Submit”>
</form>

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

<?php
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())：

<?php
function gen_token() {
//這是貪方便，實際上單使用Rand()得出的隨機數作為令牌，也是不安全的。
//這個可以參考寫的Findbugs筆記中的《Randomobject created and used only once》
$token = md5(uniqid(rand(), true));
return $token;
}

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

<?php
function gen_stoken() {
$pToken = “”;
if($_SESSION[STOKEN_NAME]  == $pToken){
//沒有值，賦新值
$_SESSION[STOKEN_NAME] = gen_token();
}
else{
//繼續使用舊的值
}
}
?>

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

<?php
function gen_input() {
gen_stoken();
echo “<input type=\”hidden\” name=\”” .FTOKEN_NAME . “\”
value=\”” . $_SESSION[STOKEN_NAME] . “\”> “;
}
?>

4).WEB表單結構：

<?php
session_start();
include(”functions.php”);
?>
<form method=”POST” action=”transfer.php”>
<input type=”text” name=”toBankId”>
<input type=”text” name=”money”>
<? gen_input(); ?>
<input type=”submit” name=”submit” value=”Submit”>
</FORM>

5).服務端核對令牌：

2.  jQuery 跨站腳本漏洞

2.1    問題描述

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

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

2.2    整改方法

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

https://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、對穿入參數進行危險字符過濾，禁止('、"、+、%、&、<>、（）、;、,.等)特殊字符的傳入。

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

       {

              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;

}

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]https://issues.apache.org/bugzilla/show_bug.cgi?id=38217[/url]

(2)修改tomcat/conf/server.xml
啟用這一段：

<Connector port="8443"protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
 clientAuth="false"sslProtocol="TLS" />
並修改為：
<Connector port="8443" protocol="HTTP/1.1"SSLEnabled="true"
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"這個用其他的代替，就可以解決已解密的登錄請求，僅共參考

<div><li>密&nbsp;&nbsp;碼：<input type="text"

 onkeypress="javascript:hiddenPass(event)"onkeyup="this.value=this.value.replace(/./g,'*');"/></li>

<li><input type="hidden"name="password"/></li>

<div>

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

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

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

8.3    案例

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

1）.漏洞的描述

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

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

詳細可以看，

https://tomcat.apache.org/security-6.html

查找 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為最新版本。

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

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

https://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<filter.length ; i++)

    {

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

    }

    return content;

  }

參考信息：https://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"/>

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如<br />等代碼

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參考地址：https://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 OK=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++)

     paramValue=paramValue+values[i];

    for(inti=0;i<characterParams.length;i++)

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

      status = true;

      break; www.2cto.com

     }

    if(status)break;

    }

   }

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

   if (status) {

    PrintWriter out =servletresponse.getWriter();

    out

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

        // +servletrequest.getRequestURL()

         +"window.history.go(-1);</script>");

   }else

   arg2.doFilter(request,response);

 }

 public void init(FilterConfig config)throws ServletException {

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

   OK=false;

  else

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

 }

}

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

<!-- 非法字符過濾器 -->

<filter>

 <filter-name>IllegalCharacterFilter</filter-name>

  <filter-class>

  com.liufeng.sys.filter.IllegalCharacterFilter

  </filter-class>

  <init-param>

  <param-name>characterParams</param-name>

  <param-value>',@</param-value><!-- 此處加入要過濾的字符或字符串，以逗號隔開 -->

  </init-param>

 </filter>

 <filter-mapping>

 <filter-name>IllegalCharacterFilter</filter-name>

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

 </filter-mapping>

重啟你的服務器就OK了。

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

最後更新：2017-04-03 12:53:59

  上一篇： NFC and Contactless Technologies

  下一篇： linux驅動開發--字符設備：創建一組設備節點