xssjava,java代碼過濾

本文目錄一覽：

1、用JAVA做一個網站，現在要做防止XSS攻擊，請問怎麼防止這種攻擊
2、如何安全檢測Java Web應用網站漏洞
3、java web開發如何有效的防止xss攻擊
4、Struct2+Spring 架構JavaWeb項目，出現xss跨站腳本攻擊漏洞解決方案？？

用JAVA做一個網站，現在要做防止XSS攻擊，請問怎麼防止這種攻擊

過濾特定符號pre t=”code” l=”java” public static String guolv(String a) {

a = a.replaceAll(“%22”, “”);

a = a.replaceAll(“%27”, “”);

a = a.replaceAll(“%3E”, “”);

a = a.replaceAll(“%3e”, “”);

a = a.replaceAll(“%3C”, “”);

a = a.replaceAll(“%3c”, “”);

a = a.replaceAll(“”, “”);

a = a.replaceAll(“\””, “”);

a = a.replaceAll(“‘”, “”);

a = a.replaceAll(“\\+”, “”);

a = a.replaceAll(“\\(“, “”);

a = a.replaceAll(“\\)”, “”);

a = a.replaceAll(” and “, “”);

a = a.replaceAll(” or “, “”);

a = a.replaceAll(” 1=1 “, “”);

return a;

}

如何安全檢測Java Web應用網站漏洞

如何安全檢測Java Web應用網站漏洞.txt32因為愛心，流浪的人們才能重返家園；因為愛心，疲憊的靈魂才能活力如初。渴望愛心，如同星光渴望彼此輝映；渴望愛心，如同世紀之歌渴望永遠被唱下去。web開發應用程序（網站），是目前應用最廣泛的程序。但是開發者的水平參差不齊，導致了各種各樣web漏洞的出現。本文站在分層架構的角度，分析一下如何在java web程序中找到可能出現的種種漏洞。本文討論的只是web程序上的漏洞，和其它漏洞，是相對獨立的。這句話看似廢話，實際上卻說明了時常被忽略的因素，即：“很多人認為只要我開發web程序沒有漏洞，web服務器就安全了”，事實上，並非如此。一個合格的web程序開發人員，應該時刻清楚自己開發的程序會在什麼環境中被使用，以及一旦自己的程序產生某種漏洞，最終會導致什麼後果。簡單的說，web程序被安裝在一台或多台（分布式）web服務器上，一旦安裝成功，就等於在為廣大用戶提供服務的同時，給入侵者打開了一條或N條新的思路。如果服務器管理員剛好對安全配置不了解（事實上，國內這種管理員居多），那麼只好由我們的程序來守好最後的關卡最後一道防線。看了本文題目，一定有一部分人會認為，“不就是講JSP漏洞么，用得着披着這麼厚的包裝么？”，為了回答這個疑問，我們先看看JSP和ASP的開發有什麼不同吧。在ASP時代（ASP，PHP等語言），開發一套系統往往比修改別人已經寫好的系統痛苦的多，因為它們把所有的代碼（包括鏈接數據庫的代碼、執行SQL語句的代碼、控制頁面顯示的代碼）統統都放在%……%中，我們時常會看到如下代碼塊： ———–代碼來自某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”等標籤，全部應用“CSS”顯示。掛了，把程序員召喚出來，一個一個的改吧。。。注意，這裡強調下，特指“召喚程序員”才能改，如果是學美工的，只會HTML、JS、CSS，完了，這活還幹不成。而這些只是簡單的頁面修改，如果客戶今天說，MYSQL服務器承擔不了這個數據量，要掛Oracle，可憐的程序員就要在一片一片的代碼海洋里尋找執行SQL語句的代碼，而每一個文件都可能存放着SQL語句，意味着每一個文件都可能在受SQL注入的威脅。

