如何安全檢測Java Web應(yīng)用網(wǎng)站漏洞

如何安全檢測Java?Web應(yīng)用網(wǎng)站漏洞.txt32因?yàn)閻坌模骼说娜藗儾拍苤胤导覉@；因?yàn)閻坌模v的靈魂才能活力如初。渴望愛心，如同星光渴望彼此輝映；渴望愛心，如同世紀(jì)之歌渴望永遠(yuǎn)被唱下去。web開發(fā)應(yīng)用程序（網(wǎng)站），是目前應(yīng)用最廣泛的程序。但是開發(fā)者的水平參差不齊，導(dǎo)致了各種各樣web漏洞的出現(xiàn)。本文站在分層架構(gòu)的角度，分析一下如何在java?web程序中找到可能出現(xiàn)的種種漏洞。??? ????????本文討論的只是web程序上的漏洞，和其它漏洞，是相對獨(dú)立的。這句話看似廢話，實(shí)際上卻說明了時(shí)常被忽略的因素，即：“很多人認(rèn)為只要我開發(fā)web程序沒有漏洞，web服務(wù)器就安全了”，事實(shí)上，并非如此。一個(gè)合格的web程序開發(fā)人員，應(yīng)該時(shí)刻清楚自己開發(fā)的程序會(huì)在什么環(huán)境中被使用，以及一旦自己的程序產(chǎn)生某種漏洞，最終會(huì)導(dǎo)致什么后果。簡單的說，web程序被安裝在一臺(tái)或多臺(tái)（分布式）web服務(wù)器上，一旦安裝成功，就等于在為廣大用戶提供服務(wù)的同時(shí)，給入侵者打開了一條或N條新的思路。如果服務(wù)器管理員剛好對安全配置不了解（事實(shí)上，國內(nèi)這種管理員居多），那么只好由我們的程序來守好最后的關(guān)卡最后一道防線。??? ????????看了本文題目，一定有一部分人會(huì)認(rèn)為，“不就是講JSP漏洞么，用得著披著這么厚的包裝么？”，為了回答這個(gè)疑問，我們先看看JSP和ASP的開發(fā)有什么不同吧。在ASP時(shí)代（ASP，PHP等語言），開發(fā)一套系統(tǒng)往往比修改別人已經(jīng)寫好的系統(tǒng)痛苦的多，因?yàn)樗鼈儼阉械拇a（包括鏈接數(shù)據(jù)庫的代碼、執(zhí)行SQL語句的代碼、控制頁面顯示的代碼）統(tǒng)統(tǒng)都放在%......%中，我們時(shí)常會(huì)看到如下代碼塊：??? ????-----------代碼來自某ASP?SHELL-----------??????Function?GetFileSize(size)??????Dim?FileSize?? ????FileSize=size?/?1024?? ????FileSize=FormatNumber(FileSize,2)?? ????If?FileSize??1024?and?FileSize??1?then?? ????GetFileSize="font?color=red"?FileSize??"/font?KB"??????ElseIf?FileSize?1024?then?? ????GetFileSize="font?color=red"?FormatNumber(FileSize?/?1024,2)??"/font?MB"??????Else?? ????GetFileSize="font?color=red"?Size??"/font?Bytes"??????End?If?? ????End?Function?? ????----------------------------------------?????? ????????如果客戶的需求變了，要求頁面不能使用“font?color=red”等標(biāo)簽，全部應(yīng)用“CSS”顯示。掛了，把程序員召喚出來，一個(gè)一個(gè)的改吧。。。注意，這里強(qiáng)調(diào)下，特指“召喚程序員”才能改，如果是學(xué)美工的，只會(huì)HTML、JS、CSS，完了，這活還干不成。而這些只是簡單的頁面修改，如果客戶今天說，MYSQL服務(wù)器承擔(dān)不了這個(gè)數(shù)據(jù)量，要掛Oracle，可憐的程序員就要在一片一片的代碼海洋里尋找執(zhí)行SQL語句的代碼，而每一個(gè)文件都可能存放著SQL語句，意味著每一個(gè)文件都可能在受SQL注入的威脅。??

創(chuàng)新互聯(lián)是專業(yè)的南京網(wǎng)站建設(shè)公司，南京接單;提供做網(wǎng)站、成都網(wǎng)站制作,網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行南京網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!

