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

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

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

3、個(gè)偽隨機(jī)值)：    這可能是最簡單的解決方案了，因?yàn)楣粽卟荒塬@得第三方的Cookie(理論上)，所以表單中的數(shù)據(jù)也就構(gòu)造失敗.       /構(gòu)造加密的Cookie信息    $value = “DefenseSCRF”;    setcookie(”cookie”, $value, time()+3600);    ?>    在表單里增加Hash值，以認(rèn)證這確實(shí)是用戶發(fā)送的請(qǐng)求。       $hash

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

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

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

7、果每次表單被裝入時(shí)站點(diǎn)生成一個(gè)偽隨機(jī)值來覆蓋以前的偽隨機(jī)值將會(huì)發(fā)生什么情況：用戶只能成功地提交他最后打開的表單，因?yàn)樗衅渌谋韱味己蟹欠ǖ膫坞S機(jī)值。必須小心操作以確保CSRF保護(hù)措施不會(huì)影響選項(xiàng)卡式的瀏覽或者利用多個(gè)瀏覽器窗口瀏覽一個(gè)站點(diǎn)。    以下實(shí)現(xiàn):    1).先是令牌生成函數(shù)(gen_token()：       function gen_token()     /這是貪方便，實(shí)際上單使用Rand()得出的隨機(jī)數(shù)作為令牌，也是不安全的。    /這個(gè)可以參考寫

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

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

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

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

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

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

14、誤頁，而不能使用服務(wù)器默認(rèn)的錯(cuò)誤輸出方式；    3、對(duì)穿入?yún)?shù)進(jìn)行危險(xiǎn)字符過濾，禁止('、"、+、%、&、<>、（）、;、,.等)特殊字符的傳入。3.3 案例：    加固范例（一）：    /*將login.jsp中String u =request.getParameter("u");替換為如下內(nèi)容：*/    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('+','_');    加固范例（二）：    /*更積極的方式是利用正則表達(dá)式只允許輸入指定的字符：*/ 

17、   /*在String u = request.getParameter("u");后代入以下isValidInput函數(shù)作辨別*/    public boolean isValidInput(Stringstr)        if(str.matches("a-z0-9+")return true;    else return false;    4. URL重定向釣魚4.1 3.1問題描述：    通過構(gòu)建URL，

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

19、t;（引號(hào)）    9 '（反斜杠轉(zhuǎn)義單引號(hào)）    10 "（反斜杠轉(zhuǎn)義引號(hào)）    11 <>（尖括號(hào)）    12 ()（括號(hào)）    13 +（加號(hào)）    14 CR（回車符，ASCII 0x0d）    15 LF（換行，ASCII 0x0a）    16 ,（逗號(hào)）    17 （反斜杠）4.3 3.3案例：    對(duì)輸入?yún)?shù)進(jìn)行做處理。  &

20、#160; 加固范例（一）：    /*將login.jsp中String u = request.getParameter("u");替換為如下內(nèi)容：*/    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 ('+','_');    加固范例（二）：    /*更積極的方式是利用正則表達(dá)式只允許輸入指定的字符：*/    /*在String u = request.getParameter("u");后代入以下isValidInput函數(shù)作辨別*/    public boolean

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

24、險(xiǎn)范例：    /*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變量內(nèi)容前加入對(duì)Password變量的加密處理：*/    <% pageimport="java.security.*" %>    <% pageimport="java.util.*" %>        public String byte2hex(byte b)/二行制轉(zhuǎn)字符串        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. 錯(cuò)誤的頁面信息6.1 問題描述：    錯(cuò)誤/警告消息，可能會(huì)泄露敏感信息。6.2 整改建議：    在編碼階段開發(fā)者對(duì)敏感頁面缺乏授權(quán)保護(hù)，導(dǎo)致相關(guān)URL頁面敏感信息泄露。建議修改錯(cuò)誤信息。    一切敏感或需要權(quán)限方可瀏覽的頁面，包括：敏感信息中轉(zhuǎn)處理頁面、上傳頁面、管理平臺(tái)頁面、用戶自管理頁面等。6.3 案例：    風(fēng)險(xiǎn)范例：    /*風(fēng)險(xiǎn)范例為一

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

30、    return;    7. 已解密的登陸請(qǐng)求7.1 問題描述：    用戶名、密碼輸入字段未經(jīng)加密即進(jìn)行了傳遞。7.2 整改建議：    確保所有登錄請(qǐng)求都以https加密方式發(fā)送到服務(wù)器。7.3 案例：    方法一：配置SSL加密傳輸    【概念理解】keystore 是一個(gè)密碼保護(hù)的文件，用來存儲(chǔ)密鑰和證書    (1)生成一個(gè)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    輸入密碼、提供你的信息即可。如果不是用來“玩”的話，請(qǐng)如實(shí)的填寫自己以及單位的信息吧。    【注意】它會(huì)在前后問你兩次密碼，第二次直接回車就行了，如果兩個(gè)密碼不一樣，將會(huì)出現(xiàn)java.io.IOException錯(cuò)誤。詳情請(qǐng)見：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"這個(gè)用其他的代替，就可以解決已解密的登錄請(qǐng)求，僅共參考   · 密  碼：<="" 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拒絕服務(wù)8.1 問題描述    HTTP存在DOS漏洞。    如果遠(yuǎn)程攻擊者使用發(fā)包工具向Apache服務(wù)器發(fā)送了不完整的HTTP請(qǐng)求，服務(wù)器會(huì)打開連接等待接受完整的頭，但如果發(fā)包工具不再繼續(xù)發(fā)送完整請(qǐng)求而是發(fā)送無效頭的話，就會(huì)一直保持打開的連接。這種攻擊所造成的影響很嚴(yán)重，因?yàn)楣粽卟恍枰l(fā)送很大的通訊就

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

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

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

42、60;   同“6.錯(cuò)誤的頁面信息”11. SQL注入11.1 問題描述    受外部影響的輸入來構(gòu)造SQL 命令的全部或一部分，但是它對(duì)可能在所需 SQL 命令發(fā)送到數(shù)據(jù)庫時(shí)修改該命令的特殊元素未正確進(jìn)行無害化處理。如果在用戶可控制的輸入中沒有對(duì) SQL 語法充分地除去或引用，那么生成的 SQL 查詢可能會(huì)導(dǎo)致將這些輸入解釋為 SQL 而不是普通用戶數(shù)據(jù)。這可用于修改查詢邏輯以繞過安全性檢查，或者插入其他用于修改后端數(shù)據(jù)庫的語句，并可能包括執(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 整改建議    升級(jí)Apache/IIS等到最新版本。13. 微軟IIS波狀目錄枚舉13.1 問題描述    攻擊

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

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

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

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

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

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

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

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

53、6。請(qǐng)使用允許的文件擴(kuò)展名的白名單，這有助于避免 CWE-434。25. 源代碼暴露25.1 問題描述    源代碼暴露。25.2 整改建議    刪除源代碼文件或?qū)π枰奈唇馕龅脑创a進(jìn)行解析。26. SSL證書無效26.1 問題描述    SSL證書過期或SSL證書不合法等。26.2 整改建議    重新生成配置SSL證書。27. SSL加密方式弱27.1 問題描述    SSL證書加密方式弱，導(dǎo)致加密信息可能被解密。27.2 整改建議    重新生成SSL證書，加密算法

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

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

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

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

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

59、#160; 過濾器示例1參考地址：    過濾器示例2如下：    使用JAVA過濾器對(duì)攻擊特征進(jìn)行過濾如：    一。寫一個(gè)過濾器    代碼如下：    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、     /*    * 此程序塊主要用來解決參數(shù)帶非法字符等過濾功能    */    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()