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

常見WEB安全漏洞及整改建議1.HTML表單沒有CSRF保護(hù)1.1問題描述：

CSRF（Cross-siterequestforgery），中文名稱：跨站請求偽造，也被稱為：oneclickattack/sessionriding，縮寫為：CSRF/XSRF。

CSRF攻擊：攻擊者盜用了你的身份，以你的名義發(fā)送惡意請求。CSRF能夠做的事情包括：以你名義發(fā)送郵件，發(fā)消息，盜取你的賬號，甚至于購買商品，虛擬貨幣轉(zhuǎn)賬……造成的問題包括：個人隱私泄露以及財產(chǎn)安全。1.2整改建議：

CSRF的防御可以從服務(wù)端和客戶端兩方面著手，防御效果是從服務(wù)端著手效果比較好，現(xiàn)在一般的CSRF防御也都在服務(wù)端進(jìn)行。有以下三種方法：

(1).CookieHashing(所有表單都包含同一個偽隨機(jī)值)：

(2).驗證碼

(3).One-TimeTokens(不同的表單包含一個不同的偽隨機(jī)值)1.3案例：

1.服務(wù)端進(jìn)行CSRF防御

服務(wù)端的CSRF方式方法很多樣，但總的思想都是一致的，就是在客戶端頁面增加偽隨機(jī)數(shù)。1.3.1CookieHashing(所有表單都包含同一個偽隨機(jī)值)：

這可能是最簡單的解決方案了，因為攻擊者不能獲得第三方的Cookie(理論上)，所以表單中的數(shù)據(jù)也就構(gòu)造失敗.

//構(gòu)造加密的Cookie信息

$value=“DefenseSCRF”;

setcookie(”cookie”,$value,time()+3600);

?>

在表單里增加Hash值，以認(rèn)證這確實是用戶發(fā)送的請求。

$hash=md5($_COOKIE['cookie']);

?>

”>

然后在服務(wù)器端進(jìn)行Hash值驗證

if(isset($_POST['check'])){

$hash=md5($_COOKIE['cookie']);

if($_POST['check']==$hash){

doJob();

}else{

//…

}

}else{

//…

}

?>

這個方法已經(jīng)可以杜絕99%的CSRF攻擊了，那還有1%….由于用戶的Cookie很容易由于網(wǎng)站的XSS漏洞而被盜取，這就另外的1%。一般的攻擊者看到有需要算Hash值，基本都會放棄了，某些除外，所以如果需要100%的杜絕，這個不是最好的方法。1.3.2驗證碼

這個方案的思路是：每次的用戶提交都需要用戶在表單中填寫一個圖片上的隨機(jī)字符串，這個方案可以完全解決CSRF，但在易用性方面似乎不是太好，還有是驗證碼圖片的使用涉及了一個被稱為MHTML的Bug，可能在某些版本的微軟IE中受影響。1.3.3One-TimeTokens(不同的表單包含一個不同的偽隨機(jī)值)

在實現(xiàn)One-TimeTokens時，需要注意一點：就是“并行會話的兼容”。如果用戶在一個站點上同時打開了兩個不同的表單，CSRF保護(hù)措施不應(yīng)該影響到他對任何表單的提交?？紤]一下如果每次表單被裝入時站點生成一個偽隨機(jī)值來覆蓋以前的偽隨機(jī)值將會發(fā)生什么情況：用戶只能成功地提交他最后打開的表單，因為所有其他的表單都含有非法的偽隨機(jī)值。必須小心操作以確保CSRF保護(hù)措施不會影響選項卡式的瀏覽或者利用多個瀏覽器窗口瀏覽一個站點。

以下實現(xiàn):

1).先是令牌生成函數(shù)(gen_token())：

