常見安全漏洞及整改建議[備忘]
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”
?>
在表單裡增加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 整改方法
目前廠商已經發布了升級補丁以修復此安全問題，補丁獲取連結：
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、對穿入引數進行危險字元過濾，禁止('、"、+、%、&、<>、（）、;、,.等)特殊字元的傳入。
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
輸入密碼、提供你的資訊即可。如果不是用來“玩”的話，請如實的填寫自己以及單位的資訊吧。
(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
方法二：把text="password"這個用其他的代替，就可以解決已解密的登入請求，僅共參考
<div><li>密 碼：<input type="text"id="password1" style="width:146px;height:18px;"
onkeypress="javascript:hiddenPass(event)"onkeyup="this.value=this.value.replace(/./g,'*');"/></li>
<li><inputid="password" 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
------------
目前廠商還沒有提供補丁或者升級程式，我們建議使用此軟體的使用者隨時關注廠商的主頁以獲取最新版本：http://www.apache.org
8.3 案例
關於HTTP版本低漏洞資訊，如下：
1）.漏洞的描述
2）.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）.公開的漏洞測試程式碼
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;
}
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參考地址：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 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();
Stri