跨站腳本攻擊

A. 解析如何防止XSS跨站腳本攻擊

不可信數據 不可信數據通常是來自HTTP請求的數據，以URL參數、表單欄位、標頭或者Cookie的形式。不過從安全形度來看，來自資料庫、網路伺服器和其他來源的數據往往也是不可信的，也就是說，這些數據可能沒有完全通過驗證。 應該始終對不可信數據保持警惕，將其視為包含攻擊，這意味著在發送不可信數據之前，應該採取措施確定沒有攻擊再發送。由於應用程序之間的關聯不斷深化，下游直譯程序執行的攻擊可以迅速蔓延。 傳統上來看，輸入驗證是處理不可信數據的最好辦法，然而，輸入驗證法並不是注入式攻擊的最佳解決方案。首先，輸入驗證通常是在獲取數據時開始執行的，而此時並不知道目的地所在。這也意味著我們並不知道在目標直譯程序中哪些字元是重要的。其次，可能更加重要的是，應用程序必須允許潛在危害的字元進入，例如，是不是僅僅因為SQL認為Mr. O'Malley名字包含特殊字元他就不能在資料庫中注冊呢? 雖然輸入驗證很重要，但這始終不是解決注入攻擊的完整解決方案，最好將輸入攻擊作為縱深防禦措施，而將escaping作為首要防線。 解碼(又稱為Output Encoding) 「Escaping」解碼技術主要用於確保字元作為數據處理，而不是作為與直譯程序的解析器相關的字元。有很多不同類型的解碼，有時候也被成為輸出「解碼」。有些技術定義特殊的「escape」字元，而其他技術則包含涉及若干字元的更復雜的語法。 不要將輸出解碼與Unicode字元編碼的概念弄混淆了，後者涉及映射Unicode字元到位序列。這種級別的編碼通常是自動解碼，並不能緩解攻擊。但是，如果沒有正確理解伺服器和瀏覽器間的目標字元集，有可能導致與非目標字元產生通信，從而招致跨站XSS腳本攻擊。這也正是為所有通信指定Unicode字元編碼(字元集)(如UTF-8等)的重要所在。 Escaping是重要的工具，能夠確保不可信數據不能被用來傳遞注入攻擊。這樣做並不會對解碼數據造成影響，仍將正確呈現在瀏覽器中，解碼只能阻止運行中發生的攻擊。 注入攻擊理論 注入攻擊是這樣一種攻擊方式，它主要涉及破壞數據結構並通過使用特殊字元(直譯程序正在使用的重要數據)轉換為代碼結構。XSS是一種注入攻擊形式，瀏覽器作為直譯程序，攻擊被隱藏在HTML文件中。HTML一直都是代碼和數據最差的mashup，因為HTML有很多可能的地方放置代碼以及很多不同的有效編碼。HTML是很復雜的，因為它不僅是層次結構的，而且還包含很多不同的解析器(XML、HTML、javaScript、VBScript、CSS、URL等)。 要想真正明白注入攻擊與XSS的關系，必須認真考慮HTML DOM的層次結構中的注入攻擊。在HTML文件的某個位置(即開發者允許不可信數據列入DOM的位置)插入數據，主要有兩種注入代碼的方式： Injecting UP，上行注入 最常見的方式是關閉現有的context並開始一個新的代碼context，例如，當你關閉HTML屬性時使用">並開始新的 可以終止腳本塊，即使該腳本塊被注入腳本內方法調用內的引用字元，這是因為HTML解析器在JavaScript解析器之前運行。 Injecting DOWN，下行注入 另一種不太常見的執行XSS注入的方式就是，在不關閉當前context的情況下，引入一個subcontext。例如，將改為 ，並不需要躲開HTML屬性context，相反只需要引入允許在src屬性內寫腳本的context即可。另一個例子就是CSS屬性中的expression()功能，雖然你可能無法躲開引用CSS屬性來進行上行注入，你可以採用x ss:expression(document.write(document.cookie))且無需離開現有context。 同樣也有可能直接在現有context內進行注入，例如，可以採用不可信的輸入並把它直接放入JavaScript context。這種方式比你想像的更加常用，但是根本不可能利用escaping(或者任何其他方式)保障安全。從本質上講，如果這樣做，你的應用程序只會成為攻擊者將惡意代碼植入瀏覽器的渠道。 本文介紹的規則旨在防止上行和下行XSS注入攻擊。防止上行注入攻擊，你必須避免那些允許你關閉現有context開始新context的字元;而防止攻擊跳躍DOM層次級別，你必須避免所有可能關閉context的字元;下行注入攻擊，你必須避免任何可以用來在現有context內引入新的sub-context的字元。 積極XSS防禦模式 本文把HTML頁面當作一個模板，模板上有很多插槽，開發者允許在這些插槽處放置不可信數據。在其他地方放置不可信數據是不允許的，這是「白名單」模式，否認所有不允許的事情。 根據瀏覽器解析HTML的方式的不同，每種不同類型的插槽都有不同的安全規則。當你在這些插槽處放置不可信數據時，必須採取某些措施以確保數據不會「逃離」相應插槽並闖入允許代碼執行的context。從某種意義上說，這種方法將HTML文檔當作參數化的資料庫查詢，數據被保存在具體文職並與escaping代碼context相分離。 本文列出了最常見的插槽位置和安全放置數據的規則，基於各種不同的要求、已知的XSS載體和對流行瀏覽器的大量手動測試，我們保證本文提出的規則都是安全的。 定義好插槽位置，開發者們在放置任何數據前，都應該仔細分析以確保安全性。瀏覽器解析是非常棘手的，因為很多看起來無關緊要的字元可能起著重要作用。 為什麼不能對所有不可信數據進行HTML實體編碼? 可以對放入HTML文檔正文的不可行數據進行HTML實體編碼，如 標簽內。也可以對進入屬性的不可行數據進行實體編碼，尤其是當屬性中使用引用符號時。但是HTML實體編碼並不總是有效，例如將不可信數據放入 directlyinascript insideanHTMLcomment inanattributename <...NEVERPUTUNTRUSTEDDATAHERE...href="/test"/> inatagname 更重要的是，不要接受來自不可信任來源的JavaScript代碼然後運行，例如，名為「callback」的參數就包含JavaScript代碼段，沒有解碼能夠解決。 No.2 – 在向HTML元素內容插入不可信數據前對HTML解碼 這條規則適用於當你想把不可信數據直接插入HTML正文某處時，這包括內部正常標簽(div、p、b、td等)。大多數網站框架都有HTML解碼的方法且能夠躲開下列字元。但是，這對於其他HTML context是遠遠不夠的，你需要部署其他規則。 ...... ...... 以及其他的HTML常用元素 使用HTML實體解碼躲開下列字元以避免切換到任何執行內容，如腳本、樣式或者事件處理程序。在這種規格中推薦使用十六進制實體，除了XML中5個重要字元(&、<、 >、 "、 ')外，還加入了斜線符，以幫助結束HTML實體。 &-->& <-->< >-->> "-->" '-->''isnotrecommended /-->/ ESAPI參考實施 Stringsafe=ESAPI.encoder().encodeForHTML(request.getParameter("input")); No.3 – 在向HTML常見屬性插入不可信數據前進行屬性解碼 這條規則是將不可信數據轉化為典型屬性值(如寬度、名稱、值等)，這不能用於復雜屬性(如href、src、style或者其他事件處理程序)。這是及其重要的規則，事件處理器屬性(為HTML JavaScript Data Values)必須遵守該規則。 content insidesinglequotedattribute 除了字母數字字元外，使用小於256的ASCII值&#xHH格式(或者命名的實體)對所有數據進行解碼以防止切換屬性。這條規則應用廣泛的原因是因為開發者常常讓屬性保持未引用，正確引用的屬性只能使用相應的引用進行解碼。未引用屬性可以被很多字元破壞，包括[space] % * + , - / ; < = > ^ 和 |。 ESAPI參考實施 String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) ); No.4 – 在向HTML JavaScript Data Values插入不可信數據前，進行JavaScript解碼 這條規則涉及在不同HTML元素上制定的JavaScript事件處理器。向這些事件處理器放置不可信數據的唯一安全位置就是「data value」。在這些小代碼塊放置不可信數據是相當危險的，因為很容易切換到執行環境，因此請小心使用。 insideaquotedstring onesideofanexpression insideUNquotedeventhandler insidequotedeventhandler insidequotedeventhandler 除了字母數字字元外，使用小於256的ASCII值xHH格式 對所有數據進行解碼以防止將數據值切換至腳本內容或者另一屬性。不要使用任何解碼捷徑(如" )因為引用字元可能被先運行的HTML屬性解析器相匹配。如果事件處理器被引用，則需要相應的引用來解碼。這條規則的廣泛應用是因為開發者經常讓事件處理器保持未引用。正確引用屬性只能使用相應的引用來解碼，未引用屬性可以使用任何字元(包括[space] % * + , - / ; < = > ^ 和|)解碼。同時，由於HTML解析器比JavaScript解析器先運行，關閉標簽能夠關閉腳本塊，即使腳本塊位於引用字元串中。 ESAPI參考實施 Stringsafe=ESAPI.encoder().encodeForJavaScript(request.getParameter("input")); No.5 – 在向HTML 樣式屬性值插入不可信數居前，進行CSS解碼 當你想將不可信數據放入樣式表或者樣式標簽時，可以用此規則。CSS是很強大的，可以用於許多攻擊。因此，只能在屬性值中使用不可信數據而不能在其他樣式數據中使用。不能將不可信數據放入復雜的屬性(如url,、behavior、和custom (-moz-binding))。同樣，不能將不可信數據放入允許JavaScript的IE的expression屬性值。 propertyvalue textpropertyvalue 除了字母數字字元外，使用小於256的ASCII值HH格式對所有數據進行解碼。不要使用任何解碼捷徑(如" )因為引用字元可能被先運行的HTML屬性解析器相匹配，防止將數據值切換至腳本內容或者另一屬性。同時防止切換至expression或者其他允許腳本的屬性值。如果屬性被引用，將需要相應的引用進行解碼，所有的屬性都應該被引用。未引用屬性可以使用任何字元(包括[space] % * + , - / ; < = > ^ 和|)解碼。同時，由於HTML解析器比JavaScript解析器先運行，標簽能夠關閉腳本塊，即使腳本塊位於引用字元串中。 ESAPI參考實施 Stringsafe=ESAPI.encoder().encodeForCSS(request.getParameter("input")); No.6- 在向HTML URL屬性插入不可信數據前，進行URL解碼 當你想將不可信數據放入鏈接到其他位置的link中時需要運用此規則。這包括href和src屬性。還有很多其他位置屬性，不過我們建議不要在這些屬性中使用不可信數據。需要注意的是在javascript中使用不可信數據的問題，不過可以使用上述的HTML JavaScript Data Value規則。 linkanormallink animagesource ascriptsource 除了字母數字字元外，使用小於256的ASCII值%HH 解碼格式對所有數據進行解碼。在數據中保護不可信數據：URL不能夠被允許，因為沒有好方法來通過解碼來切換URL以避免攻擊。所有的屬性都應該被引用。未引用屬性可以使用任何字元(包括[space] % * + , - / ; < = > ^ 和|)解碼。 請注意實體編碼在這方面是沒用的。

