方法防范xss漏洞(xss注入漏洞產(chǎn)生的原因)
1.xss注入漏洞產(chǎn)生的原因
對(duì)于的用戶輸入中出現(xiàn)XSS漏洞的問題，主要是由于開發(fā)人員對(duì)XSS了解不足，安全的意識(shí)不夠造成的。
現(xiàn)在讓我們來普及一下XSS的一些常識(shí)，以后在開發(fā)的時(shí)候，每當(dāng)有用戶輸入的內(nèi)容時(shí)，都要加倍小心。請(qǐng)記住兩條原則：過濾輸入和轉(zhuǎn)義輸出。
一、什么是XSSXSS又叫CSS (Cross Site Script) ，跨站腳本攻擊。它指的是惡意攻擊者往Web頁(yè)面里插入惡意html代碼，當(dāng)用戶瀏覽該頁(yè)之時(shí)，嵌入其中Web里面的html代碼會(huì)被執(zhí)行，從而達(dá)到惡意的特殊目的。
XSS屬于被動(dòng)式的攻擊，因?yàn)槠浔粍?dòng)且不好利用，所以許多人常呼略其危害性。在WEB2.0時(shí)代，強(qiáng)調(diào)的是互動(dòng)，使得用戶輸入信息的機(jī)會(huì)大增，在這個(gè)情況下，我們作為開發(fā)者，在開發(fā)的時(shí)候，要提高警惕。
二、XSS攻擊的主要途徑XSS攻擊方法只是利用HTML的屬性，作各種的嘗試，找出注入的方法?，F(xiàn)在對(duì)三種主要方式進(jìn)行分析。
第一種：對(duì)普通的用戶輸入，頁(yè)面原樣內(nèi)容輸出。打開tag顯示出來。
（2）實(shí)現(xiàn)Session 標(biāo)記（session tokens）、CAPTCHA（驗(yàn)證碼）系統(tǒng)或者HTTP引用頭檢查，以防功能被第三方網(wǎng)站所執(zhí)行，對(duì)于用戶提交信息的中的img等link，檢查是否有重定向回本站、不是真的圖片等可疑操作。（3）cookie 防盜。
避免直接在cookie中泄露用戶隱私，例如email、密碼，等等；通過使cookie和系統(tǒng)IP綁定來降低cookie泄露后的危險(xiǎn)。這樣攻擊者得到的cookie沒有實(shí)際價(jià)值，很難拿來直接進(jìn)行重放攻擊。
（4）確認(rèn)接收的內(nèi)容被妥善地規(guī)范化，僅包含最小的、安全的Tag（沒有JavaScript），去掉任何對(duì)遠(yuǎn)程內(nèi)容的引用（尤其是樣式表和JavaScript），使用HTTPonly的cookie。
3.如何防御XSS
要想從根本上解決XSS攻擊，就要對(duì)Web應(yīng)用程序源代碼進(jìn)行檢查，發(fā)現(xiàn)安全漏洞進(jìn)行修改。
但是這種方法在實(shí)際中給用戶帶來了不便，如：需要花費(fèi)大copy量的人力財(cái)力；可能無法找到當(dāng)時(shí)的網(wǎng)站開發(fā)人員、需要網(wǎng)站下線等。對(duì)代碼進(jìn)行修改后，由于增加了過濾條件和功能，同時(shí)也給服務(wù)器帶來了計(jì)算壓力。
通常的解決方法是在數(shù)據(jù)庫(kù)服務(wù)器前端部署入侵防zd御產(chǎn)品。XSS攻擊具有變種多、隱蔽性強(qiáng)等特點(diǎn)，傳統(tǒng)的特征匹配檢測(cè)方式不能有效地進(jìn)行防御，需要采用基于攻擊手法的行為監(jiān)測(cè)的入侵防御產(chǎn)品產(chǎn)品才能夠精確地檢測(cè)到XSS攻擊。
4.如何避免XSS攻擊和SQL注入
所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁(yè)面請(qǐng)求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。具體來說，它是利用現(xiàn)有應(yīng)用程序，將（惡意）的SQL命令注入到后臺(tái)數(shù)據(jù)庫(kù)引擎執(zhí)行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個(gè)存在安全漏洞的網(wǎng)站上的數(shù)據(jù)庫(kù)，而不是按照設(shè)計(jì)者意圖去執(zhí)行SQL語句。比如先前的很多影視網(wǎng)站泄露VIP會(huì)員密碼大多就是通過WEB表單遞交查詢字符暴出的，這類表單特別容易受到SQL注入式攻擊.
防護(hù)
歸納一下，主要有以下幾點(diǎn)：
1.永遠(yuǎn)不要信任用戶的輸入。對(duì)用戶的輸入進(jìn)行校驗(yàn)，可以通過正則表達(dá)式，或限制長(zhǎng)度；對(duì)單引號(hào)和
雙"-"進(jìn)行轉(zhuǎn)換等。
2.永遠(yuǎn)不要使用動(dòng)態(tài)拼裝sql，可以使用參數(shù)化的sql或者直接使用存儲(chǔ)過程進(jìn)行數(shù)據(jù)查詢存取。
3.永遠(yuǎn)不要使用管理員權(quán)限的數(shù)據(jù)庫(kù)連接，為每個(gè)應(yīng)用使用單獨(dú)的權(quán)限有限的數(shù)據(jù)庫(kù)連接。
4.不要把機(jī)密信息直接存放，加密或者h(yuǎn)ash掉密碼和敏感的信息。
5.應(yīng)用的異常信息應(yīng)該給出盡可能少的提示，最好使用自定義的錯(cuò)誤信息對(duì)原始錯(cuò)誤信息進(jìn)行包裝
6.sql注入的檢測(cè)方法一般采取輔助軟件或網(wǎng)站平臺(tái)來檢測(cè)，軟件一般采用sql注入檢測(cè)工具jsky，網(wǎng)站平臺(tái)就有億思網(wǎng)站安全平臺(tái)檢測(cè)工具。MDCSOFT SCAN等。采用MDCSOFT-IPS可以有效的防御SQL注入，XSS攻擊等。
5.Web應(yīng)用常見的安全漏洞有哪些
Web應(yīng)用常見的安全漏洞：
1、SQL注入
注入是一個(gè)安全漏洞，允許攻擊者通過操縱用戶提供的數(shù)據(jù)來更改后端SQL語句。 當(dāng)用戶輸入作為命令或查詢的一部分被發(fā)送到解釋器并且欺騙解釋器執(zhí)行非預(yù)期的命令并且允許訪問未授權(quán)的數(shù)據(jù)時(shí)，發(fā)生注入。
2、跨站腳本攻擊 （XSS）
XSS漏洞針對(duì)嵌入在客戶端（即用戶瀏覽器而不是服務(wù)器端）的頁(yè)面中嵌入的腳本。當(dāng)應(yīng)用程序獲取不受信任的數(shù)據(jù)并將其發(fā)送到Web瀏覽器而未經(jīng)適當(dāng)驗(yàn)證時(shí)，可能會(huì)出現(xiàn)這些缺陷。
3、跨站點(diǎn)請(qǐng)求偽造
CSRF攻擊是指惡意網(wǎng)站，電子郵件或程序?qū)е掠脩舻臑g覽器在用戶當(dāng)前已對(duì)其進(jìn)行身份驗(yàn)證的受信任站點(diǎn)上執(zhí)行不需要的操作時(shí)發(fā)生的攻擊。
4、無法限制URL訪問
Web應(yīng)用程序在呈現(xiàn)受保護(hù)的鏈接和按鈕之前檢查URL訪問權(quán)限 每次訪問這些頁(yè)面時(shí)，應(yīng)用程序都需要執(zhí)行類似的訪問控制檢查。 通過智能猜測(cè)，攻擊者可以訪問權(quán)限頁(yè)面。攻擊者可以訪問敏感頁(yè)面，調(diào)用函數(shù)和查看機(jī)密信息。
5、不安全的加密存儲(chǔ)
不安全的加密存儲(chǔ)是一種常見的漏洞，在敏感數(shù)據(jù)未安全存儲(chǔ)時(shí)存在。 用戶憑據(jù)，配置文件信息，健康詳細(xì)信息，信用卡信息等屬于網(wǎng)站上的敏感數(shù)據(jù)信息。
擴(kuò)展資料
web應(yīng)用漏洞發(fā)生的市場(chǎng)背景：
由于Web服務(wù)器提供了幾種不同的方式將請(qǐng)求轉(zhuǎn)發(fā)給應(yīng)用服務(wù)器，并將修改過的或新的網(wǎng)頁(yè)發(fā)回給最終用戶，這使得非法闖入網(wǎng)絡(luò)變得更加容易。
許多程序員不知道如何開發(fā)安全的應(yīng)用程序。他們的經(jīng)驗(yàn)也許是開發(fā)獨(dú)立應(yīng)用程序或Intranet Web應(yīng)用程序，這些應(yīng)用程序沒有考慮到在安全缺陷被利用時(shí)可能會(huì)出現(xiàn)災(zāi)難性后果。
許多Web應(yīng)用程序容易受到通過服務(wù)器、應(yīng)用程序和內(nèi)部已開發(fā)的代碼進(jìn)行的攻擊。這些攻擊行動(dòng)直接通過了周邊防火墻安全措施，因?yàn)槎丝?0或443(SSL，安全套接字協(xié)議層)必須開放，以便讓應(yīng)用程序正常運(yùn)行。
參考資料來源：搜狗百科-WEB安全漏洞
參考資料來源：搜狗百科-Web安全
6.如何防止xss攻擊,需要過濾什么
XSS攻擊通常是指黑客通過"HTML注入"篡改了網(wǎng)頁(yè)，插入了惡意的腳本，從而在用戶瀏覽網(wǎng)頁(yè)時(shí)，控制用戶瀏覽器的一種攻擊。
一、HttpOnly防止劫取CookieHttpOnly最早由微軟提出，至今已經(jīng)成為一個(gè)標(biāo)準(zhǔn)。瀏覽器將禁止頁(yè)面的Javascript訪問帶有HttpOnly屬性的Cookie。
目前主流瀏覽器都支持，HttpOnly解決是XSS后的Cookie支持攻擊。我們來看下百度有沒有使用。
未登錄時(shí)的Cookie信息可以看到，所有Cookie都沒有設(shè)置HttpOnly，現(xiàn)在我登錄下發(fā)現(xiàn)在個(gè)叫BDUSS的Cookie設(shè)置了HttpOnly?？梢圆聹y(cè)此Cookie用于認(rèn)證。
下面我用PHP來實(shí)現(xiàn)下：<?phpheader("Set-Cookie: cookie1=test1;");header("Set-Cookie: cookie2=test2;Encode,php中的函數(shù)是htmlentities<?php$a = "";$b = "";?><?=htmlentities($b)?><?=htmlentities($a)?>2、在HTML屬性中輸出這種情況防御也是使用htmlEncode在owasp-php中實(shí)現(xiàn)：$immune_htmlattr = array(',', '.', '-', '_');$this->htmlEntityCodec->encode($this->immune_htmlattr, "\"><\"");3、在這樣xss又生效了。
首先js變量輸出一定要在引號(hào)內(nèi)，但是如果我$c = "\"abc;alert(123)；//"，你會(huì)發(fā)現(xiàn)放引號(hào)中都沒用，自帶的函數(shù)都不能很好的滿足。這時(shí)只能使用一個(gè)更加嚴(yán)格的JavascriptEncode函數(shù)來保證安全——除數(shù)字、字母外的所有字符，都使用十六進(jìn)制"\xHH"的方式進(jìn)行編碼。
這里我采用開源的owasp-php方法來實(shí)現(xiàn)$immune = array("");echo $this->javascriptCodec->encode($immune, "\"abc;alert(123);//");最后輸出\x22abc\x3Balert\x28123\x29\x3B\x2F\x2F4、在事件中輸出test可能攻擊方法xss/;//')">test這個(gè)其實(shí)就是寫在按照三中輸出檢查用到的防御方法，在x賦值時(shí)進(jìn)行編碼，但是當(dāng)document.write輸出數(shù)據(jù)到HTML時(shí)，瀏覽器重新渲染了頁(yè)面，會(huì)將x進(jìn)行解碼，因此這么一來，相當(dāng)于沒有編碼，而產(chǎn)生xss。防御方法：首先，還是應(yīng)該做輸出防御編碼的，但后。
