常見WEB安全漏洞及整改建議創(chuàng)新

1、常見WEB安全漏洞及整改建議 1. HTML表單沒有CSRF保護1.1 問題描述：    CSRF（Cross-site request forgery），中文名稱：跨站請求偽造，也被稱為：one click attack/session riding，縮寫為：CSRF/XSRF。    CSRF攻擊：攻擊者盜用了你的身份，以你的名義發(fā)送惡意請求。CSRF能夠做的事情包括：以你名義發(fā)送郵件，發(fā)消息，盜取你的賬號，甚至于購買商品，虛擬貨幣轉賬造成的問題包括：個人隱私泄露以及財產安全。1.2 整改建議：    CSRF的防御可以從服務端和

2、客戶端兩方面著手，防御效果是從服務端著手效果比較好，現在一般的CSRF防御也都在服務端進行。有以下三種方法：    (1).Cookie Hashing(所有表單都包含同一個偽隨機值)：    (2).驗證碼    (3).One-Time Tokens(不同的表單包含一個不同的偽隨機值)1.3 案例：    1.服務端進行CSRF防御    服務端的CSRF方式方法很多樣，但總的思想都是一致的，就是在客戶端頁面增加偽隨機數。1.3.1 Cookie Hashing(所有表單都包含同一

3、個偽隨機值)：    這可能是最簡單的解決方案了，因為攻擊者不能獲得第三方的Cookie(理論上)，所以表單中的數據也就構造失敗.       /構造加密的Cookie信息    $value = “DefenseSCRF”;    setcookie(”cookie”, $value, time()+3600);    ?>    在表單里增加Hash值，以認證這確實是用戶發(fā)送的請求。       $hash

4、 = md5($_COOKIE'cookie');    ?>               ”>           然后在服務器端進行Hash值驗證       if(isset($_POST'check')     $hash = md5($_COOKIE'cookie');

5、    if($_POST'check' = $hash)     doJob();    else     /        else     /        ?>    這個方法已經可以杜絕99%的CSRF攻擊了，那還有1%.由于用戶的Cookie很容易由于網站的XSS漏洞而被盜取，這就另外的1%。一般的攻擊者看到有需要算Hash值，基本都會放棄了，某些除外，所以如果需

6、要100%的杜絕，這個不是最好的方法。1.3.2 驗證碼    這個方案的思路是：每次的用戶提交都需要用戶在表單中填寫一個圖片上的隨機字符串，這個方案可以完全解決CSRF，但在易用性方面似乎不是太好，還有是驗證碼圖片的使用涉及了一個被稱為MHTML的Bug，可能在某些版本的微軟IE中受影響。1.3.3 One-Time Tokens(不同的表單包含一個不同的偽隨機值)    在實現One-Time Tokens時，需要注意一點：就是“并行會話的兼容”。如果用戶在一個站點上同時打開了兩個不同的表單，CSRF保護措施不應該影響到他對任何表單的提交?？紤]一下如

7、果每次表單被裝入時站點生成一個偽隨機值來覆蓋以前的偽隨機值將會發(fā)生什么情況：用戶只能成功地提交他最后打開的表單，因為所有其他的表單都含有非法的偽隨機值。必須小心操作以確保CSRF保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器窗口瀏覽一個站點。    以下實現:    1).先是令牌生成函數(gen_token()：       function gen_token()     /這是貪方便，實際上單使用Rand()得出的隨機數作為令牌，也是不安全的。    /這個可以參考寫

8、的Findbugs筆記中的Randomobject created and used only once    $token = md5(uniqid(rand(), true);    return $token;        2).然后是Session令牌生成函數(gen_stoken()：       function gen_stoken()     $pToken = “”;    if($_SESSIONSTOKEN_NA

9、ME = $pToken)    /沒有值，賦新值    $_SESSIONSTOKEN_NAME = gen_token();        else    /繼續(xù)使用舊的值            ?>    3).WEB表單生成隱藏輸入域的函數：       function gen_input()     gen_stoken(); 

10、  echo “<="" p="" style="padding: 0px; margin: 0px; font-size: 12px; font-family: 宋體;">    value=” . $_SESSIONSTOKEN_NAME . “”> “;        ?>    4).WEB表單結構：       session_start();    i