B. 跨站腳本攻擊是什麼意思

XSS，跨站腳本攻擊，Cross-Site
Scripting，為了和前端的CSS避免重名，簡稱為XSS，是指通過技術手段，向正常用戶請求的HTML頁面中插入惡意腳本，執行。
這種攻擊主要是用於信息竊取和破壞等目的。在防範XSS上，主要就是通過對用戶輸入的數據做過濾或者或者轉義，可以使用框架提供的工具類HTML
Util，另外前端在瀏覽器展示數據的時候，要使用安全的API展示數據。比如使用inner text而不是inner HTML。

C. 跨站腳本攻擊的危害

為了搜集用戶信息，攻擊者通常會在有漏洞的程序中插入 JavaScript、VBScript、 ActiveX或Flash以欺騙用戶（詳見下文）。一旦得手，他們可以盜取用戶帳戶，修改用戶設置，盜取/污染cookie，做虛假廣告等。每天都有大量的XSS攻擊的惡意代碼出現。 Brett Moore的下面這篇文章詳細地闡述了「拒絕服務攻擊」以及用戶僅僅閱讀一篇文章就會受到的「自動攻擊」。 1.HTML注入。所有HTML注入範例只是注入一個JavaScript彈出式的警告框：alert(1)。
2.做壞事。如果您覺得警告框還不夠刺激，當受害者點擊了一個被注入了HTML代碼的頁面鏈接時攻擊者能作的各種的惡意事情。
3.誘捕受害者。 「微博病毒」攻擊事件
回顧：
2011年6月28日晚，新浪微博出現了一次比較大的XSS攻擊事件。大量用戶自動發送諸如：「郭美美事件的一些未注意到的細節」，「建黨大業中穿幫的地方」，「讓女人心動的100句詩歌」，「3D肉團團高清普通話版種子」，「這是傳說中的神仙眷侶啊」，「驚爆!范冰冰艷照真流出了」等等微博和私信，並自動關注一位名為hellosamy的用戶。
事件的經過線索如下：
20:14，開始有大量帶V的認證用戶中招轉發蠕蟲
20:30，某網站中的病毒頁面無法訪問
20:32，新浪微博中hellosamy用戶無法訪問
21:02，新浪漏洞修補完畢 隨著AJAX（Asynchronous JavaScript and XML，非同步JavaScript和XML）技術的普遍應用，XSS的攻擊危害將被放大。使用AJAX的最大優點，就是可以不用更新整個頁面來維護數據，Web應用可以更迅速地響應用戶請求。AJAX會處理來自Web伺服器及源自第三方的豐富信息，這對XSS攻擊提供了良好的機會。AJAX應用架構會泄漏更多應用的細節，如函數和變數名稱、函數參數及返回類型、數據類型及有效范圍等。AJAX應用架構還有著較傳統架構更多的應用輸入，這就增加了可被攻擊的點。

