常見WEB安全漏洞和整改建議

/常見WEB安全漏洞及整改建議1.HTML表單沒有CSRF保護(hù)1.1問題描述：CSRF〔Cross-siterequestforgery.中文名稱：跨站請求偽造.也被稱為：oneclickattack/sessionriding.縮寫為：CSRF/XSRF。CSRF攻擊：攻擊者盜用了你的身份.以你的名義發(fā)送惡意請求。CSRF能夠做的事情包括：以你名義發(fā)送郵件.發(fā)消息.盜取你的賬號(hào).甚至于購買商品.虛擬貨幣轉(zhuǎn)賬……造成的問題包括：個(gè)人隱私泄露以及財(cái)產(chǎn)安全。1.2整改建議：CSRF的防御可以從服務(wù)端和客戶端兩方面著手.防御效果是從服務(wù)端著手效果比較好.現(xiàn)在一般的CSRF防御也都在服務(wù)端進(jìn)行。有以下三種方法：<1>.CookieHashing<所有表單都包含同一個(gè)偽隨機(jī)值>：<2>.驗(yàn)證碼<3>.One-TimeTokens<不同的表單包含一個(gè)不同的偽隨機(jī)值>1.3案例：1.服務(wù)端進(jìn)行CSRF防御服務(wù)端的CSRF方式方法很多樣.但總的思想都是一致的.就是在客戶端頁面增加偽隨機(jī)數(shù)。1.3.1CookieHashing<所有表單都包含同一個(gè)偽隨機(jī)值>：這可能是最簡單的解決方案了.因?yàn)楣粽卟荒塬@得第三方的Cookie<理論上>.所以表單中的數(shù)據(jù)也就構(gòu)造失敗.//構(gòu)造加密的Cookie信息$value="DefenseSCRF";setcookie<"cookie",$value,time<>+3600>;?>在表單里增加Hash值.以認(rèn)證這確實(shí)是用戶發(fā)送的請求。$hash=md5<$_COOKIE['cookie']>;?>">然后在服務(wù)器端進(jìn)行Hash值驗(yàn)證if<isset<$_POST['check']>>{$hash=md5<$_COOKIE['cookie']>;if<$_POST['check']==$hash>{doJob<>;}else{//…}}else{//…}?>這個(gè)方法已經(jīng)可以杜絕99%的CSRF攻擊了.那還有1%….由于用戶的Cookie很容易由于網(wǎng)站的XSS漏洞而被盜取.這就另外的1%。一般的攻擊者看到有需要算Hash值.基本都會(huì)放棄了.某些除外.所以如果需要100%的杜絕.這個(gè)不是最好的方法。1.3.2驗(yàn)證碼這個(gè)方案的思路是：每次的用戶提交都需要用戶在表單中填寫一個(gè)圖片上的隨機(jī)字符串.這個(gè)方案可以完全解決CSRF.但在易用性方面似乎不是太好.還有是驗(yàn)證碼圖片的使用涉及了一個(gè)被稱為MHTML的Bug.可能在某些版本的微軟IE中受影響。1.3.3One-TimeTokens<不同的表單包含一個(gè)不同的偽隨機(jī)值>在實(shí)現(xiàn)One-TimeTokens時(shí).需要注意一點(diǎn)：就是"并行會(huì)話的兼容"。如果用戶在一個(gè)站點(diǎn)上同時(shí)打開了兩個(gè)不同的表單.CSRF保護(hù)措施不應(yīng)該影響到他對任何表單的提交?？紤]一下如果每次表單被裝入時(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<>>：functiongen_token<>{//這是貪方便.實(shí)際上單使用Rand<>得出的隨機(jī)數(shù)作為令牌.也是不安全的。//這個(gè)可以參考寫的Findbugs筆記中的《Randomobjectcreatedandusedonlyonce》$token=md5<uniqid<rand<>,true>>;return$token;}2>.然后是Session令牌生成函數(shù)<gen_stoken<>>：functiongen_stoken<>{$pToken="";if<$_SESSION[STOKEN_NAME]==$pToken>{//沒有值.賦新值$_SESSION[STOKEN_NAME]=gen_token<>;}else{//繼續(xù)使用舊的值}}?>3>.WEB表單生成隱藏輸入域的函數(shù)：functiongen_input<>{gen_stoken<>;echo"<=""p=""style="padding:0px;margin:0px;font-size:12px;font-family:宋體;">value=\"".$_SESSION[STOKEN_NAME]."\">";}?>4>.WEB表單結(jié)構(gòu)：session_start<>;include<"functions.php">;?>5>.服務(wù)端核對令牌：2.jQuery跨站腳本漏洞2.1問題描述jQuery是繼prototype之后又一個(gè)優(yōu)秀的Javascrīpt框架。jQuery1.6.3之前版本中存在跨站腳本漏洞。當(dāng)使用location.hash選擇元素時(shí).通過特制的標(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)站。攻擊者利用跨站請求偽造能夠輕松地強(qiáng)迫用戶的瀏覽器發(fā)出非故意的HTTP請求.如詐騙性的電匯請求、修改口令和下載非法的內(nèi)容等請求。風(fēng)險(xiǎn)等級(jí)：高風(fēng)險(xiǎn)范圍：任何存在輸入/輸出方法〔包括GET與POST的頁面皆可能存在惡意符號(hào)輸入缺陷.主要影響應(yīng)用包括留言板、在線通訊信息、文章發(fā)布頁面等。3.2整改建議：對用戶輸入的參數(shù)執(zhí)行嚴(yán)格檢測：1、對產(chǎn)生漏洞模塊的傳入?yún)?shù)進(jìn)行有效性檢測。int類型的只允許0-9的整型數(shù)字；string等字符類型的只允許<1-9.a-z.A-Z>的英文字母；2、當(dāng)客戶端輸入限定值意外的字符后.立即轉(zhuǎn)向自定義的錯(cuò)誤頁.而不能使用服務(wù)器默認(rèn)的錯(cuò)誤輸出方式；3、對穿入?yún)?shù)進(jìn)行危險(xiǎn)字符過濾.禁止<'、"、+、%、&、<>、〔、;、,.等>特殊字符的傳入。3.3案例：加固范例〔一：/*將login.jsp中[Stringu=request.getParameter<"u">;]替換為如下內(nèi)容：*/Stringu=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<'+','_'>;加固范例〔二：/*更積極的方式是利用正則表達(dá)式只允許輸入指定的字符：*//*在[Stringu=request.getParameter<"u">;]后代入以下isValidInput函數(shù)作辨別*/publicbooleanisValidInput<Stringstr>{if<str.matches<"[a-z0-9]+">>returntrue;elsereturnfalse;}4.URL重定向釣魚4.13.1問題描述：通過構(gòu)建URL.攻擊者可以使用戶重定向到任意URL.利用這個(gè)漏洞可以誘使用戶訪問某個(gè)頁面.掛馬、密碼記錄、下載任意文件等.常被用來釣魚。4.23.2整改建議：對輸入?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]"〔引號(hào)[9]\'〔反斜杠轉(zhuǎn)義單引號(hào)[10]\"〔反斜杠轉(zhuǎn)義引號(hào)[11]<>〔尖括號(hào)[12]<>〔括號(hào)[13]+〔加號(hào)[14]CR〔回車符.ASCII0x0d[15]LF〔換行.ASCII0x0a[16],〔逗號(hào)[17]\〔反斜杠4.33.3案例：對輸入?yún)?shù)進(jìn)行做處理。加固范例〔一：/*將login.jsp中[Stringu=request.getParameter<"u">;]替換為如下內(nèi)容：*/Stringu=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<'+','_'>;加固范例〔二：/*更積極的方式是利用正則表達(dá)式只允許輸入指定的字符：*//*在[Stringu=request.getParameter<"u">;]后代入以下isValidInput函數(shù)作辨別*/publicbooleanisValidInput<Stringstr>{if<str.matches<"[a-z0-9]+">>returntrue;elsereturnfalse;}5.不安全存儲(chǔ)5.1問題描述不安全存儲(chǔ).在頁面上顯示密碼。5.2整改建議加密密碼或不在頁面及源碼上顯示密碼。5.3案例一切涉及敏感信息讀寫操作的頁面.如登陸頁面、登陸處理頁面等。風(fēng)險(xiǎn)范例：/*Add_user.jsp*/Stringsql;sql="insertintouser<username,password>values<"+Username+","+Password+">";Statementsm=cn.createStatement<>;sm.executeUpdate<sql>;sm.close<>;加固范例：/*在生成sql變量內(nèi)容前加入對Password變量的加密處理：*/<%@pageimport="java.security.*"%><%@pageimport="java.util.*"%>