functiongen_token(){

//這是貪方便，實際上單使用Rand()得出的隨機(jī)數(shù)作為令牌，也是不安全的。

//這個可以參考寫的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之后又一個優(yōu)秀的Javascrīpt框架。

jQuery1.6.3之前版本中存在跨站腳本漏洞。當(dāng)使用location.hash選擇元素時，通過特制的標(biāo)簽，遠(yuǎn)程攻擊者利用該漏洞注入任意web腳本或HTML。2.2整改方法

目前廠商已經(jīng)發(fā)布了升級補(bǔ)丁以修復(fù)此安全問題，補(bǔ)丁獲取鏈接：

/usn/USN-1722-1/2.3整改案例

升級jQuery版本。3.跨站腳本編制3.1問題描述：

跨站腳本攻擊是通過在網(wǎng)頁中加入惡意代碼，當(dāng)訪問者瀏覽網(wǎng)頁時惡意代碼會被執(zhí)行或者通過給管理員發(fā)信息的方式誘使管理員瀏覽，從而獲得管理員權(quán)限，控制整個網(wǎng)站。攻擊者利用跨站請求偽造能夠輕松地強(qiáng)迫用戶的瀏覽器發(fā)出非故意的HTTP請求，如詐騙性的電匯請求、修改口令和下載非法的內(nèi)容等請求。

風(fēng)險等級：高

風(fēng)險范圍：

任何存在輸入/輸出方法（包括GET與POST）的頁面皆可能存在惡意符號輸入缺陷，主要影響應(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)向自定義的錯誤頁，而不能使用服務(wù)器默認(rèn)的錯誤輸出方式；

3、對穿入?yún)?shù)進(jì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，利用這個漏洞可以誘使用戶訪問某個頁面，掛馬、密碼記錄、下載任意文件等，常被用來釣魚。4.23.2整改建議：

對輸入?yún)?shù)進(jìn)行做處理，建議過濾出所有以下字符：

[1]|（豎線符號）

[2]&（&符號）

[3];（分號）

[4]$（美元符號）

[5]%（百分比符號）

[6]@（at符號）

[7]'（單引號）

[8]"（引號）

[9]\'（反斜杠轉(zhuǎn)義單引號）

[10]\"（反斜杠轉(zhuǎn)義引號）

[11]<>（尖括號）

[12]()（括號）

[13]+（加號）

[14]CR（回車符，ASCII0x0d）

[15]LF（換行，ASCII0x0a）

[16],（逗號）

