常見WEB開發(fā)安全漏洞原因分析及解決

目錄1 會(huì)話標(biāo)識未更新 31.1 原因 31.2 解決 32 SQL注入 32.1 原因 32.2 解決 53 XSS跨站腳本編制 53.1 原因 53.2 解決 54 XSRF跨站請求偽造 74.1 原因 74.2 解決 85 登錄錯(cuò)誤消息憑證枚舉（不充分帳戶封鎖） 85.1 原因 85.2 解決 96 HTML注釋敏感信息泄露 96.1 原因 96.2 解決 97 應(yīng)用程序錯(cuò)誤 97.1 原因 97.2 解決 98 已解密的登錄請求 98.1 原因 98.2 解決 99 啟用了不安全的HTTP方法 109.1 原因 109.2 解決 1010 禁止頁面緩存 1110.1 原因 1110.2 解決 1111 數(shù)據(jù)庫錯(cuò)誤模式 1111.1 原因 1111.2 解決 12

會(huì)話標(biāo)識未更新原因在用戶進(jìn)入登錄頁面，但還未登錄時(shí)，就已經(jīng)產(chǎn)生了一個(gè)session，用戶輸入信息，登錄以后，session的id不會(huì)改變，也就是說還是以前的那個(gè)session（事實(shí)上session也確實(shí)不會(huì)改變，因?yàn)闆]有建立新session，原來的session也沒有被銷毀）。很多人只是讓會(huì)話invalidate沒有用（request.getSession().invalidate();），是因?yàn)閕nvalidate方法不是真正的將session銷毀，只是將session中的內(nèi)容清空，所以當(dāng)invalidate以后再新建session，新建的session其實(shí)不是新的，是將之前的session重新啟用了。于是session的id不變就不奇怪了。只有cookie失效掉，才能換成新的sessionid解決在登錄頁面上加上一段代碼：request.getSession().invalidate();//清空sessionif(request.getCookies()!=null){

Cookiecookie=request.getCookies()[0];//獲取cookie