而JSP采用MVC模式分層架構(gòu)進(jìn)行開發(fā)，就可以把所有的文件分開，根據(jù)其用途，分別放在不同的文件夾下（分層），每個(gè)文件夾下的文件只負(fù)責(zé)自己的事情。例如數(shù)據(jù)訪問層的代碼就放在數(shù)據(jù)訪問層的文件夾下，業(yè)務(wù)邏輯層的代碼也都放在自己的文件夾下，當(dāng)顯示層（這一層是為了把最終的運(yùn)算結(jié)果顯示給用戶看）的需求發(fā)生變化，就像前面的客戶需求，我們只要修改這一層的文件就是了，其他層的代碼根本不需要?jiǎng)樱薷恼咭膊恍枰闷渌鼘拥拇a。??? ????代碼分層了，意味著漏洞也在跟著分層，我們尋找JSP漏洞的思路也要跟著分層，才能與時(shí)俱進(jìn)。??? ????????下面在講述尋找漏洞的過程中，本文就拿一個(gè)簡單的分層架構(gòu)例子來做樣板。樣板程序的名稱為“XX文章系統(tǒng)”，系統(tǒng)使用了STRUTS框架，和安全有關(guān)的層分為：??? ?????“DB層”，這一層存放了鏈接數(shù)據(jù)庫的字符串，以及JdbcTemplate類，直接訪問數(shù)據(jù)庫。因?yàn)樵趈ava中，執(zhí)行SQL語句的函數(shù)按照返回值可以分為三類，所以在這一層定義了JDBC模版類（JdbcTemplate），每一次使用操作數(shù)據(jù)庫時(shí)都要執(zhí)行這一層的三個(gè)方法其中一個(gè)。??? ????“DAO層（Data?Access?Object數(shù)據(jù)訪問對象層）”，從安全角度上看，這一層存放了SQL語句（并不執(zhí)行SQL語句，語句傳給DB層執(zhí)行）。這一層調(diào)用“DB層”訪問數(shù)據(jù)庫，它只知道“DB層”的存在，不知道數(shù)據(jù)庫的存在。??? ????“SERVICE層”，業(yè)務(wù)邏輯層，因?yàn)橐粋€(gè)業(yè)務(wù)的實(shí)現(xiàn)，并不是一次數(shù)據(jù)庫訪問就可以完成的，所以這一層通過N次調(diào)用“DAO層的方法”實(shí)現(xiàn)業(yè)務(wù)邏輯，它只知道“DAO層”的存在，不知道“DB層”和數(shù)據(jù)庫的存在。??“ACTION層”，調(diào)用業(yè)務(wù)邏輯層，根據(jù)返回的結(jié)果，控制JSP頁面顯示。它只知道業(yè)務(wù)層的存在。這一層是入侵者的攻擊平臺(tái)。??? ????“Form層”，把用戶POST提交的信息封裝成Form對象，經(jīng)過驗(yàn)證后提交給ACTION層處理。??? ????“JSP層”(顯示層)，這一層是最終顯示給用戶看的頁面，同時(shí)也是入侵者的攻擊平臺(tái)。??? ?????????用戶通過訪問ACTION層，自動(dòng)會(huì)發(fā)生：“ACTION調(diào)用SERVICE，SERVICE調(diào)用DAO，DAO調(diào)用DB，DB執(zhí)行SQL語句返回結(jié)果給DAO，DAO返回給SERVICE，SERVICE返回給ACTION，ACTION把數(shù)據(jù)顯示到JSP里返回給用戶”。??? ????有了樣板，我們來分析這套程序中可能出現(xiàn)的各種web漏洞。??? ????1、SQL注入漏洞??? ????????從SQL注入漏洞說起吧，在web漏洞里，SQL注入是最容易被利用而又最具有危害性的。怎么快速的找到呢？先分析流程，就拿用戶查看文章這個(gè)流程為例：用戶訪問一個(gè)