D. 跨站腳本攻擊有哪些類型

1、持久型跨站：最直接的危害類型，跨站代碼存儲在伺服器（資料庫）。

2、非持久型跨站：反射型跨站腳本漏洞，最普遍的類型。用戶訪問伺服器-跨站鏈接-返回跨站代碼。

3、DOM跨站（DOM XSS）:DOM(document object model文檔對象模型)，客戶端腳本處理邏輯導致的安全問題。

(4)跨站腳本攻擊擴展閱讀：

跨站腳本攻擊產生的原因是網站過於相信用戶的輸入，那麼解決的辦法也很直接，就是從根本上不相信用戶的任何輸入。一個安全的網站應當對任何用戶的任何輸入都要進行檢查，特別是對用戶提交到伺服器中保存的數據，更要做篩選。

這種攻擊與反射型攻擊不同的是，它會把自己的攻擊代碼保存在網站的伺服器上，這樣，任何訪問了這個頁面的用戶，都會受到這個攻擊。

E. 如何解決跨站腳本攻擊

test
如：<input type="text" id="txtceshi" /><input type="button" onclick="yanzheng()" value="ceshi" />
<script type="text/javascript">
function yanzheng() {
var ce = txtceshi.value;//獲取文本框的值
var ze = /[^0-9]+/; //只能是數字，這里可以在網上找到一些正則替換成你想要的表達式
if (ze.test(ce)) {
alert("數據不合法！");
}
}
</script>