cookie.setMaxAge(0);//讓cookie過期

}注：會(huì)話失效后，請不要在代碼前面使用SESSION保存數(shù)據(jù)。SQL注入原因沒有正確過濾轉(zhuǎn)義字符在用戶的輸入沒有為轉(zhuǎn)義字符過濾時(shí)，就會(huì)發(fā)生這種形式的注入式攻擊，它會(huì)被傳遞給一個(gè)SQL語句。這樣就會(huì)導(dǎo)致應(yīng)用程序的終端用戶對數(shù)據(jù)庫上的語句實(shí)施操縱。比方說，下面的這行代碼就會(huì)演示這種漏洞：statement:="SELECT*FROMusersWHEREname='"+userName+"';"將用戶名變量(即username)設(shè)置為：a'or't'='t，此時(shí)原始語句發(fā)生了變化.用戶輸入錯(cuò)誤的數(shù)據(jù)類型如果一個(gè)用戶提供的字段并非一個(gè)強(qiáng)類型，或者沒有實(shí)施類型強(qiáng)制，就會(huì)發(fā)生這種形式的攻擊。當(dāng)在一個(gè)SQL語句中使用一個(gè)數(shù)字字段時(shí)，如果程序員沒有檢查用戶輸入的合法性(是否為數(shù)字型)就會(huì)發(fā)生這種攻擊。例如：statement:="SELECT*FROMdataWHEREid="+a_variable+";"從這個(gè)語句可以看出，作者希望a_variable是一個(gè)與“id”字段有關(guān)的數(shù)字。不過，如果終端用戶選擇一個(gè)字符串，就繞過了對轉(zhuǎn)義字符的需要。例如，將a_variable設(shè)置為:1;DROPTABLEusers，它會(huì)將“users”表從數(shù)據(jù)庫中刪除，SQL語句變成：SELECT*FROMDATAWHEREid=1;DROPTABLEusers;數(shù)據(jù)庫服務(wù)器中的漏洞有時(shí)，數(shù)據(jù)庫服務(wù)器軟件中也存在著漏洞，如MYSQL服務(wù)器中mysql_real_escape_string()函數(shù)漏洞。這種漏洞允許一個(gè)攻擊者根據(jù)錯(cuò)誤的統(tǒng)一字符編碼執(zhí)行一次成功的SQL注入式攻擊。盲目SQL注入式攻擊當(dāng)一個(gè)Web應(yīng)用程序易于遭受攻擊而其結(jié)果對攻擊者卻不見時(shí)，就會(huì)發(fā)生所謂的盲目SQL注入式攻擊。有漏洞的網(wǎng)頁可能并不會(huì)顯示數(shù)據(jù)，而是根據(jù)注入到合法語句中的邏輯語句的結(jié)果顯示不同的內(nèi)容。這種攻擊相當(dāng)耗時(shí)，因?yàn)楸仨殲槊恳粋€(gè)獲得的字節(jié)而精心構(gòu)造一個(gè)新的語句。但是一旦漏洞的位置和目標(biāo)信息的位置被確立以后，一種稱為Absinthe的工具就可以使這種攻擊自動(dòng)化。條件響應(yīng)注意，有一種SQL注入迫使數(shù)據(jù)庫在一個(gè)普通的應(yīng)用程序屏幕上計(jì)算一個(gè)邏輯語句的值：SELECTbooktitleFROMbooklistWHEREbookId='OOk14cd'AND1=1這會(huì)導(dǎo)致一個(gè)標(biāo)準(zhǔn)的面面，而語句SELECTbooktitleFROMbooklistWHEREbookId='OOk14cd'AND1=2在頁面易于受到SQL注入式攻擊時(shí)，它有可能給出一個(gè)不同的結(jié)果。如此這般的一次注入將會(huì)證明盲目的SQL注入是可能的，它會(huì)使攻擊者根據(jù)另外一個(gè)表中的某字段內(nèi)容設(shè)計(jì)可以評判真?zhèn)蔚恼Z句。條件性差錯(cuò)如果WHERE語句為真，這種類型的盲目SQL注入會(huì)迫使數(shù)據(jù)庫評判一個(gè)引起錯(cuò)誤的語句，從而導(dǎo)致一個(gè)SQL錯(cuò)誤。例如：SELECT1/0FROMusersWHEREusername='Ralph'。顯然，如果用戶Ralph存在的話，被零除將導(dǎo)致錯(cuò)誤。時(shí)間延誤時(shí)間延誤是一種盲目的SQL注入，根據(jù)所注入的邏輯，它可以導(dǎo)致SQL引擎執(zhí)行一個(gè)長隊(duì)列或者是一個(gè)時(shí)間延誤語句。攻擊者可以衡量頁面加載的時(shí)間，從而決定所注入的語句是否為真。解決用預(yù)編譯處理語言要防御SQL注入，用戶的輸入就絕對不能直接被嵌入到SQL語句中。恰恰相反，用戶的輸入必須進(jìn)行過濾，或者使用參數(shù)化的語句。參數(shù)化的語句使用參數(shù)而不是將用戶輸入嵌入到語句中。在多數(shù)情況中，SQL語句就得以修正。然后，用戶輸入就被限于一個(gè)參數(shù)。下面是一個(gè)使用Java和JDBCAPI例子：PreparedStatementprep=conn.prepareStatement("SELECT*FROMUSERSWHEREPASSWORD=?");prep.setString(1,pwd);總體上講，有兩種方法可以保證應(yīng)用程序不易受到SQL注入的攻擊，一是使用代碼復(fù)查，二是強(qiáng)迫使用參數(shù)化語句的。強(qiáng)迫使用參數(shù)化的語句意味著嵌入用戶輸入的SQL語句在運(yùn)行時(shí)將被拒絕。軌范出錯(cuò)處理防范SQL注入，還要避免出現(xiàn)一些詳細(xì)的錯(cuò)誤消息，因?yàn)楹诳蛡兛梢岳眠@些消息。要使用一種標(biāo)準(zhǔn)的輸入確認(rèn)機(jī)制來驗(yàn)證所有的輸入數(shù)據(jù)的長度、類型、語句、企業(yè)規(guī)則等。使用專業(yè)的漏洞掃描工具但防御SQL注入攻擊也是不夠的。攻擊者們目前正在自動(dòng)搜索攻擊目標(biāo)并實(shí)施攻擊。其技術(shù)甚至可以輕易地被應(yīng)用于其它的Web架構(gòu)中的漏洞。企業(yè)應(yīng)當(dāng)投資于一些專業(yè)的漏洞掃描工具，如大名鼎鼎的Acunetix的Web漏洞掃描程序等。一個(gè)完善的漏洞掃描程序不同于網(wǎng)絡(luò)掃描程序，它專門查找網(wǎng)站上的SQL注入式漏洞。最新的漏洞掃描程序可以查找最新發(fā)現(xiàn)的漏洞。XSS跨站腳本編制原因它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當(dāng)用戶瀏覽該頁之時(shí)，嵌入其中Web里面的html代碼會(huì)被執(zhí)行，從而達(dá)到惡意用戶的特殊目的。XSS屬于被動(dòng)式的攻擊，因?yàn)槠浔粍?dòng)且不好利用，所以許多人常忽略其危害性。解決在防止這類問題時(shí)，輸入內(nèi)容的轉(zhuǎn)義效果遠(yuǎn)比內(nèi)容過濾要好。具體實(shí)施可以增加一個(gè)request的轉(zhuǎn)碼過濾器。代碼：packagecom.apusic.portal.sso;importjava.io.IOException;