11、nclude(”functions.php”);    ?>                         5).服務端核對令牌：2. jQuery 跨站腳本漏洞2.1 問題描述    jQuery是繼prototype之后又一個優(yōu)秀的Javascrpt框架。    jQuery 1.6.3之前版本中存在跨站腳本漏洞。當使用location.hash選擇元素時

12、，通過特制的標簽，遠程攻擊者利用該漏洞注入任意web腳本或HTML。2.2 整改方法    目前廠商已經發(fā)布了升級補丁以修復此安全問題，補丁獲取鏈接：    2.3 整改案例    升級jQuery版本。3. 跨站腳本編制3.1 問題描述：    跨站腳本攻擊是通過在網頁中加入惡意代碼，當訪問者瀏覽網頁時惡意代碼會被執(zhí)行或者通過給管理員發(fā)信息的方式誘使管理員瀏覽，從而獲得管理員權限，控制整個網站。攻擊者利用跨站請求偽造能夠輕松地強迫用戶的瀏覽器發(fā)出非故意的HTTP請求，如詐騙性的電匯請求、修改口令和下載非法的內容等

13、請求。    風險等級：高    風險范圍：    任何存在輸入/輸出方法（包括GET與POST）的頁面皆可能存在惡意符號輸入缺陷，主要影響應用包括留言板、在線通訊信息、文章發(fā)布頁面等。3.2 整改建議：    對用戶輸入的參數執(zhí)行嚴格檢測：    1、對產生漏洞模塊的傳入參數進行有效性檢測。int類型的只允許0-9的整型數字；string等字符類型的只允許(1-9，a-z，A-Z)的英文字母；    2、當客戶端輸入限定值意外的字符后，立即轉向自定義的錯