而JSP採用MVC模式分層架構進行開發，就可以把所有的文件分開，根據其用途，分別放在不同的文件夾下（分層），每個文件夾下的文件只負責自己的事情。例如數據訪問層的代碼就放在數據訪問層的文件夾下，業務邏輯層的代碼也都放在自己的文件夾下，當顯示層（這一層是為了把最終的運算結果顯示給用戶看）的需求發生變化，就像前面的客戶需求，我們只要修改這一層的文件就是了，其他層的代碼根本不需要動，而修改者也不需要懂得其它層的代碼。代碼分層了，意味着漏洞也在跟着分層，我們尋找JSP漏洞的思路也要跟着分層，才能與時俱進。下面在講述尋找漏洞的過程中，本文就拿一個簡單的分層架構例子來做樣板。樣板程序的名稱為“XX文章系統”，系統使用了STRUTS框架，和安全有關的層分為： “DB層”，這一層存放了鏈接數據庫的字符串，以及JdbcTemplate類，直接訪問數據庫。因為在java中，執行SQL語句的函數按照返回值可以分為三類，所以在這一層定義了JDBC模版類（JdbcTemplate），每一次使用操作數據庫時都要執行這一層的三個方法其中一個。 “DAO層（Data Access Object數據訪問對象層）”，從安全角度上看，這一層存放了SQL語句（並不執行SQL語句，語句傳給DB層執行）。這一層調用“DB層”訪問數據庫，它只知道“DB層”的存在，不知道數據庫的存在。 “SERVICE層”，業務邏輯層，因為一個業務的實現，並不是一次數據庫訪問就可以完成的，所以這一層通過N次調用“DAO層的方法”實現業務邏輯，它只知道“DAO層”的存在，不知道“DB層”和數據庫的存在。 “ACTION層”，調用業務邏輯層，根據返回的結果，控制JSP頁面顯示。它只知道業務層的存在。這一層是入侵者的攻擊平台。 “Form層”，把用戶POST提交的信息封裝成Form對象，經過驗證後提交給ACTION層處理。 “JSP層”(顯示層)，這一層是最終顯示給用戶看的頁面，同時也是入侵者的攻擊平台。用戶通過訪問ACTION層，自動會發生：“ACTION調用SERVICE，SERVICE調用DAO，DAO調用DB，DB執行SQL語句返回結果給DAO，DAO返回給SERVICE，SERVICE返回給ACTION，ACTION把數據顯示到JSP里返回給用戶”。有了樣板，我們來分析這套程序中可能出現的各種web漏洞。 1、SQL注入漏洞從SQL注入漏洞說起吧，在web漏洞里，SQL注入是最容易被利用而又最具有危害性的。怎麼快速的找到呢？先分析流程，就拿用戶查看文章這個流程為例：用戶訪問一個

action，告訴它用戶想看ID為7的文章，這個action就會繼續完成前面所說的流程。如果是ASP程序，這就是最容易產生問題的時候，ASP是弱類型，接到參數後不需要轉換類型，就和SQL語句連加起來。但是JSP就不一樣，JSP是強類型的語言，接受有害的參數後：對於GET請求（直接在地址欄訪問頁面），如果這裡要的是int型，即使不懂安全的程序員，也會把它（文章的ID）立刻轉換成int，因為這裡轉換後在後面的處理中會更容易操作，而這時程序就出錯了；對於POST請求，如果這裡要的是int型，程序會在把它封裝成Form對象時，因為自動要進行類型轉化，同樣發生錯誤，這兩種錯誤發生後，根本不會訪問後面的流程就跳出了，或許這就是JSP天生的安全性。所以，通常提交的變量是int時，不會發生問題，問題會出現在string參數這裡，如果要查看某用戶的信息，程序可能會讓你提交如下參數：showuser.do? username=kxlzx。問題來了，因為這裡是string類型，所以不懂安全的程序員頂多會判斷一下是不是空，就連加成為SQL語句。有漏洞的程序大概會寫成這個樣子： ACTION的代碼： showuser.do String username = null; username = request.getParameter(“username”); Service service = new Service(); service.findByUsername(username); 得到參數後調用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調用了DB層的JdbcTemplate，把SQL語句拼好後，傳給了JdbcTemplate去執行。不用再看這裡的JdbcTemplate，就可以知道裡面的代碼使用了Statement的executequery()方法執行，導致了SQL注入。分析了這麼半天，有讀者會問：“難道我要費這麼大的力氣才能找到漏洞么？”。的確，通常在ASP程序里找注入時的思路就是這樣子，但是我們現在是在使用了開發模式分層架構的JSP程序里，應該按照分層架構的思維去找漏洞。在回答這個問題之前，我們還得繞個彎子，看看怎麼在這裡預防SQL注入（java始終都是這麼優美，它不會直接告訴你答案，而是一層一層的讓你撥開雲霧）。剛才分析流程，是從正向分析的，從用戶輸入到產生漏洞，我們在防禦的時候，不妨倒過來看看，從DB層入手。JdbcTemplate調用執行SQL語句，可以有兩個類供我們選擇，一個是Statement，另一個就是預處理的Statement，兩者有着效率上和安全上的顯著差別。在效率上，只要數據庫支持預處理技術（sqlserver，mysql，oracle等都支持，只有少數access等不支持），就會在大量執行SQL語句時增加速度；在安全上，使用預處理，會把接受的參數也經過預處理，從而不會作為SQL語句的一部分執行，而是僅僅作為SQL語句中的參數部分

