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

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

…publicStringbyte2hex<byte[]b>//二行制轉字符串{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ā)者對敏感頁面缺乏授權保護.導致相關URL頁面敏感信息泄露。建議修改錯誤信息。一切敏感或需要權限方可瀏覽的頁面.包括：敏感信息中轉處理頁面、上傳頁面、管理平臺頁面、用戶自管理頁面等。6.3案例：風險范例：/*風險范例為一切需要敏感但編碼階段沒有進行授權鑒別的頁面*/加固范例：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)加密即進行了傳遞。7.2整改建議：確保所有登錄請求都以https加密方式發(fā)送到服務器。7.3案例：方法一：配置SSL加密傳輸[概念理解]keystore是一個密碼保護的文件.用來存儲密鑰和證書<1>生成一個keystore文件〔包含證書.文件位置/usr/local/tomcat/conf/.keystore#cd/usr/local/jdk/bin/#./keytool-genkey-aliastomcat-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拒絕服務8.1問題描述HTTP存在DOS漏洞。如果遠程攻擊者使用發(fā)包工具向Apache服務器發(fā)送了不完整的HTTP請求.服務器會打開連接等待接受完整的頭.但如果發(fā)包工具不再繼續(xù)發(fā)送完整請求而是發(fā)送無效頭的話.就會一直保持打開的連接。這種攻擊所造成的影響很嚴重.因為攻擊者不需要發(fā)送很大的通訊就可以耗盡服務器上的可用連接。也就是說.即使低帶寬的用戶也可以攻擊大流量的服務器。8.2整改方法臨時解決方法：更改默認的TimeOut選項少于7000ms.或使用mod_limitipconn模塊限制單個IP地址的連接數(shù)。廠商補?。篈pacheGroup目前廠商還沒有提供補丁或者升級程序.8.3案例關于HTTP版本低漏洞信息.如下：1.漏洞的描述2.TOMCAT官網(wǎng)說這個不是一個漏洞.沒有打算出補丁.只有緩解方法詳細可以看./security-6.html#Not_a_vulnerability_in_Tomcat查找CVE-2012-5568會看到官網(wǎng)說明。緩解方法通過server.xml內定義的連接器的connectionTimeout屬性.配置一個合適的超時時間。3.但CVE的漏洞還是所有版本也存在。下面是一個CVE的詳細信息地址.此頁面最后更新為2013-03-07.當時6.0.35為最新版本。4.公開的漏洞測試代碼9.跨站點請求偽造同"1.HTML表單沒有CSRF保護"。10.應用程序錯誤信息同"6.錯誤的頁面信息"11.SQL注入11.1問題描述受外部影響的輸入來構造SQL命令的全部或一部分.但是它對可能在所需SQL命令發(fā)送到數(shù)據(jù)庫時修改該命令的特殊元素未正確進行無害化處理。如果在用戶可控制的輸入中沒有對SQL語法充分地除去或引用.那么生成的SQL查詢可能會導致將這些輸入解釋為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整改建議升級Apache/IIS等到最新版本。13.微軟IIS波狀目錄枚舉13.1問題描述攻擊者可以利用"~"字符猜解或遍歷服務器中的文件名.或對IIS服務器中的.NetFramework進行拒絕服務攻擊。13.2整改建議升級netframework至4.0以上版本。14.未加密的__VIEWSTATE的參數(shù)14.1問題描述可能會收集有關Web應用程序的敏感信息.如用戶名、密碼、機器名和/或敏感文件位置。14.2整改建議在Web.Config文件的元素之下.添加下面這一行：15.Unicode轉換問題15.1問題描述Unicode編碼未指定15.2整改建議在源碼內指定編碼類型即可解決如：UTF-816.證書泄漏16.1問題描述發(fā)現(xiàn)SSL證書信息16.2整改建議使用公認第三方如CA的簽名證書。17.目錄列表17.1問題描述可能會查看和下載特定Web應用程序虛擬目錄的內容.其中可能包含受限文件。17.2整改建議[1]將Web服務器配置成拒絕列出目錄。[2]根據(jù)Web服務器或Web應用程序上現(xiàn)有的問題來下載特定安全補丁。部分已知的目錄列表問題列在這個咨詢的"引用"字段中。[3]利用"CERT"咨詢中的變通方法〔在這項咨詢的"引用"字段中來修訂短文件名〔8.3DOS格式問題：a.想要完全由Web服務器來保護的文件僅用8.3標準短文件名。在FAT文件系統(tǒng)〔16位上.您可以啟用"Win31FileSystem"注冊表鍵〔設為1.注冊表路徑：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\來強制這一點。b.在NTFS〔32位上.您可以啟用"NtfsDisable8dot3NameCreation"注冊表鍵〔設為1.注冊表路徑：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\來禁用創(chuàng)建長文件名文件的8.3標準短文件名。不過.這個步驟可能會引起與16位應用程序的兼容性問題。c.使用基于NTFS的ACL〔目錄或文件級別的訪問控制表來擴增或替換基于Web服務器的安全。18.備份文件18.1問題描述存在不必要的備份殘留文件.可能會被信息采集進入步深入滲透。18.2整改建議刪除不必要的備份文件。19.ASP.NETpaddingoracl攻擊19.1問題描述使用.NETFramework所編譯的ASP.Net應用中沒有正確地實現(xiàn)加密.攻擊者可以解密并篡改敏感數(shù)據(jù)。如果要理解這個漏洞.首先要了解加密系統(tǒng)中的提示機制.當你提出問題時提示機制會給出某種形式的答案。此漏洞涉及到ASP.NET對加密信息中填充數(shù)據(jù)的提示.攻擊者可以通過向Web服務器發(fā)送特定的密文文本.然后通過檢查所返回的出錯代碼來判斷數(shù)據(jù)是否被正確解密。通過反復上述操作.攻擊者就可以收集到足夠的信息用來解密剩余部分的密文文本。19.2整改建議打上MS10-070漏洞補丁。20.用戶得憑證信息以明文發(fā)送20.1問題描述不安全明文傳輸?shù)卿浾埱蟆?0.2整改建議使用SSL加密。21.Web應用防火墻檢測從HTTPHTTPS后不安全的過渡形式21.1問題描述不安全明文傳輸方式。21.2整改建議使用所以頁面通過SSL加密。22.struts2漏洞22.1問題描述struts2框架版本過低.存在遠程任意命令執(zhí)行漏洞。22.2整改建議升級struts2框架到最新版本。23.弱口令23.1問題描述使用如：123456、test等弱口令。23.2整改建議按電信密碼規(guī)范要求配置口令。24.文件包含24.1問題描述可能會在Web服務器上運行遠程命令。這通常意味著完全破壞服務器及其內容。24.2整改建議假定所有輸入都是惡意的。使用"接受已知善意"輸入驗證策略：嚴格遵守規(guī)范的可接受輸入的白名單。拒絕任何沒有嚴格遵守規(guī)范的輸入.或者將其轉換為遵守規(guī)范的內容。不要完全依賴于將惡意或格式錯誤的輸入加入黑名單。但是.黑名單可幫助檢測潛在攻擊.或者確定哪些輸入格式不正確.以致應當將其徹底拒絕。執(zhí)行輸入驗證時.請考慮所有潛在相關屬性.包括長度、輸入類型、可接受值的完整范圍、缺失或多余輸入、語法、跨相關字段的一致性以及業(yè)務規(guī)則一致性。以業(yè)務規(guī)則邏輯為例."boat"可能在語法上有效.因為它僅包含字母數(shù)字字符.但如果預期為顏色〔如"red"或"blue".那么它無效。對于文件名.請使用限制要使用的字符集的嚴格白名單。如果可行.請僅允許文件名中出現(xiàn)單個"."字符以避免CWE-23之類的弱點.并排除"/"之類的目錄分隔符以避免CWE-36。請使用允許的文件擴展名的白名單.這有助于避免CWE-434。25.源代碼暴露25.1問題描述源代碼暴露。25.2整改建議刪除源代碼文件或對需要的未解析的源代碼進行解析。26.SSL證書無效26.1問題描述SSL證書過期或SSL證書不合法等。26.2整改建議重新生成配置SSL證書。27.SSL加密方式弱27.1問題描述SSL證書加密方式弱.導致加密信息可能被解密。27.2整改建議重新生成SSL證書.加密算法選擇如：RSA-1024等。28.Http請求頭的額外的回車換行符注入28.1問題描述攻擊者可能注入自定義HTTP頭。例如.攻擊者可以注入會話cookie或HTML代碼。這可能會進行類似的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響應拆分同上：Http請求頭的額外的回車換行符注入。30.MBean提交密碼字段中使用GET方法30.1問題描述使用GET方法MBean提交密碼字段。30.2整改建議更改為POST提交方法。31.JBoss類漏洞31.1問題描述發(fā)現(xiàn)JBoss框架登錄管理后臺等信息。31.2整改建議限制JBOSS控制臺等目錄訪問權限。32.ApacheTomcat版本低32.1問題描述ApacheTomcat版本過低32.2整改建議升級ApacheTomcat到最新版本。33.ApacheTomcat類漏洞33.1問題描述發(fā)現(xiàn)存在ApacheTomcat的示例文件、控制臺等信息。33.2整改建議刪除ApacheTomcat的示例文件及控制臺相關文件。34.臨時應急加固方法35.非公眾訪問類35.1問題描述發(fā)現(xiàn)系統(tǒng)、數(shù)據(jù)庫類等漏洞沒法加固或暫時無法加固。35.2整改建議關閉不必要的應用或使用系統(tǒng)防火墻限制非公眾使用的端口進行來源綁定訪問。36.WEB類36.1問題描述發(fā)現(xiàn)XSS、SQL等漏洞的應急加固辦法。36.2整改建議apachecommons-lang工具包里的類.可以在工程中寫一個過濾器.使用該工具類去實現(xiàn)敏感字符的過濾。過濾器示例2如下：使用JAVA過濾器對攻擊特征進行過濾如：一。寫一個過濾器代碼如下：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{