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