內容被執行。一旦DB層使用了預處理，DAO層的SQL語句也會發生變化，成為這個樣子： 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注入就和我們的程序幾乎無關了，注意我說的是幾乎，而不是全部。知道了怎麼防禦，於是一切在這裡變的簡單極了，我們應該直接去DB層找到JdbcTemplate，看看代碼，一旦使用了Statement，很好，這個系統十有八九有漏洞，下面要做的是使用Editplus搜索“request.getParameter”。沒有使用預處理的系統，可能會在action層進行防禦，對參數過濾，但總有防禦不到的時候，因為戰線拉的太長了，每一個action里都可能接受參數並存在漏洞。還有一種情況，系統一部分使用了預處理，一部分沒有，這樣的情況可能是因為項目趕的比較倉促，人員沒有經過正規培訓，最後艱難的整合到了一起。這種情況也好辦，直接在DAO層搜索（”’）或（’”），這些符號用於和字符串變量連加，拼SQL語句，肯定是這些語句之後的代碼使用了Statement。然後再往上層找，看看哪個action調用了這個有問題的dao類，也可能發生SQL注入。即使系統使用了預處理，別忘了，程序給客戶使用後，客戶有權利去擴展的。程序拿到客戶那裡，客戶有了新的需求，而這個需求又不大，很可能不願意花錢重新僱人來實現擴展功能，在這個時候也可能出現問題，客戶使用自己的程序員擴展AJAX功能，這個程序員因為怕出問題，不敢動源程序，就在web.xml里加了一個servlet，這個servlet直接去調用conn。可怕的事情發生了。所以，我們的搜索漏洞規則中又加上了一條，在非dao層的文件中，搜索“select，update，delete”等字符串。 2、暴露程序信息漏洞這個漏洞是怎麼來的呢？我們需要從異常說起。有經驗的入侵者，可以從JSP程序的異常中獲取很多信息，比如程序的部分架構、程序的物理路徑、SQL注入爆出來的信息等，這個漏洞很容易防禦，卻很難快速定位漏洞文件。出現這樣漏洞的時候，通常是我們在寫代碼的時候，少了一些可能性的考慮而導致的。這樣的問題都是經驗造成的，而尋找漏洞也要通過經驗加運氣（要有仙緣。。。），我個人技術有限，就不多說了。防禦的方法就是在程序中加上“Exception層”，自定義異常，把系統產生的異常統統包裝起來，不要放過任何一個可能產生異常的地方。像騰訊的異常就包裝的很好“對不起，今天的註冊人數已經達到十萬，請您明天再來。。。”，廢話，日註冊量都十萬，還讓不讓人活啦，鐵定是程序發生了異常，不敢讓各位大大們看到真實的面孔。

java web開發如何有效的防止xss攻擊

配置過濾器，再實現 ServletRequest 的包裝類。

將所有的編程全角字符的解決方式。首先添加一個jar包：commons-lang-2.5.jar ，然後在後台調用函數。

Struct2+Spring 架構JavaWeb項目，出現xss跨站腳本攻擊漏洞解決方案？？

沒用到富文本的話可以用spring里的HtmlUtils.htmlEscape(string str)來對parameter轉碼。是用filter還是其他方式都可以

原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/200847.html