action，告訴它用戶想看ID為7的文章，這個(gè)action就會(huì)繼續(xù)完成前面所說的流程。??? ????????如果是ASP程序，這就是最容易產(chǎn)生問題的時(shí)候，ASP是弱類型，接到參數(shù)后不需要轉(zhuǎn)換類型，就和SQL語句連加起來。但是JSP就不一樣，JSP是強(qiáng)類型的語言，接受有害的參數(shù)后：對于GET請求（直接在地址欄訪問頁面），如果這里要的是int型，即使不懂安全的程序員，也會(huì)把它（文章的ID）立刻轉(zhuǎn)換成int，因?yàn)檫@里轉(zhuǎn)換后在后面的處理中會(huì)更容易操作，而這時(shí)程序就出錯(cuò)了；對于POST請求，如果這里要的是int型，程序會(huì)在把它封裝成Form對象時(shí)，因?yàn)樽詣?dòng)要進(jìn)行類型轉(zhuǎn)化，同樣發(fā)生錯(cuò)誤，這兩種錯(cuò)誤發(fā)生后，根本不會(huì)訪問后面的流程就跳出了，或許這就是JSP天生的安全性。所以，通常提交的變量是int時(shí)，不會(huì)發(fā)生問題，問題會(huì)出現(xiàn)在string參數(shù)這里，如果要查看某用戶的信息，程序可能會(huì)讓你提交如下參數(shù)：showuser.do?????username=kxlzx。問題來了，因?yàn)檫@里是string類型，所以不懂安全的程序員頂多會(huì)判斷一下是不是空，就連加成為SQL語句。有漏洞的程序大概會(huì)寫成這個(gè)樣子：??? ????ACTION的代碼：?showuser.do??????String?username?=?null;?? ????username?=?request.getParameter("username");??????Service?service?=?new?Service();??????service.findByUsername(username);?? ????得到參數(shù)后調(diào)用service,service層直接交給了Dao層，dao的代碼：??????public?Object?findByUsername(String?username)???????{?? ????JdbcTemplate?jt=new?JdbcTemplate();?? ????String?sql?=?"select?*?from?Users?where?username=’"+username"’";??????List?list?=?jt.query(sql);??????...................???????}????? ???????dao調(diào)用了DB層的JdbcTemplate，把SQL語句拼好后，傳給了JdbcTemplate去執(zhí)行。不用再看這里的JdbcTemplate，就可以知道里面的代碼使用了Statement的executequery()方法執(zhí)行，導(dǎo)致了SQL注入。??? ???????分析了這么半天，有讀者會(huì)問：“難道我要費(fèi)這么大的力氣才能找到漏洞么？”。的確，通常在ASP程序里找注入時(shí)的思路就是這樣子，但是我們現(xiàn)在是在使用了開發(fā)模式分層架構(gòu)的JSP程序里，應(yīng)該按照分層架構(gòu)的思維去找漏洞。在回答這個(gè)問題之前，我們還得繞個(gè)彎子，看看怎么在這里預(yù)防SQL注入（java始終都是這么優(yōu)美，它不會(huì)直接告訴你答案，而是一層一層的讓你撥開云霧）。??? ????????剛才分析流程，是從正向分析的，從用戶輸入到產(chǎn)生漏洞，我們在防御的時(shí)候，不妨倒過來看看，從DB層入手。JdbcTemplate調(diào)用執(zhí)行SQL語句，可以有兩個(gè)類供我們選擇，一個(gè)是Statement，另一個(gè)就是預(yù)處理的Statement，兩者有著效率上和安全上的顯著差別。在效率上，只要數(shù)據(jù)庫支持預(yù)處理技術(shù)（sqlserver，mysql，oracle等都支持，只有少數(shù)access等不支持），就會(huì)在大量執(zhí)行SQL語句時(shí)增加速度；在安全上，使用預(yù)處理，會(huì)把接受的參數(shù)也經(jīng)過預(yù)處理，從而不會(huì)作為SQL語句的一部分執(zhí)行，而是僅僅作為SQL語句中的參數(shù)部分