importjavax.servlet.Filter;

importjavax.servlet.FilterChain;

importjavax.servlet.FilterConfig;

importjavax.servlet.ServletException;

importjavax.servlet.ServletRequest;

importjavax.servlet.ServletResponse;

importjavax.servlet.http.*;

importjava.util.*;/**

*ServletFilterimplementationclassSqlEscapeFilter

*/

publicclassSqlEscapeFilterimplementsFilter{

/**

*Defaultconstructor.

*/

publicSqlEscapeFilter(){

//TODOAuto-generatedconstructorstub

}

/**

*@seeFilter#destroy()

*/

publicvoiddestroy(){

//TODOAuto-generatedmethodstub

}

/**

*@seeFilter#doFilter(ServletRequest,ServletResponse,FilterChain)

*/

publicvoiddoFilter(ServletRequestrequest,ServletResponseresponse,FilterChainchain)throwsIOException,ServletException{

//TODOAuto-generatedmethodstub

//placeyourcodehere

HttpServletRequesthreq=(HttpServletRequest)request;

Mapmap=hreq.getParameterMap();

Iteratoritr=map.keySet().iterator();

while(itr.hasNext())

{

Stringkey=itr.next().toString();

String[]values=hreq.getParameterValues(key);

if(values!=null)

{

for(inti=0;i<values.length;i++)

{

values[i]=cleanXSS(values[i]);

}

}

hreq.setAttribute(key,values);

}

//passtherequestalongthefilterchain

chain.doFilter(request,response);

}

/**

*@seeFilter#init(FilterConfig)

*/

publicvoidinit(FilterConfigfConfig)throwsServletException{

//TODOAuto-generatedmethodstub

}

privateStringcleanXSS(Stringvalue)

{

value=value.replaceAll("<","<").replaceAll(">",">");

value=value.replaceAll("\\(","(").replaceAll("\\)",")");

value=value.replaceAll("'","'");

value=value.replaceAll("eval\\((.*)\\)","");

value=value.replaceAll("[\\\"\\\'][\\s]*javascript:(.*)[\\\"\\\']","\"\"");

value=value.replaceAll("script","");

returnvalue;

}}配置應(yīng)用中的web.xmlWeb.xml:<filter>

<display-name>SqlEscapeFilter</display-name>

<filter-name>SqlEscapeFilter</filter-name>

<filter-class>com.apusic.portal.sso.SqlEscapeFilter</filter-class>

</filter><filter-mapping>

<filter-name>SqlEscapeFilter</filter-name>

<url-pattern>*.jsp</url-pattern>