F. 如何進行跨站腳本攻擊

你好~
XSS漏洞產生的原因：

跨站點腳本的主要原因是程序猿對用戶的信任。開發人員輕松地認為用戶永遠不會試圖執行什麼出格的事情,所以他們創建應用程序,卻沒有使用任何額外的代碼來過濾用戶輸入以阻止任何惡意活動。另一個原因是,這種攻擊有許多變體，用製造出一種行之有效的XSS過濾器是一件比較困難的事情。
但是這只是相對的，對用戶輸入數據的」編碼」和」過濾」在任何時候都是很重要的，我們必須採取一些針對性的手段對其進行防禦。

如何創造一個良好的XSS過濾器來阻止大多數XSS攻擊代碼

1 .需要重點」編碼」和」過濾」的對象
The URL
HTTP referrer objects
GET parameters from a form
POST parameters from a form
Window.location
Document.referrer
document.location
document.URL
document.URLUnencoded
cookie data
headers data
database data

防禦XSS有一個原則:
以當前的應用系統為中心，所有的進入應用系統的數據都看成是輸入數據(包括從FORM表單或者從資料庫獲取到的數據)，所有從當前應用系統流出的數據都看作是輸出(包括輸出到用戶瀏覽器或向資料庫寫入數據)
對輸入的數據進行」過濾」，對輸出數據進行」編碼」。這里的」編碼」也要注意，必須針對數據具體的上下文語境進行針對性的編碼。例如數據是輸出到HTML中的那就要進行HtmlEncode，如果數據是輸出到javascript代碼中進行拼接的，那就要進行javascriptEncode。
如果不搞清楚數據具體輸出的語境，就有可能因為HtmlParser()和javascriptParser()兩種解析引擎的執行先後問題導致看似嚴密的」編碼」形同虛設。