內(nèi)容被執(zhí)行。一旦DB層使用了預(yù)處理，DAO層的SQL語句也會(huì)發(fā)生變化，成為這個(gè)樣子：??????public?Object?findByUsername(String?username)???????{?? ????JdbcTemplate?jt=new?JdbcTemplate();?? ????String?sql?=?"select?*?from?Users?where?username=?";??????List?list?=?jt.query(sql,new?Object[1]{username});??????...................??????}????? ????????這樣，SQL注入就和我們的程序幾乎無關(guān)了，注意我說的是幾乎，而不是全部。知道了怎么防御，于是一切在這里變的簡單極了，我們應(yīng)該直接去DB層找到JdbcTemplate，看看代碼，一旦使用了Statement，很好，這個(gè)系統(tǒng)十有八九有漏洞，下面要做的是使用Editplus搜索“request.getParameter”。沒有使用預(yù)處理的系統(tǒng)，可能會(huì)在action層進(jìn)行防御，對參數(shù)過濾，但總有防御不到的時(shí)候，因?yàn)閼?zhàn)線拉的太長了，每一個(gè)action里都可能接受參數(shù)并存在漏洞。??? ????????還有一種情況，系統(tǒng)一部分使用了預(yù)處理，一部分沒有，這樣的情況可能是因?yàn)轫?xiàng)目趕的比較倉促，人員沒有經(jīng)過正規(guī)培訓(xùn)，最后艱難的整合到了一起。這種情況也好辦，直接在DAO層搜索（"’）或（’"），這些符號(hào)用于和字符串變量連加，拼SQL語句，肯定是這些語句之后的代碼使用了Statement。然后再往上層找，看看哪個(gè)action調(diào)用了這個(gè)有問題的dao類，也可能發(fā)生SQL注入。?? ???????即使系統(tǒng)使用了預(yù)處理，別忘了，程序給客戶使用后，客戶有權(quán)利去擴(kuò)展的。程序拿到客戶那里，客戶有了新的需求，而這個(gè)需求又不大，很可能不愿意花錢重新雇人來實(shí)現(xiàn)擴(kuò)展功能，在這個(gè)時(shí)候也可能出現(xiàn)問題，客戶使用自己的程序員擴(kuò)展AJAX功能，這個(gè)程序員因?yàn)榕鲁鰡栴}，不敢動(dòng)源程序，就在web.xml里加了一個(gè)servlet，這個(gè)servlet直接去調(diào)用conn。可怕的事情發(fā)生了。所以，我們的搜索漏洞規(guī)則中又加上了一條，在非dao層的文件中，搜索“select，update，delete”等字符串。??? ????2、暴露程序信息漏洞??? ????????這個(gè)漏洞是怎么來的呢？我們需要從異常說起。有經(jīng)驗(yàn)的入侵者，可以從JSP程序的異常中獲取很多信息，比如程序的部分架構(gòu)、程序的物理路徑、SQL注入爆出來的信息等，這個(gè)漏洞很容易防御，卻很難快速定位漏洞文件。出現(xiàn)這樣漏洞的時(shí)候，通常是我們在寫代碼的時(shí)候，少了一些可能性的考慮而導(dǎo)致的。這樣的問題都是經(jīng)驗(yàn)造成的，而尋找漏洞也要通過經(jīng)驗(yàn)加運(yùn)氣（要有仙緣。。。），我個(gè)人技術(shù)有限，就不多說了。防御的方法就是在程序中加上“Exception層”，自定義異常，把系統(tǒng)產(chǎn)生的異常統(tǒng)統(tǒng)包裝起來，不要放過任何一個(gè)可能產(chǎn)生異常的地方。像騰訊的異常就包裝的很好“對不起，今天的注冊人數(shù)已經(jīng)達(dá)到十萬，請您明天再來。。。”，廢話，日注冊量都十萬，還讓不讓人活啦，鐵定是程序發(fā)生了異常，不敢讓各位大大們看到真實(shí)的面孔。

怎么查看java代碼是否內(nèi)存泄露

第一階段 通過jdk的GC輸出進(jìn)行測試

可以在 JAVA_OPTS增加以下參數(shù)打開jdk的GC輸出日志：

-verbose:gc -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError

打開輸出日志，jdk會(huì)在每一次的垃圾回收時(shí)打印相關(guān)日志

第二階段 通過jmap命令

jmap命令可以獲得運(yùn)行中的jvm的堆的快照，從而可以離線分析堆，以檢查內(nèi)存泄漏，檢查一些嚴(yán)重影響性能的大對象的創(chuàng)建，檢查系統(tǒng)中什么對象最多，各種對象所占內(nèi)存的大小等等

第三階段 通過Eclipse Memory Analyzer 分析工具來分析

Eclipse Memory Analyzer是一種快速的,功能豐富的Java堆分析工具，以下簡稱MAT,可以幫助查找內(nèi)存泄露,并減少內(nèi)存消耗。 這個(gè)工具可以對由堆轉(zhuǎn)儲(chǔ)產(chǎn)生的數(shù)以億計(jì)的對象進(jìn)行分析,一旦堆轉(zhuǎn)儲(chǔ)被解析,可以在打開他的一瞬間,立即得到保留大小的單一對象,提取記錄詳細(xì)的信息，查看為什么這些對象對象資料沒有被釋放掉。使用這些功能的報(bào)告,可以對這些對象進(jìn)行跟蹤，找到內(nèi)存泄露嫌疑人，也可以得到系統(tǒng)的性能指數(shù),幫助優(yōu)化系統(tǒng)。

java正則表達(dá)式怎么防止代碼漏洞

javaWeb安全漏洞及處理方式