</filter-mapping>XSRF跨站請求偽造原因CSRF利用方式比較類似XSS(跨站腳本CrossSiteScripting),不過不同的是CSRF是構(gòu)造一個(gè)提交來讓其他人訪問后,利用站點(diǎn)對這些人的信任來進(jìn)行一些所期望的操作.比如:A和B在同一個(gè)有XSS漏洞的站點(diǎn)C,B登錄過D站點(diǎn),并且有這個(gè)D站點(diǎn)的Cookies,這時(shí)候如果A構(gòu)造一個(gè)CSRF,內(nèi)容為給A在D站點(diǎn)的賬戶轉(zhuǎn)移一些虛擬幣,如果這時(shí)候在C站點(diǎn)瀏覽的B用戶打開了A構(gòu)造的含有CSRF的頁面,這時(shí)候B的D站點(diǎn)用戶會(huì)因?yàn)閷用戶的信任而進(jìn)行給A轉(zhuǎn)賬的操作.解決此類攻擊的情景相對的比較復(fù)雜，具體解決可以參考以下5點(diǎn)：第一：限制驗(yàn)證cookie的到期時(shí)間。這些cookie的合法時(shí)間越短，黑客利用你的Web應(yīng)用程序的機(jī)會(huì)就越小。不過，這個(gè)時(shí)間越短，用戶就越不方便。因此，你需要在安全性和方便性之間進(jìn)行平衡。第二：執(zhí)行重要業(yè)務(wù)之前，要求用戶提交額外的信息。要求用戶在進(jìn)行重要業(yè)務(wù)前輸入口令，這可以防止黑客發(fā)動(dòng)CSRF攻擊(只要瀏覽器中沒有包含口令)，因?yàn)檫@種重要信息無法預(yù)測或輕易獲得。第三：使用秘密的無法預(yù)測的驗(yàn)證符號。當(dāng)保存在用戶瀏覽器中的cookie僅由一次會(huì)話確認(rèn)時(shí)，CSRF攻擊才會(huì)有效。所以在每次HTTP請求(當(dāng)然攻擊者無法提前知道)中都有附加的特定會(huì)話的信息，這樣就可以挫敗CSRF攻擊。不過，如果這種應(yīng)用程序存在跨站腳本漏洞，黑客就有可能訪問這種驗(yàn)證符號。第四：使用定制的HTTP報(bào)頭。如果執(zhí)行交易的所有請求都使用XMLHttpRequest并附加一個(gè)定制的HTTP報(bào)頭，同時(shí)拒絕缺少定制報(bào)頭的任何請求，就可以用XMLHttpRequestAPI來防御CSRF攻擊。由于瀏覽器通常僅準(zhǔn)許站點(diǎn)將定制的HTTP報(bào)頭發(fā)送給相同站點(diǎn)，從而了防止由CSRF攻擊的源站點(diǎn)所發(fā)起的交易。第五：檢查訪問源的報(bào)頭。在瀏覽者發(fā)送HTTP請求時(shí)，它通常會(huì)包含源自訪問源報(bào)頭的URL。理論上講，你可以使用這些信息來阻止源自其它任何站點(diǎn)(而不是來自Web應(yīng)用程序自身)的請求。綜合公司以往平臺(tái)報(bào)出此類漏洞產(chǎn)出的原因，基本上都可以通過以下簡單做法加以解決：在請求后面加上一次性令牌。如驗(yàn)證碼，手機(jī)短信驗(yàn)證，或者sessionID等。登錄錯(cuò)誤消息憑證枚舉（不充分帳戶封鎖）原因當(dāng)試圖利用不正確的憑證來登錄時(shí)，當(dāng)用戶輸入無效的用戶名和無效的密碼時(shí)，應(yīng)用程序會(huì)分別生成不同的錯(cuò)誤消息。通過利用該行為攻擊者可以通過反復(fù)試驗(yàn)，加暴力破解來發(fā)現(xiàn)應(yīng)用程序的有效用戶名、再繼續(xù)嘗試發(fā)現(xiàn)相關(guān)聯(lián)的密碼。解決不論用戶名或密碼出現(xiàn)問題都提示同樣的錯(cuò)誤，且同時(shí)加上登陸失敗次數(shù)達(dá)到規(guī)定次數(shù)，則執(zhí)行帳戶鎖定功能。HTML注釋敏感信息泄露原因頁面源代碼不正確的注釋方式。解決將html中有關(guān)密碼之類的敏感注釋去掉或者用<%---%>隱式注釋。應(yīng)用程序錯(cuò)誤原因未執(zhí)行驗(yàn)證，可能輸入?yún)?shù)數(shù)據(jù)類型不匹配。解決實(shí)行嚴(yán)格的數(shù)據(jù)類型驗(yàn)證。已解密的登錄請求原因AppScan的推理是“AppScan識別了不是通過SSL發(fā)送的密碼參數(shù)。解決第一：采用基于SSL的HTTPS傳輸協(xié)議第二：對敏感信息加密并繞過掃描（只要不是采用SSL安全認(rèn)證即使加密了但是AppScan還是會(huì)掃描出來）<inputtype="text"id="password1"style="width:195px;height:25px;line-height:25px;border:solid1px#89B4D6;color:#999"value="10086密碼"onfocus="javascript:clearPass();"onkeyup="this.value=this.value.replace(/./g,'*');"onkeypress="javascript:hiddenPass()"/><inputid="password"type="hidden"name="password"class="inputs_dl"value=""/>將type為password的改為text,然后用JS做一個(gè)假的密碼輸入框，AppScan會(huì)掃描type為password的控件。functionhiddenPass(){varpass=document.getElementById("password1"); varj_pass=document.getElementById("password"); if(event.keyCode==13){ check(); } varkeycode=event.keyCode;varkeychar=String.fromCharCode(keycode); j_pass.value=j_pass.value+keychar; j_pass.value=j_pass.value.substring(0,pass.length); }functionclearPass(){$("#password1").val("");$("#password").val("");}然后傳輸密碼的時(shí)候加個(gè)密：password=base64encode(password);啟用了不安全的HTTP方法原因除標(biāo)準(zhǔn)的GET與POST方法外，HTTP請求還使用其他各種方法。許多這類方法主要用于完成不常見與特殊的任務(wù)。如果低權(quán)限用戶可以訪問這些方法，他們就能夠以此向應(yīng)用程序?qū)嵤┯行Ч?。以下是一些值得注意的方法：PUT，向指定的目錄上傳附加文件；DELETE，刪除指定的資源；COPY，將指定的資源復(fù)制到Destination消息頭指定的位置；MOVE，將指定的資源移動(dòng)到Destination消息頭指定的位置；SEARCH，在一個(gè)目錄路徑中搜索資源。PROPFIND，獲取與指定資源有關(guān)的信息，如作者、大小與內(nèi)容類型。TRACE，在響應(yīng)中返回服務(wù)器收到的原始請求。可以使用這種方法避開阻止跨站點(diǎn)腳本的防御解決如何禁止DELETE、PUT、OPTIONS、TRACE、HEAD等協(xié)議訪問應(yīng)用程序應(yīng)用程序呢？解決方法第一步：修改應(yīng)用程序的web.xml文件的協(xié)議<?xmlversion="1.0"encoding="UTF-8"?><web-appxmlns="/xml/ns/j2ee"xmlns:xsi="/2001/XMLSchema-instance"xsi:schemaLocation="/xml/ns/j2ee/web-app_2_4.xsd"version="2.4">第二步：在應(yīng)用程序的web.xml中添加如下的代碼即可<security-constraint><web-resource-collection><url-pattern>/*</url-pattern><http-method>PUT</http-method><http-method>DELETE</http-method><http-method>HEAD</http-method><http-method>OPTIONS</http-method><http-method>TRACE</http-method></web-resource-collection><auth-constraint></auth-constraint></security-constraint><login-config><auth-method>BASIC</auth-method></login-config>禁止頁面緩存原因能夠訪問到緩存的脫機(jī)數(shù)據(jù)導(dǎo)致泄密。解決建議在web管理后臺(tái)程序的過濾器里增加如下代碼：

response.setHeader("Cache-Control","no-cache");

//只是請求或響應(yīng)消息不緩存

response.setHeader("Cache-Control","no-store");//在請求消息中發(fā)送將使得請求和響應(yīng)消息都不使用緩存

response.setDateHeader("Expires",0);//緩存距離過期的時(shí)間為0毫秒，即緩存立即過期

response.setHeader("Pragma","no-cache");//頁面不緩存數(shù)據(jù)庫錯(cuò)誤模式原因主要是一些數(shù)據(jù)連接錯(cuò)誤信息，通過提交特殊構(gòu)造的字符，程序會(huì)暴露一些數(shù)據(jù)庫信息，也容易引起SQL注入攻擊?，F(xiàn)有平臺(tái)發(fā)現(xiàn)的例子：<h