G. 跨站腳本攻擊xss和css的區別

傳統防禦技術傳統XSS防禦多採用特徵匹配方式，在所有提交的信息中都進行匹配檢查。對於這種類型的XSS攻擊，採用的模式匹配方法一般會需要對「javascript」這個關鍵字進行檢索，一旦發現提交信息中包含「javascript」，就認定為XSS攻擊

H. 下面這段代碼總是檢測到XSS跨站腳本攻擊漏洞找高手求解

是否有漏洞，取決於你輸出的內容是否可信
比如echo $rows["Author"];
如$rows["Author"]裡面是由用戶輸入且入庫未過濾，那麼直接輸出時存在xss漏洞的。
如$rows["Author"]輸入的值為〈script〉 alert( 1 )〈/script 〉
那麼直接輸出存在漏洞，
簡單點修改 echo htmlentities($rows["Author"]),其他echo的類似
如果輸出內容可信（過濾過，或來源可信安全）那麼直接輸出也不存在問題，程序檢測的未必准確。

入庫過濾了或者本身內容來源可靠不存在此漏洞。

I. DOM 跨站腳本攻擊問題，怎麼解決

跨站腳本攻擊（Cross Site Scripting）是指攻擊者利用網站程序對用戶輸入過濾不足，輸入可以顯示在頁面上對其他用戶造成影響的HTML代碼，從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。為了與層疊樣式表（Cascading Style Sheets）的縮寫CSS區分開，跨站腳本攻擊通常簡寫為XSS。
下面這個頁面的主要作用是獲取用戶輸入的參數作為用戶名，並在頁面中顯示「歡迎您，XXX」的形式，具體代碼如下：
<?php
$username = $_GET["name"];
echo "<p>歡迎您, ".$username."!</p>";