關(guān)注

轉(zhuǎn)載自：

1、SQL注入攻擊

SQL注入攻擊就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。具體來說，它是利用現(xiàn)有應(yīng)用程序，將(惡意)的SQL命令注入到后臺(tái)數(shù)據(jù)庫引擎執(zhí)行的能力，它可以通過在Web表單中輸入(惡意)SQL語句得到一個(gè)存在安全漏洞的網(wǎng)站上的數(shù)據(jù)庫，而不是按照設(shè)計(jì)者意圖去執(zhí)行SQL語句。

隨著B/S框架結(jié)構(gòu)在系統(tǒng)開發(fā)中的廣泛應(yīng)用，惡意攻擊者利用SQL命令在Web表單中輸入合法的字符或查詢字符串來欺騙服務(wù)器執(zhí)行SQL命令。當(dāng)注入攻擊得逞后，Web程序?qū)⑿孤洞罅坑脩綦[私數(shù)據(jù)和數(shù)據(jù)庫中數(shù)據(jù)結(jié)構(gòu)。攻擊者能夠獲得系統(tǒng)較高的訪問權(quán)限，進(jìn)行破壞操作。

SQL注入可以分為平臺(tái)層注入和代碼層注入。前者由不安全的數(shù)據(jù)庫配置或數(shù)據(jù)庫平臺(tái)的漏洞所致;后者主要是由于程序員對輸入未進(jìn)行細(xì)致地過濾，從而執(zhí)行了非法的數(shù)據(jù)查詢。基于此，SQL注入的產(chǎn)生原因通常表現(xiàn)在以下幾方面:

1）不當(dāng)?shù)念愋吞幚?

2）不安全的數(shù)據(jù)庫配置;

3）不合理的查詢集處理;

4）不當(dāng)?shù)腻e(cuò)誤處理;

5）轉(zhuǎn)義字符處理不合適;

6) 多個(gè)提交處理不當(dāng)。

解決方法:

數(shù)據(jù)庫安全通信包括SQL注入攻擊的防范、安全設(shè)置、異常信息處理三個(gè)方面。

1.服務(wù)端Filter對訪問者輸入的字符進(jìn)行過濾檢驗(yàn)，但是攻擊者經(jīng)常把危險(xiǎn)字符潛藏在用戶輸入的有效字符中完 成過濾檢驗(yàn)。

2.通過正則表達(dá)式對頁面的文本框輸入的數(shù)據(jù)進(jìn)行限制可以減少過濾檢驗(yàn)存在的漏洞。

3.使用prepareStatment預(yù)編譯sql語句

2、XSS跨站腳本攻擊

跨站腳本（Cross-site scripting，簡稱XSS），是一種迫使Web站點(diǎn)回顯可執(zhí)行代碼的攻擊技術(shù)，而這些可執(zhí)行代碼由攻擊者提供、最終為用戶瀏覽器加載。不同于大多數(shù)攻擊（一般只涉及攻擊者和受害者），XSS涉及到三方，即攻擊者、客戶端與網(wǎng)站。XSS的攻擊目標(biāo)是為了盜取客戶端的cookie或者其他網(wǎng)站用于識(shí)別客戶端身份的敏感信息。獲取到合法用戶的信息后，攻擊者甚至可以假冒最終用戶與網(wǎng)站進(jìn)行交互。

XSS 屬于被動(dòng)式的攻擊。攻擊者先構(gòu)造一個(gè)跨站頁面，利用SCRIPT、IMG、IFRAME等各種方式使得用戶瀏覽這個(gè)頁面時(shí)，觸發(fā)對被攻擊站點(diǎn)的HTTP 請求。此時(shí)，如果被攻擊者如果已經(jīng)在被攻擊站點(diǎn)登錄，就會(huì)持有該站點(diǎn)cookie。這樣該站點(diǎn)會(huì)認(rèn)為被攻擊者發(fā)起了一個(gè)HTTP請求。而實(shí)際上這個(gè)請求是在被攻擊者不知情情況下發(fā)起的，由此攻擊者在一定程度上達(dá)到了冒充被攻擊者的目的。精心的構(gòu)造這個(gè)攻擊請求，可以達(dá)到冒充發(fā)文，奪取權(quán)限等多個(gè)攻擊目的。在常見的攻擊實(shí)例中，這個(gè)請求是通過script 來發(fā)起的，因此被稱為Cross Site Script。