14、誤頁，而不能使用服務器默認的錯誤輸出方式；    3、對穿入參數進行危險字符過濾，禁止('、"、+、%、&、<>、（）、;、,.等)特殊字符的傳入。3.3 案例：    加固范例（一）：    /*將login.jsp中String u =request.getParameter("u");替換為如下內容：*/    String u = request.getParameter("u");    u = u

15、.replace ('','_');    u = u.replace ('','_');    u = u.replace('"','_');    u = u.replace(''','_');    u = u.replace ('%','_');    u = u.replace('','

16、_');    u = u.replace('(','_');    u = u.replace(')','_');    u = u.replace('&','_');    u = u.replace('+','_');    加固范例（二）：    /*更積極的方式是利用正則表達式只允許輸入指定的字符：*/ 

17、   /*在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，

18、攻擊者可以使用戶重定向到任意URL，利用這個漏洞可以誘使用戶訪問某個頁面，掛馬、密碼記錄、下載任意文件等，常被用來釣魚。4.2 3.2整改建議：    對輸入參數進行做處理，建議過濾出所有以下字符：    1 |（豎線符號）    2 & （& 符號）    3;（分號）    4 $（美元符號）    5 %（百分比符號）    6 （at 符號）    7 '（單引號）    8 &quo

19、t;（引號）    9 '（反斜杠轉義單引號）    10 "（反斜杠轉義引號）    11 <>（尖括號）    12 ()（括號）    13 +（加號）    14 CR（回車符，ASCII 0x0d）    15 LF（換行，ASCII 0x0a）    16 ,（逗號）    17 （反斜杠）4.3 3.3案例：    對輸入參數進行做處理。  &

20、#160; 加固范例（一）：    /*將login.jsp中String u = request.getParameter("u");替換為如下內容：*/    String u =request.getParameter("u");    u = u.replace ('','_');    u = u.replace ('','_');    u = u.replace (&#

21、39;"','_');    u = u.replace (''','_');    u = u.replace ('%','_');    u = u.replace ('','_');    u = u.replace ('(','_');    u = u.replace (')','_')

22、;    u = u.replace ('&','_');    u = u.replace ('+','_');    加固范例（二）：    /*更積極的方式是利用正則表達式只允許輸入指定的字符：*/    /*在String u = request.getParameter("u");后代入以下isValidInput函數作辨別*/    public boolean

23、isValidInput(String str)        if(str.matches("a-z0-9+") returntrue;    else return false;    5. 不安全存儲5.1 問題描述    不安全存儲，在頁面上顯示密碼。5.2 整改建議    加密密碼或不在頁面及源碼上顯示密碼。5.3 案例    一切涉及敏感信息讀寫操作的頁面，如登陸頁面、登陸處理頁面等。    風

24、險范例：    /*Add_user.jsp*/    String sql;    sql="insert into user(username,password) values (" + Username + "," + Password +")"    Statement sm = cn.createStatement();    sm.executeUpdate(sql);    sm.close();

25、60;   加固范例：    /*在生成sql變量內容前加入對Password變量的加密處理：*/    <% pageimport="java.security.*" %>    <% pageimport="java.util.*" %>        public String byte2hex(byte b)/二行制轉字符串        Stringhs=&quo

26、t;"    Stringstmp=""    for(int n=0;n<b.length;n+)< p="">        stmp=(java.lang.Integer.toHexString(bn& 0XFF);    if(stmp.length()=1) hs=hs+"0"+stmp;    elsehs=hs+stmp;    /if(n<

27、b.length-1) hs="hs+":"</p">        returnhs.toUpperCase();            java.security.MessageDigestalg=java.security.MessageDigest.getInstance("SHA-256");    alg.update(Password.getBytes();    byt

28、e digest=alg.digest();    Password=byte2hex(digest);6. 錯誤的頁面信息6.1 問題描述：    錯誤/警告消息，可能會泄露敏感信息。6.2 整改建議：    在編碼階段開發(fā)者對敏感頁面缺乏授權保護，導致相關URL頁面敏感信息泄露。建議修改錯誤信息。    一切敏感或需要權限方可瀏覽的頁面，包括：敏感信息中轉處理頁面、上傳頁面、管理平臺頁面、用戶自管理頁面等。6.3 案例：    風險范例：    /*風險范例為一

29、切需要敏感但編碼階段沒有進行授權鑒別的頁面*/    加固范例：    if(session.getValue("UserName")=null)|(session.getValue("UserClass")=null)|(!session.getValue("UserClass").equals("系統(tǒng)管理員")        response.sendRedirect("err.jsp?id=14");

30、    return;    7. 已解密的登陸請求7.1 問題描述：    用戶名、密碼輸入字段未經加密即進行了傳遞。7.2 整改建議：    確保所有登錄請求都以https加密方式發(fā)送到服務器。7.3 案例：    方法一：配置SSL加密傳輸    【概念理解】keystore 是一個密碼保護的文件，用來存儲密鑰和證書    (1)生成一個keystore文件（包含證書），文件位置/usr/local/tomcat/conf/.keystor

31、e    # cd /usr/local/jdk/bin/    # ./keytool -genkey -alias tomcat -keyalg RSA -keystore/usr/local/tomcat/conf/.keystore    輸入密碼、提供你的信息即可。如果不是用來“玩”的話，請如實的填寫自己以及單位的信息吧。    【注意】它會在前后問你兩次密碼，第二次直接回車就行了，如果兩個密碼不一樣，將會出現java.io.IOException錯誤。詳情請見：urlhttp:/is

32、/bugzilla/show_bug.cgi?id=38217/url    (2)修改tomcat/conf/server.xml    啟用這一段：   <="" p="">    maxThreads="150" scheme="https" secure="true"    clientAuth="false"sslProtoc

33、ol="TLS" />    并修改為：   <="" p="">    maxThreads="150" scheme="https" secure="true"    keystoreFile="/usr/local/tomcat/conf/.keystore"    keystorePass="snailwarrior&qu

34、ot;    clientAuth="false" sslProtocol="TLS" />    (3)重啟Tomcat    # /usr/local/tomcat/bin/shutdown.sh    # /usr/local/tomcat/bin/startup.sh    (4)防火墻開啟8443端口    瀏覽器輸入：url0:8443/url    

35、方法二：把text="password"這個用其他的代替，就可以解決已解密的登錄請求，僅共參考   · 密  碼：<="" p="" style="padding: 0px; margin: 0px; font-size: 12px; font-family: 宋體; width: 146px; height: 18px;">    nkeypress="javascript：hiddenPass(event)"o

36、nkeyup="this.value=this.value.replace(/./g,'*');"/>·    ·        js代碼    functionhiddenPass(e)    e = e ? e : window.event;    var kcode = e.which ? e.which : e.keyCode;    var pass =document.getElem

37、entByIdx_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

38、(0,pass.length);            獲取密碼：document.getElementByIdx_x("password").value;8. HTTP拒絕服務8.1 問題描述    HTTP存在DOS漏洞。    如果遠程攻擊者使用發(fā)包工具向Apache服務器發(fā)送了不完整的HTTP請求，服務器會打開連接等待接受完整的頭，但如果發(fā)包工具不再繼續(xù)發(fā)送完整請求而是發(fā)送無效頭的話，就會一直保持打開的連接。這種攻擊所造成的影響很嚴重，因為攻擊者不需要發(fā)送很大的通訊就

39、可以耗盡服務器上的可用連接。也就是說，即使低帶寬的用戶也可以攻擊大流量的服務器。8.2 整改方法    臨時解決方法：    更改默認的TimeOut選項少于7000ms，或使用mod_limitipconn模塊限制單個IP地址的連接數。    廠商補?。?#160;   Apache Group    -    目前廠商還沒有提供補丁或者升級程序，我們建議使用此軟件的用戶隨時關注廠商的主頁以獲取最新版本：8.3 案例

40、0;   關于HTTP版本低漏洞信息，如下：    1）.漏洞的描述        2）.TOMCAT官網說這個不是一個漏洞，沒有打算出補丁，只有緩解方法    詳細可以看，    /security-6.html#Not_a_vulnerability_in_Tomcat    查找 CVE-2012-5568 會看到官網說明。    緩解方法    通過se

41、rver.xml內定義的連接器的connectionTimeout屬性，配置一個合適的超時時間。        3）.但CVE 的漏洞還是所有版本也存在。下面是一個CVE的詳細信息地址，此頁面最后更新為2013-03-07，當時6.0.35為最新版本。        4）.公開的漏洞測試代碼    /slowloris/slowloris.pl9. 跨站點請求偽造    同“1.HTML表單沒有CSRF保護”。10. 應用程序錯誤信息

42、60;   同“6.錯誤的頁面信息”11. SQL注入11.1 問題描述    受外部影響的輸入來構造SQL 命令的全部或一部分，但是它對可能在所需 SQL 命令發(fā)送到數據庫時修改該命令的特殊元素未正確進行無害化處理。如果在用戶可控制的輸入中沒有對 SQL 語法充分地除去或引用，那么生成的 SQL 查詢可能會導致將這些輸入解釋為 SQL 而不是普通用戶數據。這可用于修改查詢邏輯以繞過安全性檢查，或者插入其他用于修改后端數據庫的語句，并可能包括執(zhí)行系統(tǒng)命令。11.2 整改建議    public static String filterConte

43、nt(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<="" p="">       

44、content.replace(filteri, "");        return content;        參考信息：/index.php/Top_10_2010-A112. HTTP版本過低12.1 問題描述    Apache/IIS等版本過低存在眾多安全漏洞。12.2 整改建議    升級Apache/IIS等到最新版本。13. 微軟IIS波狀目錄枚舉13.1 問題描述    攻擊

45、者可以利用“”字符猜解或遍歷服務器中的文件名，或對IIS服務器中的.Net Framework進行拒絕服務攻擊。13.2 整改建議    升級netframework 至4.0以上版本。14. 未加密的_VIEWSTATE的參數14.1 問題描述    可能會收集有關 Web 應用程序的敏感信息，如用戶名、密碼、機器名和/或敏感文件位置。14.2 整改建議    在 Web.Config 文件的 元素之下，添加下面這一行：   15. Unicode轉換問題15.1 問題描述    U

46、nicode編碼未指定15.2 整改建議    在源碼內指定編碼類型即可解決如：UTF-816. 證書泄漏16.1 問題描述    發(fā)現SSL證書信息16.2 整改建議    使用公認第三方如CA的簽名證書。17. 目錄列表17.1 問題描述    可能會查看和下載特定 Web應用程序虛擬目錄的內容，其中可能包含受限文件。17.2 整改建議    1 將 Web 服務器配置成拒絕列出目錄。    2 根據 Web 服務器或 Web 應用程序上現有的問題來下載特定安全補丁。部分

47、已知的目錄列表問題列在這個咨詢的“引用”字段中。    3 利用“CERT”咨詢中的變通方法（在這項咨詢的“引用”字段中）來修訂短文件名（8.3 DOS 格式）問題：    a. 想要完全由 Web 服務器來保護的文件僅用 8.3 標準短文件名。在FAT 文件系統(tǒng)（16 位）上，您可以啟用“Win31FileSystem”注冊表鍵（設為 1，注冊表路徑：HKEY_LOCAL_MACHINESystemCurrentControlSetControlFileSystem）來強制這一點。    b. 在 NTFS（32 位）上，您可以啟用

48、“NtfsDisable8dot3NameCreation”注冊表鍵（設為 1，注冊表路徑：HKEY_LOCAL_MACHINESystemCurrentControlSetControlFileSystem）來禁用創(chuàng)建長文件名文件的8.3 標準短文件名。不過，這個步驟可能會引起與 16 位應用程序的兼容性問題。    c. 使用基于 NTFS 的 ACL（目錄或文件級別的訪問控制表）來擴增或替換基于 Web 服務器的安全。18. 備份文件18.1 問題描述    存在不必要的備份殘留文件，可能會被信息采集進入步深入滲透。18.2 整改建議 

49、  刪除不必要的備份文件。19. ASP.NET padding oracl攻擊19.1 問題描述    使用.NETFramework所編譯的ASP.Net應用中沒有正確地實現加密，攻擊者可以解密并篡改敏感數據。    如果要理解這個漏洞，首先要了解加密系統(tǒng)中的提示機制，當你提出問題時提示機制會給出某種形式的答案。此漏洞涉及到ASP.NET對加密信息中填充數據的提示，攻擊者可以通過向Web服務器發(fā)送特定的密文文本，然后通過檢查所返回的出錯代碼來判斷數據是否被正確解密。通過反復上述操作，攻擊者就可以收集到足夠的信息用來解密剩余部分的密文文本。1

50、9.2 整改建議    打上MS10-070漏洞補丁。20. 用戶得憑證信息以明文發(fā)送20.1 問題描述    不安全明文傳輸登錄請求。20.2 整改建議    使用SSL加密。21. Web應用防火墻檢測從HTTP HTTPS后不安全的過渡形式21.1 問題描述    不安全明文傳輸方式。21.2 整改建議    使用所以頁面通過SSL加密。22. struts2漏洞22.1 問題描述    struts2框架版本過低，存在遠程任意命令執(zhí)行漏洞。22.2 整改建議 

51、;   升級struts2框架到最新版本。23. 弱口令23.1 問題描述    使用如：123456、test等弱口令。23.2 整改建議    按電信密碼規(guī)范要求配置口令。24. 文件包含24.1 問題描述    可能會在 Web 服務器上運行遠程命令。這通常意味著完全破壞服務器及其內容。24.2 整改建議    假定所有輸入都是惡意的。使用“接受已知善意”輸入驗證策略：嚴格遵守規(guī)范的可接受輸入的白名單。拒絕任何沒有嚴格遵守規(guī)范的輸入，或者將其轉換為遵守規(guī)范的內容。不要完全依賴于將惡意或格式錯誤的輸入

52、加入黑名單。但是，黑名單可幫助檢測潛在攻擊，或者確定哪些輸入格式不正確，以致應當將其徹底拒絕。    執(zhí)行輸入驗證時，請考慮所有潛在相關屬性，包括長度、輸入類型、可接受值的完整范圍、缺失或多余輸入、語法、跨相關字段的一致性以及業(yè)務規(guī)則一致性。以業(yè)務規(guī)則邏輯為例，“boat”可能在語法上有效，因為它僅包含字母數字字符，但如果預期為顏色（如“red”或“blue”），那么它無效。    對于文件名，請使用限制要使用的字符集的嚴格白名單。如果可行，請僅允許文件名中出現單個“.”字符以避免 CWE-23 之類的弱點，并排除“/”之類的目錄分隔符以避免 CWE-3

53、6。請使用允許的文件擴展名的白名單，這有助于避免 CWE-434。25. 源代碼暴露25.1 問題描述    源代碼暴露。25.2 整改建議    刪除源代碼文件或對需要的未解析的源代碼進行解析。26. SSL證書無效26.1 問題描述    SSL證書過期或SSL證書不合法等。26.2 整改建議    重新生成配置SSL證書。27. SSL加密方式弱27.1 問題描述    SSL證書加密方式弱，導致加密信息可能被解密。27.2 整改建議    重新生成SSL證書，加密算法

54、選擇如：RSA-1024等。28. Http請求頭的額外的回車換行符注入28.1 問題描述    攻擊者可能注入自定義HTTP頭。例如，攻擊者可以注入會話cookie或HTML代碼。這可能會進行類似的XSS(跨站點腳本)或會話固定漏洞。28.2 整改建議    這種現象往往表現在帶有參數傳遞的網頁，只要合理的過濾好就OK啦，提供PHP代碼：    $post =trim($post);    2 $post =strip_tags($post,""); /清除HTML如等代碼 

55、60; 3 $post =ereg_replace("t","",$post); /去掉制表符號    4 $post =ereg_replace("rn","",$post); /去掉回車換行符號    5 $post =ereg_replace("r","",$post); /去掉回車    6 $post =ereg_replace("n","",$post); /去掉換

56、行    7 $post =ereg_replace(" ","",$post); /去掉空格    8 $post= ereg_replace("'","",$post); /去掉單引號29. CRLF注入/ HTTP響應拆分    同上：Http請求頭的額外的回車換行符注入。30. MBean提交密碼字段中使用GET方法30.1 問題描述    使用GET方法MBean提交密碼字段。30.2 整改建議   

57、; 更改為POST提交方法。31. JBoss類漏洞31.1 問題描述    發(fā)現JBoss框架登錄管理后臺等信息。31.2 整改建議    限制JBOSS控制臺等目錄訪問權限。32. Apache Tomcat版本低32.1 問題描述    Apache Tomcat版本過低32.2 整改建議    升級ApacheTomcat到最新版本。33. Apache Tomcat類漏洞33.1 問題描述    發(fā)現存在ApacheTomcat的示例文件、控制臺等信息。33.2 整改建議 

58、  刪除ApacheTomcat的示例文件及控制臺相關文件。34. 臨時應急加固方法35. 非公眾訪問類35.1 問題描述    發(fā)現系統(tǒng)、數據庫類等漏洞沒法加固或暫時無法加固。35.2 整改建議    關閉不必要的應用或使用系統(tǒng)防火墻限制非公眾使用的端口進行來源綁定訪問。36. WEB類36.1 問題描述    發(fā)現XSS、SQL等漏洞的應急加固辦法。36.2 整改建議    apache commons-lang工具包里的類，可以在工程中寫一個過濾器，使用該工具類去實現敏感字符的過濾。  &

59、#160; 過濾器示例1參考地址：    過濾器示例2如下：    使用JAVA過濾器對攻擊特征進行過濾如：    一。寫一個過濾器    代碼如下：    package com.liufeng.sys.filter;    import java.io.IOException;    import java.io.PrintWriter;    import javax.servlet.Filter;    im

60、port javax.servlet.FilterChain;    import javax.servlet.FilterConfig;    import javax.servlet.ServletException;    import javax.servlet.ServletRequest;    import javax.servlet.ServletResponse;    importjavax.servlet.http.HttpServletRequest; 

61、60; importjavax.servlet.http.HttpServletResponse;    public class IllegalCharacterFilterimplements Filter     private String characterParams =null;    private boolean K=true;    public void destroy()     / TODO Auto-generated method stub   

62、     /*    * 此程序塊主要用來解決參數帶非法字符等過濾功能    */    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()