❶ 如何防止xss攻擊，需要過濾什麼
XSS攻擊通常是指黑客通過"HTML注入"篡改了網頁，插入了惡意的腳本，從而在用戶瀏覽網頁時，控制用戶瀏覽器的一種攻擊。
一、HttpOnly防止劫取Cookie
HttpOnly最早由微軟提出，至今已經成為一個標准。瀏覽器將禁止頁面的javascript訪問帶有HttpOnly屬性的Cookie。目前主流瀏覽器都支持，HttpOnly解決是XSS後的Cookie支持攻擊。
我們來看下網路有沒有使用。
未登錄時的Cookie信息
可以看到，所有Cookie都沒有設置HttpOnly，現在我登錄下
發現在個叫BDUSS的Cookie設置了HttpOnly。可以猜測此Cookie用於認證。
下面我用php來實現下：
<?php
header("Set-Cookie: cookie1=test1;");
header("Set-Cookie: cookie2=test2;httponly",false);
setcookie('cookie3','test3',NULL,NULL,NULL,NULL,false);
setcookie('cookie4','test4',NULL,NULL,NULL,NULL,true);
?>
<script>
alert(document.cookie);
</script>
js只能讀到沒有HttpOnly標識的Cookie
二、輸入檢查
輸入檢查一般是檢查用戶輸入的數據中是否包含一些特殊字元，如<、>、'、"等，如果發現存在特殊字元，則將這些字元過濾或者編碼。
例如網站注冊經常用戶名只允許字母和數字的組合，或者郵箱電話，我們會在前端用js進行檢查，但在伺服器端代碼必須再次檢查一次，因為客戶端的檢查很容易繞過。
網上有許多開源的「XSS Filter」的實現，但是它們應該選擇性的使用，因為它們對特殊字元的過濾可能並非數據的本意。比如一款php的lib_filter類：
$filter = new lib_filter();
echo $filter->go('1+1>1');
它輸出的是1，這大大歪曲了數據的語義，因此什麼情況應該對哪些字元進行過濾應該適情況而定。
三、輸出檢查
大多人都知道輸入需要做檢查，但卻忽略了輸出檢查。
1、在HTML標簽中輸出
如代碼：
<?php
$a = "<script>alert(1);</script>";
$b = "<img src=# onerror=alert(2) />";
?>
<div><?=$b?></div>
<a href="#"><?=$a?></a>
這樣客戶端受到xss攻擊，解決方法就是對變數使用htmlEncode,php中的函數是htmlentities
<?php
$a = "<script>alert(1);</script>";
$b = "<img src=# onerror=alert(2) />";
?>
<div><?=htmlentities($b)?></div>
<a href="#"><?=htmlentities($a)?></a>
2、在HTML屬性中輸出
<div id="div" name ="$var"></div>
這種情況防禦也是使用htmlEncode
在owasp-php中實現：
$immune_htmlattr = array(',', '.', '-', '_');
$this->htmlEntityCodec->encode($this->immune_htmlattr, "\"><script>123123;</script><\"");
3、在<script>標簽中輸出
如代碼：
<?php
$c = "1;alert(3)";
?>
<script type="text/javascript">
var c = <?=$c?>;
</script>
這樣xss又生效了。首先js變數輸出一定要在引號內，但是如果我$c = "\"abc;alert(123);//"，你會發現放引號中都沒用，自帶的函數都不能很好的滿足。這時只能使用一個更加嚴格的JavascriptEncode函數來保證安全——除數字、字母外的所有字元，都使用十六進制"\xHH"的方式進行編碼。這里我採用開源的owasp-php方法來實現
$immune = array("");
echo $this->javascriptCodec->encode($immune, "\"abc;alert(123);//");
最後輸出\x22abc\x3Balert\x28123\x29\x3B\x2F\x2F
4、在事件中輸出
<a href="#" onclick="funcA('$var')" >test</a>
可能攻擊方法
<a href="#" onclick="funcA('');alter(/xss/;//')">test</a>
這個其實就是寫在<script>中，所以跟3防禦相同
5、在css中輸出
在owasp-php中實現：
$immune = array("");
$this->cssCodec->encode($immune, 'background:expression(window.x?0:(alert(/XSS/),window.x=1));');
6、在地址中輸出
先確保變數是否是"http"開頭，然後再使用js的encodeURI或encodeURIComponent方法。
在owasp-php中實現：
$instance = ESAPI::getEncoder();
$instance->encodeForURL(『url』);
四、處理富文體
就像我寫這篇博客，我幾乎可以隨意輸入任意字元，插入圖片，插入代碼，還可以設置樣式。這個時要做的就是設置好白名單，嚴格控制標簽。能自定義 css件麻煩事，因此最好使用成熟的開源框架來檢查。php可以使用htmlpurify
五、防禦DOM Based XSS
DOM Based XSS是從javascript中輸出數據到HTML頁面里。
<script>
var x = "$var";
document.write("<a href='"+x+"'>test</a>");
</script>
按照三中輸出檢查用到的防禦方法，在x賦值時進行編碼，但是當document.write輸出數據到HTML時，瀏覽器重新渲染了頁面，會將x進行解碼，因此這么一來，相當於沒有編碼，而產生xss。
防禦方法：首先，還是應該做輸出防禦編碼的，但後面如果是輸出到事件或腳本，則要再做一次javascriptEncode編碼，如果是輸出到HTML內容或屬性，則要做一次HTMLEncode。
會觸發DOM Based XSS的地方有很多：
document.write()、document.writeln()、xxx.innerHTML=、xxx.outerHTML=、innerHTML.replace、document.attachEvent()、window.attachEvent()、document.location.replace()、document.location.assign()
❷ java正則表達式怎麼防止代碼漏洞
javaWeb安全漏洞及處理方式
關注
轉載自：https://blog.csdn.net/lujiancs/article/details/78175007
1、SQL注入攻擊
SQL注入攻擊就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將(惡意)的SQL命令注入到後台資料庫引擎執行的能力，它可以通過在Web表單中輸入(惡意)SQL語句得到一個存在安全漏洞的網站上的資料庫，而不是按照設計者意圖去執行SQL語句。
隨著B/S框架結構在系統開發中的廣泛應用，惡意攻擊者利用SQL命令在Web表單中輸入合法的字元或查詢字元串來欺騙伺服器執行SQL命令。當注入攻擊得逞後，Web程序將泄露大量用戶隱私數據和資料庫中數據結構。攻擊者能夠獲得系統較高的訪問許可權，進行破壞操作。
SQL注入可以分為平台層注入和代碼層注入。前者由不安全的資料庫配置或資料庫平台的漏洞所致;後者主要是由於程序員對輸入未進行細致地過濾，從而執行了非法的數據查詢。基於此，SQL注入的產生原因通常表現在以下幾方面:
1）不當的類型處理;
2）不安全的資料庫配置;
3）不合理的查詢集處理;
4）不當的錯誤處理;
5）轉義字元處理不合適;
6) 多個提交處理不當。
解決方法:
資料庫安全通信包括SQL注入攻擊的防範、安全設置、異常信息處理三個方面。
1.服務端Filter對訪問者輸入的字元進行過濾檢驗，但是攻擊者經常把危險字元潛藏在用戶輸入的有效字元中完 成過濾檢驗。
2.通過正則表達式對頁面的文本框輸入的數據進行限制可以減少過濾檢驗存在的漏洞。
3.使用prepareStatment預編譯sql語句
2、XSS跨站腳本攻擊
跨站腳本（Cross-site scripting，簡稱XSS），是一種迫使Web站點回顯可執行代碼的攻擊技術，而這些可執行代碼由攻擊者提供、最終為用戶瀏覽器載入。不同於大多數攻擊（一般只涉及攻擊者和受害者），XSS涉及到三方，即攻擊者、客戶端與網站。XSS的攻擊目標是為了盜取客戶端的cookie或者其他網站用於識別客戶端身份的敏感信息。獲取到合法用戶的信息後，攻擊者甚至可以假冒最終用戶與網站進行交互。
XSS 屬於被動式的攻擊。攻擊者先構造一個跨站頁面，利用SCRIPT、<IMG>、<IFRAME>等各種方式使得用戶瀏覽這個頁面時，觸發對被攻擊站點的HTTP 請求。此時，如果被攻擊者如果已經在被攻擊站點登錄，就會持有該站點cookie。這樣該站點會認為被攻擊者發起了一個HTTP請求。而實際上這個請求是在被攻擊者不知情情況下發起的，由此攻擊者在一定程度上達到了冒充被攻擊者的目的。精心的構造這個攻擊請求，可以達到冒充發文，奪取許可權等多個攻擊目的。在常見的攻擊實例中，這個請求是通過script 來發起的，因此被稱為Cross Site Script。
XSS漏洞成因是由於動態網頁的Web應用對用戶提交請求參數未做充分的檢查過濾，允許用戶在提交的數據中摻入HTML代碼（最主要的是「>」、「<」），然後未加編碼地輸出到第三方用戶的瀏覽器，這些攻擊者惡意提交代碼會被受害用戶的瀏覽器解釋執行。
分為三種類型：
1）反射型（數據流向：瀏覽器 ->後端 -> 瀏覽器）
反射型XSS腳本攻擊即如我們上面所提到的XSS跨站腳本攻擊方式，該類型只是簡單地將用戶輸入的數據直接或未經過完善的安全過濾就在瀏覽器中進行輸出，導致輸出的數據中存在可被瀏覽器執行的代碼數據。由於此種類型的跨站代碼存在於URL中，所以黑客通常需要通過誘騙或加密變形等方式，將存在惡意代碼的鏈接發給用戶，只有用戶點擊以後才能使得攻擊成功實施。
2）存儲型（數據流向是：瀏覽器 ->後端 -> 資料庫 -> 後端-> 瀏覽器）
存儲型XSS腳本攻擊是指Web應用程序會將用戶輸入的數據信息保存在服務端的資料庫或其他文件形式中，網頁進行數據查詢展示時，會從資料庫中獲取數據內容，並將數據內容在網頁中進行輸出展示，因此存儲型XSS具有較強的穩定性。
存儲型XSS腳本攻擊最為常見的場景就是在博客或新聞發布系統中，黑客將包含有惡意代碼的數據信息直接寫入文章或文章評論中，所有瀏覽文章或評論的用戶，都會在他們客戶端瀏覽器環境中執行插入的惡意代碼。
3）基於DOM（數據流向是：URL-->瀏覽器 ）
基於DOM的XSS跨站腳本攻擊是通過修改頁面DOM節點數據信息而形成的XSS跨站腳本攻擊。不同於反射型XSS和存儲型XSS，基於DOM的XSS跨站腳本攻擊往往需要針對具體的javascript DOM代碼進行分析，並根據實際情況進行XSS跨站腳本攻擊的利用。
解決方法：
1).輸入過濾。對用戶的所有輸入數據進行檢測，比如過濾其中的「<」、「>」、「/」等可能導致腳本注入的特殊字元，或者過濾「script」、「javascript」等腳本關鍵字，或者對輸入數據的長度進行限制等等。同時，我們也要考慮用戶可能繞開ASCII碼，使用十六進制編碼來輸入腳本。因此，對用戶輸入的十六進制編碼，我們也要進行相應的過濾。只要能夠嚴格檢測每一處交互點，保證對所有用戶可能的輸入都進行檢測和XSS過濾，就能夠有效地阻止XSS攻擊。
2).輸出編碼。通過前面對XSS攻擊的分析，我們可以看到，之所以會產生XSS攻擊，就是因為Web應用程序將用戶的輸入直接嵌入到某個頁面當中，作為該頁面的HTML代碼的一部分。因此，當Web應用程序將用戶的輸入數據輸出到目標頁面中時，只要用HtmlEncoder等工具先對這些數據進行編碼，然後再輸出到目標頁面中。這樣，如果用戶輸入一些HTML的腳本，也會被當成普通的文字，而不會成為目標頁面HTML代碼的一部分得到執行.
3、CSRF跨站請求偽造漏洞防護
CSRF是CrossSite Request Forgery的縮寫，乍一看和XSS差不多的樣子，但是其原理正好相反，XSS是利用合法用戶獲取其信息，而CSRF是偽造成合法用戶發起請求。
字面理解意思就是在別的站點偽造了一個請求。專業術語來說就是在受害者訪問一個網站時，其 Cookie 還沒有過期的情況下，攻擊者偽造一個鏈接地址發送受害者並欺騙讓其點擊，從而形成 CSRF 攻擊。
根據HTTP協議，在HTTP頭中有一個欄位叫Referer，它記錄了該HTTP請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求必須來自於同一個網站。
解決方案：
配置FILTER攔截用戶所有請求(POST/GET)，對用戶請求Referer頭URL進行合法性校驗。
4、URL鏈接注入漏洞防護
鏈接注入是修改站點內容的行為，其方式為將外部站點的 URL 嵌入其中，或將有易受攻擊的站點中的腳本 的 URL 嵌入其中。將URL 嵌入易受攻擊的站點中，攻擊者便能夠以它為平台來啟動對其他站點的攻擊，以及攻擊這個易受攻擊的站點本身。
解決方案：
1，二次驗證，進行重要敏感操作時，要求用戶進行二次驗證。
2，驗證碼，進行重要敏感操作時，加入驗證碼。
3，驗證 HTTP 的 Referer 欄位。
4，請求地址中添加 Token 並驗證。
5，HTTP 頭中自定義屬性並驗證。
5、會話COOKIE中缺少HttpOnly防護
會話cookie中缺少HttpOnly屬性會導致攻擊者可以通過程序(JS腳本、Applet等)獲取到用戶的cookie信息，造成用戶cookie信息泄露，增加攻擊者的跨站腳本攻擊威脅。
HttpOnly是微軟對cookie做的擴展，該值指定cookie是否可通過客戶端腳本訪問。Microsoft Internet Explorer 版本 6 Service Pack 1 和更高版本支持cookie屬性HttpOnly。
如果在Cookie中沒有設置HttpOnly屬性為true，可能導致Cookie被竊取。竊取的Cookie可以包含標識站點用戶的敏感信息。
如果在Cookie中設置HttpOnly屬性為true，兼容瀏覽器接收到HttpOnly cookie，那麼客戶端通過程序(JS腳本、Applet等)將無法讀取到Cookie信息，這將有助於緩解跨站點腳本威脅。
解決方案：
配置filter攔截器，將伺服器端返回請求，向所有會話cookie中添加「HttpOnly」屬性。
示例代碼：
HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;
response.setHeader("SET-COOKIE","JSESSIONID=" + sessionid + "; HttpOnly");
6、點擊劫持漏洞(Clickjacking)防護
點擊劫持是一種視覺上的欺騙手段，攻擊者使用一個透明的、不可見的iframe，覆蓋在一個網頁上，然後誘使用戶在該網頁上進行操作，此時用戶在不知情的情況下點擊了透明的iframe頁面。通過調整iframe頁面的位置，可以誘使用戶恰好點擊在iframe頁面的一些功能性按鈕上。
解決方案：
配置FILTER攔截器，在伺服器端返回請求中，使用一個HTTP頭「X-Frame-Options」值為SAMEORIGIN-同源策略 ，則frame頁面的地址只能為同源域名下面的頁面，防止點擊劫持漏洞發生。
示例代碼：
HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;
response.addHeader("x-frame-options","SAMEORIGIN");
7、HTTP host 頭攻擊漏洞
使用HTTP代理工具，可以篡改HTTP報文頭部中HOST欄位時，該值可被注入惡意代碼。因為需要控制客戶端的輸入，故該漏洞較難利用。
解決方案：
配置FILTER攔截器，對請求輸入HOST頭信息進行信息安全性校驗，防止HOST頭信息被惡意篡改利用。
示例代碼：
HttpServletRequest request =(HttpServletRequest)servletRequest;
//主機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、越權訪問漏洞防護
越權訪問（Broken Access Control，簡稱BAC）是Web應用程序中一種常見的漏洞，分為垂直越權訪問和水平越權訪問。垂直越權是指不同用戶級別之間的越權，如普通用戶執行管理員用戶的許可權。水平越權是指相同級別用戶之間的越權操作。
Web應用程序如果存在越權訪問漏洞，可能導致以下危害：
1）導致任意用戶敏感信息泄露；
2）導致任意用戶信息被惡意修改或刪除。
解決方案：
配置FILTER攔截器，對請求所有URL進行攔截，對於需要進行授權的URL進行許可權校驗，防止用戶越權訪問系統資源。
9.弱口令漏洞
解決方案：最好使用至少6位的數字、字母及特殊字元組合作為密碼。資料庫不要存儲明文密碼，應存儲MD5加密後的密文，由於目前普通的MD5加密已經可以被破解，最好可以多重MD5加密，或者多種加密方式疊加組合。
10．JSP頁面拋出的異常可能暴露程序信息。
有經驗的入侵者，可以從JSP程序的異常中獲取很多信息，比如程序的部分架構、程序的物理路徑、SQL注入爆出來的信息等。
解決方案：自定義一個Exception，將異常信息包裝起來不要拋到頁面上。
11.本地緩存漏洞
合法用戶「注銷」後，在未關閉瀏覽器的情況下，點擊瀏覽器「後退」按鈕，可從本地頁面緩存中讀取數據，繞過了服務端filter過濾。
解決方案：配置filter對存放敏感信息的頁面限制頁面緩存。如：
httpResponse.setHeader("Cache-Control","no-cache");
httpResponse.setHeader("Cache-Control","no-store");
httpResponse.setDateHeader("Expires",0);
httpResponse.setHeader("Pragma","no-cache");
12.文件上傳漏洞。
前台僅使用JS對文件後綴做了過濾，這只能針對普通的用戶，而惡意攻擊者完全可以修改表單去掉JS校驗。
13.Java WEB容器默認配置漏洞。
如TOMCAT後台管理漏洞，默認用戶名及密碼登錄後可直接上傳war文件獲取webshell。
解決方案：最好刪除，如需要使用它來管理維護，可更改其默認路徑，口令及密碼。
❸ java服務介面怎麼避免xss注入攻擊
過濾特定符號
publicstaticStringguolv(Stringa){
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("\)","");
a=a.replaceAll("and","");
a=a.replaceAll("or","");
a=a.replaceAll("1=1","");
returna;
}