XSS漏洞成因是由于動(dòng)態(tài)網(wǎng)頁的Web應(yīng)用對用戶提交請求參數(shù)未做充分的檢查過濾，允許用戶在提交的數(shù)據(jù)中摻入HTML代碼（最主要的是“”、“”），然后未加編碼地輸出到第三方用戶的瀏覽器，這些攻擊者惡意提交代碼會(huì)被受害用戶的瀏覽器解釋執(zhí)行。

分為三種類型：

1）反射型（數(shù)據(jù)流向：瀏覽器 -后端 - 瀏覽器）

反射型XSS腳本攻擊即如我們上面所提到的XSS跨站腳本攻擊方式，該類型只是簡單地將用戶輸入的數(shù)據(jù)直接或未經(jīng)過完善的安全過濾就在瀏覽器中進(jìn)行輸出，導(dǎo)致輸出的數(shù)據(jù)中存在可被瀏覽器執(zhí)行的代碼數(shù)據(jù)。由于此種類型的跨站代碼存在于URL中，所以黑客通常需要通過誘騙或加密變形等方式，將存在惡意代碼的鏈接發(fā)給用戶，只有用戶點(diǎn)擊以后才能使得攻擊成功實(shí)施。

2）存儲(chǔ)型（數(shù)據(jù)流向是：瀏覽器 -后端 - 數(shù)據(jù)庫 - 后端- 瀏覽器）

存儲(chǔ)型XSS腳本攻擊是指Web應(yīng)用程序會(huì)將用戶輸入的數(shù)據(jù)信息保存在服務(wù)端的數(shù)據(jù)庫或其他文件形式中，網(wǎng)頁進(jìn)行數(shù)據(jù)查詢展示時(shí)，會(huì)從數(shù)據(jù)庫中獲取數(shù)據(jù)內(nèi)容，并將數(shù)據(jù)內(nèi)容在網(wǎng)頁中進(jìn)行輸出展示，因此存儲(chǔ)型XSS具有較強(qiáng)的穩(wěn)定性。

存儲(chǔ)型XSS腳本攻擊最為常見的場景就是在博客或新聞發(fā)布系統(tǒng)中，黑客將包含有惡意代碼的數(shù)據(jù)信息直接寫入文章或文章評(píng)論中，所有瀏覽文章或評(píng)論的用戶，都會(huì)在他們客戶端瀏覽器環(huán)境中執(zhí)行插入的惡意代碼。

3）基于DOM（數(shù)據(jù)流向是：URL--瀏覽器 ）

基于DOM的XSS跨站腳本攻擊是通過修改頁面DOM節(jié)點(diǎn)數(shù)據(jù)信息而形成的XSS跨站腳本攻擊。不同于反射型XSS和存儲(chǔ)型XSS，基于DOM的XSS跨站腳本攻擊往往需要針對具體的javascript DOM代碼進(jìn)行分析，并根據(jù)實(shí)際情況進(jìn)行XSS跨站腳本攻擊的利用。

解決方法：

1).輸入過濾。對用戶的所有輸入數(shù)據(jù)進(jìn)行檢測，比如過濾其中的“”、“”、“/”等可能導(dǎo)致腳本注入的特殊字符，或者過濾“script”、“javascript”等腳本關(guān)鍵字，或者對輸入數(shù)據(jù)的長度進(jìn)行限制等等。同時(shí)，我們也要考慮用戶可能繞開ASCII碼，使用十六進(jìn)制編碼來輸入腳本。因此，對用戶輸入的十六進(jìn)制編碼，我們也要進(jìn)行相應(yīng)的過濾。只要能夠嚴(yán)格檢測每一處交互點(diǎn)，保證對所有用戶可能的輸入都進(jìn)行檢測和XSS過濾，就能夠有效地阻止XSS攻擊。

2).輸出編碼。通過前面對XSS攻擊的分析，我們可以看到，之所以會(huì)產(chǎn)生XSS攻擊，就是因?yàn)閃eb應(yīng)用程序?qū)⒂脩舻妮斎胫苯忧度氲侥硞€(gè)頁面當(dāng)中，作為該頁面的HTML代碼的一部分。因此，當(dāng)Web應(yīng)用程序?qū)⒂脩舻妮斎霐?shù)據(jù)輸出到目標(biāo)頁面中時(shí)，只要用HtmlEncoder等工具先對這些數(shù)據(jù)進(jìn)行編碼，然后再輸出到目標(biāo)頁面中。這樣，如果用戶輸入一些HTML的腳本，也會(huì)被當(dāng)成普通的文字，而不會(huì)成為目標(biāo)頁面HTML代碼的一部分得到執(zhí)行.