…publicStringbyte2hex<byte[]b>//二行制轉(zhuǎn)字符串{Stringhs="";Stringstmp="";for<intn=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+":";</p">}returnhs.toUpperCase<>;}

…java.security.MessageDigestalg=java.security.MessageDigest.getInstance<"SHA-256">;alg.update<Password.getBytes<>>;byte[]digest=alg.digest<>;Password=byte2hex<digest>;6.錯(cuò)誤的頁面信息6.1問題描述：錯(cuò)誤/警告消息.可能會(huì)泄露敏感信息。6.2整改建議：在編碼階段開發(fā)者對敏感頁面缺乏授權(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)范例為一切需要敏感但編碼階段沒有進(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">;return;}7.已解密的登陸請求7.1問題描述：用戶名、密碼輸入字段未經(jīng)加密即進(jìn)行了傳遞。7.2整改建議：確保所有登錄請求都以https加密方式發(fā)送到服務(wù)器。7.3案例：方法一：配置SSL加密傳輸[概念理解]keystore是一個(gè)密碼保護(hù)的文件.用來存儲(chǔ)密鑰和證書<1>生成一個(gè)keystore文件〔包含證書.文件位置/usr/local/tomcat/conf/.keystore#cd/usr/local/jdk/bin/#./keytool-genkey-aliastomcat-keyalgRSA-keystore/usr/local/tomcat/conf/.keystore輸入密碼、提供你的信息即可。如果不是用來"玩"的話.請如實(shí)的填寫自己以及單位的信息吧。[注意]它會(huì)在前后問你兩次密碼.第二次直接回車就行了.如果兩個(gè)密碼不一樣.將會(huì)出現(xiàn)java.io.IOException錯(cuò)誤。詳情請見：[url]/bugzilla/show_bug.cgi?id=38217[/url]<2>修改tomcat/conf/server.xml啟用這一段：<=""p="">maxThreads="150"scheme="https"secure="true"clientAuth="false"sslProtocol="TLS"/>并修改為：<=""p="">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]0:8443/[/url]方法二：把text="password"這個(gè)用其他的代替.就可以解決已解密的登錄請求.僅共參考密碼：<=""p=""style="padding:0px;margin:0px;font-size:12px;font-family:宋體;width:146px;height:18px;">nkeypress="javascript：hiddenPass<event>"onkeyup="this.value=this.value.replace</./g,'*'>;"/>js代碼functionhiddenPass<e>{e=e?e:window.event;varkcode=e.which?e.which:e.keyCode;varpass=document.getElementByIdx_x<"password1">;varj_pass=document.getElementByIdx_x<"password">;if<kcode!=8>{varkeychar=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拒絕服務(wù)8.1問題描述HTTP存在DOS漏洞。如果遠(yuǎn)程攻擊者使用發(fā)包工具向Apache服務(wù)器發(fā)送了不完整的HTTP請求.服務(wù)器會(huì)打開連接等待接受完整的頭.但如果發(fā)包工具不再繼續(xù)發(fā)送完整請求而是發(fā)送無效頭的話.就會(huì)一直保持打開的連接。這種攻擊所造成的影響很嚴(yán)重.因?yàn)楣粽卟恍枰l(fā)送很大的通訊就可以耗盡服務(wù)器上的可用連接。也就是說.即使低帶寬的用戶也可以攻擊大流量的服務(wù)器。8.2整改方法臨時(shí)解決方法：更改默認(rèn)的TimeOut選項(xiàng)少于7000ms.或使用mod_limitipconn模塊限制單個(gè)IP地址的連接數(shù)。廠商補(bǔ)?。篈pacheGroup目前廠商還沒有提供補(bǔ)丁或者升級(jí)程序.8.3案例關(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)說明。緩解方法通過server.xml內(nèi)定義的連接器的connectionTimeout屬性.配置一個(gè)合適的超時(shí)時(shí)間。3.但CVE的漏洞還是所有版本也存在。下面是一個(gè)CVE的詳細(xì)信息地址.此頁面最后更新為2013-03-07.當(dāng)時(shí)6.0.35為最新版本。4.公開的漏洞測試代碼9.跨站點(diǎn)請求偽造同"1.HTML表單沒有CSRF保護(hù)"。10.應(yīng)用程序錯(cuò)誤信息同"6.錯(cuò)誤的頁面信息"11.SQL注入11.1問題描述受外部影響的輸入來構(gòu)造SQL命令的全部或一部分.但是它對可能在所需SQL命令發(fā)送到數(shù)據(jù)庫時(shí)修改該命令的特殊元素未正確進(jìn)行無害化處理。如果在用戶可控制的輸入中沒有對SQL語法充分地除去或引用.那么生成的SQL查詢可能會(huì)導(dǎo)致將這些輸入解釋為SQL而不是普通用戶數(shù)據(jù)。這可用于修改查詢邏輯以繞過安全性檢查.或者插入其他用于修改后端數(shù)據(jù)庫的語句.并可能包括執(zhí)行系統(tǒng)命令。11.2整改建議publicstaticStringfilterContent<Stringcontent>{Stringflt="'|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare|;|or|-|+|,";Stringfilter[]=flt.split<"|">;for<inti=0;i<=""p="">{content.replace<filter[i],"">;}returncontent;}12.HTTP版本過低12.1問題描述Apache/IIS等版本過低存在眾多安全漏洞。12.2整改建議升級(jí)Apache/IIS等到最新版本。13.微軟IIS波狀目錄枚舉13.1問題描述攻擊者可以利用"~"字符猜解或遍歷服務(wù)器中的文件名.或?qū)IS服務(wù)器中的.NetFramework進(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問題描述Unicode編碼未指定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ǔ)丁。部分已知的目錄列表問題列在這個(gè)咨詢的"引用"字段中。[3]利用"CERT"咨詢中的變通方法〔在這項(xiàng)咨詢的"引用"字段中來修訂短文件名〔8.3DOS格式問題：a.想要完全由Web服務(wù)器來保護(hù)的文件僅用8.3標(biāo)準(zhǔn)短文件名。在FAT文件系統(tǒng)〔16位上.您可以啟用"Win31FileSystem"注冊表鍵〔設(shè)為1.注冊表路徑：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\來強(qiáng)制這一點(diǎn)。b.在NTFS〔32位上.您可以啟用"NtfsDisable8dot3NameCreation"注冊表鍵〔設(shè)為1.注冊表路徑：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\來禁用創(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整改建議刪除不必要的備份文件。19.ASP.NETpaddingoracl攻擊19.1問題描述使用.NETFramework所編譯的ASP.Net應(yīng)用中沒有正確地實(shí)現(xiàn)加密.攻擊者可以解密并篡改敏感數(shù)據(jù)。如果要理解這個(gè)漏洞.首先要了解加密系統(tǒng)中的提示機(jī)制.當(dāng)你提出問題時(shí)提示機(jī)制會(huì)給出某種形式的答案。此漏洞涉及到ASP.NET對加密信息中填充數(shù)據(jù)的提示.攻擊者可以通過向Web服務(wù)器發(fā)送特定的密文文本.然后通過檢查所返回的出錯(cuò)代碼來判斷數(shù)據(jù)是否被正確解密。通過反復(fù)上述操作.攻擊者就可以收集到足夠的信息用來解密剩余部分的密文文本。19.2整改建議打上MS10-070漏洞補(bǔ)丁。20.用戶得憑證信息以明文發(fā)送20.1問題描述不安全明文傳輸?shù)卿浾埱蟆?0.2整改建議使用SSL加密。21.Web應(yīng)用防火墻檢測從HTTPHTTPS后不安全的過渡形式21.1問題描述不安全明文傳輸方式。21.2整改建議使用所以頁面通過SSL加密。22.struts2漏洞22.1問題描述struts2框架版本過低.存在遠(yuǎn)程任意命令執(zhí)行漏洞。22.2整改建議升級(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ò)誤的輸入加入黑名單。但是.黑名單可幫助檢測潛在攻擊.或者確定哪些輸入格式不正確.以致應(yīng)當(dāng)將其徹底拒絕。執(zhí)行輸入驗(yàn)證時(shí).請考慮所有潛在相關(guān)屬性.包括長度、輸入類型、可接受值的完整范圍、缺失或多余輸入、語法、跨相關(guān)字段的一致性以及業(yè)務(wù)規(guī)則一致性。以業(yè)務(wù)規(guī)則邏輯為例."boat"可能在語法上有效.因?yàn)樗鼉H包含字母數(shù)字字符.但如果預(yù)期為顏色〔如"red"或"blue".那么它無效。對于文件名.請使用限制要使用的字符集的嚴(yán)格白名單。如果可行.請僅允許文件名中出現(xiàn)單個(gè)"."字符以避免CWE-23之類的弱點(diǎn).并排除"/"之類的目錄分隔符以避免CWE-36。請使用允許的文件擴(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證書.加密算法選擇如：RSA-1024等。28.Http請求頭的額外的回車換行符注入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如等代碼3$post=ereg_replace<"\t","",$post>;//去掉制表符號(hào)4$post=ereg_replace<"\r\n","",$post>;//去掉回車換行符號(hào)5$post=ereg_replace<"\r","",$post>;//去掉回車6$post=ereg_replace<"\n","",$post>;//去掉換行7$post=ereg_replace<"","",$post>;//去掉空格8$post=ereg_replace<"'","",$post>;//去掉單引號(hào)29.CRLF注入/HTTP響應(yīng)拆分同上：Http請求頭的額外的回車換行符注入。30.MBean提交密碼字段中使用GET方法30.1問題描述使用GET方法MBean提交密碼字段。30.2整改建議更改為POST提交方法。31.JBoss類漏洞31.1問題描述發(fā)現(xiàn)JBoss框架登錄管理后臺(tái)等信息。31.2整改建議限制JBOSS控制臺(tái)等目錄訪問權(quán)限。32.ApacheTomcat版本低32.1問題描述ApacheTomcat版本過低32.2整改建議升級(jí)ApacheTomcat到最新版本。33.ApacheTomcat類漏洞33.1問題描述發(fā)現(xiàn)存在ApacheTomcat的示例文件、控制臺(tái)等信息。33.2整改建議刪除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整改建議apachecommons-lang工具包里的類.可以在工程中寫一個(gè)過濾器.使用該工具類去實(shí)現(xiàn)敏感字符的過濾。過濾器示例2如下：使用JAVA過濾器對攻擊特征進(jìn)行過濾如：一。寫一個(gè)過濾器代碼如下：packagecom.liufeng.sys.filter;importjava.io.IOException;importjava.io.PrintWriter;importjavax.servlet.Filter;importjavax.servlet.FilterChain;importjavax.servlet.FilterConfig;importjavax.servlet.ServletException;importjavax.servlet.ServletRequest;importjavax.servlet.ServletResponse;importjavax.servlet.http.HttpServletRequest;importjavax.servlet.http.HttpServletResponse;publicclassIllegalCharacterFilterimplementsFilter{privateString[]characterParams=null;privatebooleanK=true;publicvoiddestroy<>{//TODOAuto-generatedmethodstub}/***此程序塊主要用來解決參數(shù)帶非法字符等過濾功能*/publicvoiddoFilter<ServletRequestrequest,ServletResponseresponse,FilterChainarg2>throwsIOException,ServletException{