[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.不安全存儲5.1問題描述

不安全存儲，在頁面上顯示密碼。5.2整改建議

加密密碼或不在頁面及源碼上顯示密碼。5.3案例

一切涉及敏感信息讀寫操作的頁面，如登陸頁面、登陸處理頁面等。

風(fēng)險范例：

/*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.錯誤的頁面信息6.1問題描述：

錯誤/警告消息，可能會泄露敏感信息。6.2整改建議：

在編碼階段開發(fā)者對敏感頁面缺乏授權(quán)保護(hù)，導(dǎo)致相關(guān)URL頁面敏感信息泄露。建議修改錯誤信息。

一切敏感或需要權(quán)限方可瀏覽的頁面，包括：敏感信息中轉(zhuǎn)處理頁面、上傳頁面、管理平臺頁面、用戶自管理頁面等。6.3案例：

風(fēng)險范例：

/*風(fēng)險范例為一切需要敏感但編碼階段沒有進(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是一個密碼保護(hù)的文件，用來存儲密鑰和證書

(1)生成一個keystore文件（包含證書），文件位置/usr/local/tomcat/conf/.keystore

#cd/usr/local/jdk/bin/

#./keytool-genkey-alias

tomcat

-keyalgRSA-keystore/usr/local/tomcat/conf/.keystore

輸入密碼、提供你的信息即可。如果不是用來“玩”的話，請如實的填寫自己以及單位的信息吧。

【注意】它會在前后問你兩次密碼，第二次直接回車就行了，如果兩個密碼不一樣，將會出現(xiàn)java.io.IOException錯誤。詳情請見：[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"這個用其他的代替，就可以解決已解密的登錄請求，僅共參考

·密

碼：<=""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ù)器會打開連接等待接受完整的頭，但如果發(fā)包工具不再繼續(xù)發(fā)送完整請求而是發(fā)送無效頭的話，就會一直保持打開的連接。這種攻擊所造成的影響很嚴(yán)重，因為攻擊者不需要發(fā)送很大的通訊就可以耗盡服務(wù)器上的可用連接。也就是說，即使低帶寬的用戶也可以攻擊大流量的服務(wù)器。8.2整改方法

臨時解決方法：

更改默認(rèn)的TimeOut選項少于7000ms，或使用mod_limitipconn模塊限制單個IP地址的連接數(shù)。

廠商補(bǔ)?。?/p>

ApacheGroup

目前廠商還沒有提供補(bǔ)丁或者升級程序，我們建議使用此軟件的用戶隨時關(guān)注廠商的主頁以獲取最新版本：8.3案例

關(guān)于HTTP版本低漏洞信息，如下：

1）.漏洞的描述

/NewsInfo/124/17205.Html

2）.TOMCAT官網(wǎng)說這個不是一個漏洞，沒有打算出補(bǔ)丁，只有緩解方法

詳細(xì)可以看，

http:///security-6.html#Not_a_vulnerability_in_Tomcat

查找CVE-2012-5568會看到官網(wǎng)說明。

緩解方法

通過server.xml內(nèi)定義的連接器的connectionTimeout屬性，配置一個合適的超時時間。

/jyrivirkki/entry/web_server_7_meets_slowloris

3）.但CVE的漏洞還是所有版本也存在。下面是一個CVE的詳細(xì)信息地址，此頁面最后更新為2013-03-07，當(dāng)時6.0.35為最新版本。

/cve-details.php?t=1&cve_id=CVE-2012-5568

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

/slowloris/slowloris.pl9.跨站點請求偽造

同“1.HTML表單沒有CSRF保護(hù)”。10.應(yīng)用程序錯誤信息

同“6.錯誤的頁面信息”11.SQL注入11.1問題描述

受外部影響的輸入來構(gòu)造SQL命令的全部或一部分，但是它對可能在所需SQL命令發(fā)送到數(shù)據(jù)庫時修改該命令的特殊元素未正確進(jìn)行無害化處理。如果在用戶可控制的輸入中沒有對SQL語法充分地除去或引用，那么生成的SQL查詢可能會導(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;

}

參考信息：/index.php/Top_10_2010-A112.HTTP版本過低12.1問題描述

Apache/IIS等版本過低存在眾多安全漏洞。12.2整改建議

升級Apache/IIS等到最新版本。13.微軟IIS波狀目錄枚舉13.1問題描述

攻擊者可以利用“~”字符猜解或遍歷服務(wù)器中的文件名，或?qū)IS服務(wù)器中的.NetFramework進(jìn)行拒絕服務(wù)攻擊。13.2整改建議

升級netframework至4.0以上版本。14.未加密的__VIEWSTATE的參數(shù)14.1問題描述

可能會收集有關(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問題描述

可能會查看和下載特定Web應(yīng)用程序虛擬目錄的內(nèi)容，其中可能包含受限文件。17.2整改建議

[1]將Web服務(wù)器配置成拒絕列出目錄。

[2]根據(jù)Web服務(wù)器或Web應(yīng)用程序上現(xiàn)有的問題來下載特定安全補(bǔ)丁。部分已知的目錄列表問題列在這個咨詢的“引用”字段中。

[3]利用“CERT”咨詢中的變通方法（在這項咨詢的“引用”字段中）來修訂短文件名（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)制這一點。

b.在NTFS（32位）上，您可以啟用“NtfsDisable8dot3NameCreation”注冊表鍵（設(shè)為1，注冊表路徑：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\）來禁用創(chuàng)建長文件名文件的8.3標(biāo)準(zhǔn)短文件名。不過，這個步驟可能會引起與16位應(yīng)用程序的兼容性問題。

c.使用基于NTFS的ACL（目錄或文件級別的訪問控制表）來擴(kuò)增或替換基于Web服務(wù)器的安全。18.備份文件18.1問題描述

存在不必要的備份殘留文件，可能會被信息采集進(jìn)入步深入滲透。18.2整改建議

刪除不必要的備份文件。19.ASP.NETpaddingoracl攻擊19.1問題描述

使用.NETFramework所編譯的ASP.Net應(yīng)用中沒有正確地實現(xiàn)加密，攻擊者可以解密并篡改敏感數(shù)據(jù)。

如果要理解這個漏洞，首先要了解加密系統(tǒng)中的提示機(jī)制，當(dāng)你提出問題時提示機(jī)制會給出某種形式的答案。此漏洞涉及到ASP.NET對加密信息中填充數(shù)據(jù)的提示，攻擊者可以通過向Web服務(wù)器發(fā)送特定的密文文本，然后通過檢查所返回的出錯代碼來判斷數(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整改建議

升級struts2框架到最新版本。23.弱口令23.1問題描述

使用如：123456、test等弱口令。23.2整改建議

按電信密碼規(guī)范要求配置口令。24.文件包含24.1問題描述

可能會在Web服務(wù)器上運(yùn)行遠(yuǎn)程命令。這通常意味著完全破壞服務(wù)器及其內(nèi)容。24.2整改建議

假定所有輸入都是惡意的。使用“接受已知善意”輸入驗證策略：嚴(yán)格遵守規(guī)范的可接受輸入的白名單。拒絕任何沒有嚴(yán)格遵守規(guī)范的輸入，或者將其轉(zhuǎn)換為遵守規(guī)范的內(nèi)容。不要完全依賴于將惡意或格式錯誤的輸入加入黑名單。但是，黑名單可幫助檢測潛在攻擊，或者確定哪些輸入格式不正確，以致應(yīng)當(dāng)將其徹底拒絕。

執(zhí)行輸入驗證時，請考慮所有潛在相關(guān)屬性，包括長度、輸入類型、可接受值的完整范圍、缺失或多余輸入、語法、跨相關(guān)字段的一致性以及業(yè)務(wù)規(guī)則一致性。以業(yè)務(wù)規(guī)則邏輯為例，“boat”可能在語法上有效，因為它僅包含字母數(shù)字字符，但如果預(yù)期為顏色（如“red”或“blue”），那么它無效。

對于文件名，請使用限制要使用的字符集的嚴(yán)格白名單。如果可行，請僅允許文件名中出現(xiàn)單個“.”字符以避免CWE-23之類的弱點，并排除“/”之類的目錄分隔符以避免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頭。例如，攻擊者可以注入會話cookie或HTML代碼。這可能會進(jìn)行類似的XSS(跨站點腳本)或會話固定漏洞。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);//去掉制表符號

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響應(yīng)拆分

同上：Http請求頭的額外的回車換行符注入。30.MBean提交密碼字段中使用GET方法30.1問題描述

使用GET方法MBean提交密碼字段。30.2整改建議

更改為POST提交方法。31.JBoss類漏洞31.1問題描述

發(fā)現(xiàn)JBoss框架登錄管理后臺等信息。31.2整改建議

限制JBOSS控制臺等目錄訪問權(quán)限。32.ApacheTomcat版本低32.1問題描述

ApacheTomcat版本過低32.2整改建議

升級ApacheTomcat到最新版本。33.ApacheTomcat類漏洞33.1問題描述

發(fā)現(xiàn)存在ApacheTomcat的示例文件、控制臺等信息。33.2整改建議

刪除ApacheTomcat的示例文件及控制臺相關(guān)文件。34.臨時應(yīng)急加固方法35.非公眾訪問類35.1問題描述

發(fā)現(xiàn)系統(tǒng)、數(shù)據(jù)庫類等漏洞沒法加固或暫時無法加固。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工具包里的類，可以在工程中寫一個過濾器，使用該工具類去實現(xiàn)敏感字符的過濾。

過濾器示例1參考地址：/mousai/blog/88832

過濾器示例2如下：

使用JAVA過濾器對攻擊特征進(jìn)行過濾如：

一。寫一個過濾器

代碼如下：

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(){

//T