3、CSRF跨站請求偽造漏洞防護(hù)

CSRF是CrossSite Request Forgery的縮寫，乍一看和XSS差不多的樣子，但是其原理正好相反，XSS是利用合法用戶獲取其信息，而CSRF是偽造成合法用戶發(fā)起請求。

字面理解意思就是在別的站點(diǎn)偽造了一個(gè)請求。專業(yè)術(shù)語來說就是在受害者訪問一個(gè)網(wǎng)站時(shí)，其 Cookie 還沒有過期的情況下，攻擊者偽造一個(gè)鏈接地址發(fā)送受害者并欺騙讓其點(diǎn)擊，從而形成 CSRF 攻擊。

根據(jù)HTTP協(xié)議，在HTTP頭中有一個(gè)字段叫Referer，它記錄了該HTTP請求的來源地址。在通常情況下，訪問一個(gè)安全受限頁面的請求必須來自于同一個(gè)網(wǎng)站。

解決方案：

配置FILTER攔截用戶所有請求(POST/GET)，對用戶請求Referer頭URL進(jìn)行合法性校驗(yàn)。

4、URL鏈接注入漏洞防護(hù)

鏈接注入是修改站點(diǎn)內(nèi)容的行為，其方式為將外部站點(diǎn)的 URL 嵌入其中，或?qū)⒂幸资芄舻恼军c(diǎn)中的腳本 的 URL 嵌入其中。將URL 嵌入易受攻擊的站點(diǎn)中，攻擊者便能夠以它為平臺(tái)來啟動(dòng)對其他站點(diǎn)的攻擊，以及攻擊這個(gè)易受攻擊的站點(diǎn)本身。

解決方案：

1，二次驗(yàn)證，進(jìn)行重要敏感操作時(shí)，要求用戶進(jìn)行二次驗(yàn)證。

2，驗(yàn)證碼，進(jìn)行重要敏感操作時(shí)，加入驗(yàn)證碼。

3，驗(yàn)證 HTTP 的 Referer 字段。

4，請求地址中添加 Token 并驗(yàn)證。

5，HTTP 頭中自定義屬性并驗(yàn)證。

5、會(huì)話COOKIE中缺少HttpOnly防護(hù)

會(huì)話cookie中缺少HttpOnly屬性會(huì)導(dǎo)致攻擊者可以通過程序(JS腳本、Applet等)獲取到用戶的cookie信息，造成用戶cookie信息泄露，增加攻擊者的跨站腳本攻擊威脅。

HttpOnly是微軟對cookie做的擴(kuò)展，該值指定cookie是否可通過客戶端腳本訪問。Microsoft Internet Explorer 版本 6 Service Pack 1 和更高版本支持cookie屬性HttpOnly。

如果在Cookie中沒有設(shè)置HttpOnly屬性為true，可能導(dǎo)致Cookie被竊取。竊取的Cookie可以包含標(biāo)識(shí)站點(diǎn)用戶的敏感信息。

如果在Cookie中設(shè)置HttpOnly屬性為true，兼容瀏覽器接收到HttpOnly cookie，那么客戶端通過程序(JS腳本、Applet等)將無法讀取到Cookie信息，這將有助于緩解跨站點(diǎn)腳本威脅。

解決方案：

配置filter攔截器，將服務(wù)器端返回請求，向所有會(huì)話cookie中添加“HttpOnly”屬性。

示例代碼：

HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;

response.setHeader("SET-COOKIE","JSESSIONID=" + sessionid + "; HttpOnly");

6、點(diǎn)擊劫持漏洞(Clickjacking)防護(hù)

點(diǎn)擊劫持是一種視覺上的欺騙手段，攻擊者使用一個(gè)透明的、不可見的iframe，覆蓋在一個(gè)網(wǎng)頁上，然后誘使用戶在該網(wǎng)頁上進(jìn)行操作，此時(shí)用戶在不知情的情況下點(diǎn)擊了透明的iframe頁面。通過調(diào)整iframe頁面的位置，可以誘使用戶恰好點(diǎn)擊在iframe頁面的一些功能性按鈕上。

解決方案：

配置FILTER攔截器，在服務(wù)器端返回請求中，使用一個(gè)HTTP頭“X-Frame-Options”值為SAMEORIGIN-同源策略 ，則frame頁面的地址只能為同源域名下面的頁面，防止點(diǎn)擊劫持漏洞發(fā)生。

示例代碼：

HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;

response.addHeader("x-frame-options","SAMEORIGIN");

7、HTTP host 頭攻擊漏洞

使用HTTP代理工具，可以篡改HTTP報(bào)文頭部中HOST字段時(shí)，該值可被注入惡意代碼。因?yàn)樾枰刂瓶蛻舳说妮斎耄试撀┒摧^難利用。

解決方案：

配置FILTER攔截器，對請求輸入HOST頭信息進(jìn)行信息安全性校驗(yàn)，防止HOST頭信息被惡意篡改利用。

示例代碼：

HttpServletRequest request =(HttpServletRequest)servletRequest;

//主機(jī)ip和端口 或 域名和端口

String myhosts = request.getHeader("host");

if(!StringUtils.equals(myhosts, "xx.xx.xxx.xxx:xxxx")

!StringUtils.equals(myhosts, "xx.xx.xxx.xxx:xxxx")

!StringUtils.equals(myhosts,"xx.xx.xxx.xxx:xxxx")StringUtils.equals(myhosts,"xx.xx.xxx.xxx")

!StringUtils.equals(myhosts,"xx.xx.xxx.xxx") !StringUtils.equals(myhosts,"xx.xx.xxx.xxx" ){

logger.error("======訪問host非法，已攔截======");

response.sendRedirect(request.getContextPath() + "/login.jsp");

return;

}

8、越權(quán)訪問漏洞防護(hù)

越權(quán)訪問（Broken Access Control，簡稱BAC）是Web應(yīng)用程序中一種常見的漏洞，分為垂直越權(quán)訪問和水平越權(quán)訪問。垂直越權(quán)是指不同用戶級(jí)別之間的越權(quán)，如普通用戶執(zhí)行管理員用戶的權(quán)限。水平越權(quán)是指相同級(jí)別用戶之間的越權(quán)操作。

Web應(yīng)用程序如果存在越權(quán)訪問漏洞，可能導(dǎo)致以下危害：

1）導(dǎo)致任意用戶敏感信息泄露；

2）導(dǎo)致任意用戶信息被惡意修改或刪除。

解決方案：

配置FILTER攔截器，對請求所有URL進(jìn)行攔截，對于需要進(jìn)行授權(quán)的URL進(jìn)行權(quán)限校驗(yàn)，防止用戶越權(quán)訪問系統(tǒng)資源。

9.弱口令漏洞

解決方案：最好使用至少6位的數(shù)字、字母及特殊字符組合作為密碼。數(shù)據(jù)庫不要存儲(chǔ)明文密碼，應(yīng)存儲(chǔ)MD5加密后的密文，由于目前普通的MD5加密已經(jīng)可以被破解，最好可以多重MD5加密，或者多種加密方式疊加組合。

10．JSP頁面拋出的異常可能暴露程序信息。

有經(jīng)驗(yàn)的入侵者，可以從JSP程序的異常中獲取很多信息，比如程序的部分架構(gòu)、程序的物理路徑、SQL注入爆出來的信息等。

解決方案：自定義一個(gè)Exception，將異常信息包裝起來不要拋到頁面上。

11.本地緩存漏洞

合法用戶“注銷”后，在未關(guān)閉瀏覽器的情況下，點(diǎn)擊瀏覽器“后退”按鈕，可從本地頁面緩存中讀取數(shù)據(jù)，繞過了服務(wù)端filter過濾。

解決方案：配置filter對存放敏感信息的頁面限制頁面緩存。如：

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

httpResponse.setHeader("Cache-Control","no-store");

httpResponse.setDateHeader("Expires",0);

httpResponse.setHeader("Pragma","no-cache");

12.文件上傳漏洞。

前臺(tái)僅使用JS對文件后綴做了過濾，這只能針對普通的用戶，而惡意攻擊者完全可以修改表單去掉JS校驗(yàn)。

13.Java WEB容器默認(rèn)配置漏洞。

如TOMCAT后臺(tái)管理漏洞，默認(rèn)用戶名及密碼登錄后可直接上傳war文件獲取webshell。

解決方案：最好刪除，如需要使用它來管理維護(hù)，可更改其默認(rèn)路徑，口令及密碼。

當(dāng)前文章：java檢查代碼漏洞 java代碼執(zhí)行漏洞
URL地址：http://www.chinadenli.net/article10/dddoego.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、網(wǎng)站收錄、全網(wǎng)營銷推廣、小程序開發(fā)、網(wǎng)站制作、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)