『壹』 xss漏洞如何防禦
防禦方法
(1)基於特徵的防禦。XSS漏洞和著名的SQL注入漏洞一樣，都是利用了Web頁面的編寫不完善，所以每一個漏洞所利用和針對的弱點都不盡相同。這就給XSS漏洞防禦帶來了困難，不可能以單一特徵來概括所有XSS攻擊。
傳統的XSS防禦在進行攻擊鑒別時多採用特徵匹配方式，主要是針對「javascript」這個關鍵字進行檢索，但是這種鑒別不夠靈活，凡是提交的信息中各有「javascript」時，就被硬性的被判定為XSS攻擊。
(2)基於代碼修改的防禦。Web頁面開發者在編寫程序時往往會出現一些失誤和漏洞，XSS攻擊正是利用了失誤和漏洞，因此一種比較理想的方法就是通過優化Web應用開發來減少漏洞，避免被攻擊：1)用戶向伺服器上提交的信息要對URL和附帶的的HTTP頭、POST數據等進行查詢，對不是規定格式、長度的內容進行過濾。2)實現Session標記（session tokens）、CAPTCHA系統或者HTTP引用頭檢查，以防功能被第三方網站所執行。3)確認接收的的內容被妥善的規范化，僅包含最小的、安全的Tag（沒有javascript），去掉任何對遠程內容的引用（尤其是樣式表和javascript），使用HTTP only的cookie。
當然，如上操作將會降低Web業務系統的可用性，用戶僅能輸入少量的制定字元，人與系統間的交互被降到極致，僅適用於信息發布型站點。並且考慮到很少有Web編碼人員受過正規的安全培訓，很難做到完全避免頁面中的XSS漏洞。
(3)客戶端分層防禦策略。客戶端跨站腳本攻擊的分層防禦策略是基於獨立分配線程和分層防禦策略的安全模型。它建立在客戶端(瀏覽器)，這是它與其他模型最大的區別，之所以客戶端安全性如此重要，客戶端在接受伺服器信息，選擇性的執行相關內容。這樣就可以使防禦XSS攻擊變得容易，該模型主要由三大部分組成：（1）對每一個網頁分配獨立線程且分析資源消耗的「網頁線程分析模塊」；
（2）包含分層防禦策略四個規則的用戶輸入分析模塊；
（3）保存互聯網上有關XSS惡意網站信息的XSS信息資料庫。
XSS攻擊主要是由程序漏洞造成的，要完全防止XSS安全漏洞主要依靠程序員較高的編程能力和安全意識，當然安全的軟體開發流程及其他一些編程安全原則也可以大大減少XSS安全漏洞的發生。這些防範XSS漏洞原則包括：
（1）不信任用戶提交的任何內容，對所有用戶提交內容進行可靠的輸入驗證，包括對URL、查詢關鍵字、HTTP頭、REFER、POST數據等，僅接受指定長度范圍內、採用適當格式、採用所預期的字元的內容提交，對其他的一律過濾。盡量採用POST而非GET提交表單；對「<」，「>」，「；」，「」」等字元做過濾；任何內容輸出到頁面之前都必須加以en-code，避免不小心把htmltag顯示出來。
（2）實現Session 標記（session tokens）、CAPTCHA（驗證碼）系統或者HTTP引用頭檢查，以防功能被第三方網站所執行，對於用戶提交信息的中的img等link，檢查是否有重定向回本站、不是真的圖片等可疑操作。
（3）cookie 防盜。避免直接在cookie中泄露用戶隱私，例如email、密碼，等等；通過使cookie和系統IP綁定來降低cookie泄露後的危險。這樣攻擊者得到的cookie沒有實際價值，很難拿來直接進行重放攻擊。
（4）確認接收的內容被妥善地規范化，僅包含最小的、安全的Tag（沒有JavaScript），去掉任何對遠程內容的引用（尤其是樣式表和JavaScript），使用HTTPonly的cookie。
『貳』 XSS跨站腳本攻擊剖析與防禦的內容介紹
《XSS跨站腳本攻擊剖析與防禦》是一本專門剖析XSS安全的專業書，總共8章，主要包括的內容如下。第1章 XSS初探，主要闡述了XSS的基礎知識，包括XSS的攻擊原理和危害。第2章 XSS利用方式，就當前比較流行的XSS利用方式做了深入的剖析，這些攻擊往往基於客戶端，從掛馬、竊取Cookies、會話劫持到釣魚欺騙，各種攻擊都不容忽視。第3章 XSS測試和利用工具，介紹了一些常見的XSS測試工具。第4章 發掘XSS漏洞，著重以黑盒和白盒的角度介紹如何發掘XSS漏洞，以便幫助讀者樹立安全意識。第5章 XSS Worm，講解了Web 2.0的最大威脅——跨站腳本蠕蟲，剖析了Web 2.0相關概念和其核心技術，這些知識對於理解和預防XSS Worm十分重要。第6章 Flash應用安全，就當前的Flash應用安全做出了深入闡述。第7章 深入XSS原理，討論一些比較深入的XSS理論。第8章 防禦XSS攻擊，介紹了一些防範XSS攻擊的方法，例如，運用XSS Filter進行輸入過濾和輸出編碼，使用Firefox瀏覽器的Noscript插件抵禦XSS攻擊，使用HTTP-only的Cookies同樣能起到保護敏感數據的作用。
《XSS跨站腳本攻擊剖析與防禦》適合網站管理人員、信息/網路安全或相關工作從業者、軟體開發工程師，以及任何對Web安全技術感興趣的讀者。
『叄』 如何防範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」。在這些小代碼塊放置不可信數據是相當危險的，因為很容易切換到執行環境，因此請小心使用。
『肆』 跨站腳本攻擊的預防
從網站開發者角度，如何防護XSS攻擊?
來自應用安全國際組織OWASP的建議，對XSS最佳的防護應該結合以下兩種方法：驗證所有輸入數據，有效檢測攻擊；對所有輸出數據進行適當的編碼，以防止任何已成功注入的腳本在瀏覽器端運行。具體如下：
輸入驗證：某個數據被接受為可被顯示或存儲之前，使用標准輸入驗證機制，驗證所有輸入數據的長度、類型、語法以及業務規則。
輸出編碼：數據輸出前，確保用戶提交的數據已被正確進行entity編碼，建議對所有字元進行編碼而不僅局限於某個子集。
明確指定輸出的編碼方式：不要允許攻擊者為你的用戶選擇編碼方式(如ISO 8859-1或 UTF 8)。
注意黑名單驗證方式的局限性：僅僅查找或替換一些字元(如< >或類似script的關鍵字)，很容易被XSS變種攻擊繞過驗證機制。
警惕規范化錯誤：驗證輸入之前，必須進行解碼及規范化以符合應用程序當前的內部表示方法。請確定應用程序對同一輸入不做兩次解碼。
從網站用戶角度，如何防護XSS攻擊?
當你打開一封Email或附件、瀏覽論壇帖子時，可能惡意腳本會自動執行，因此，在做這些操作時一定要特別謹慎。建議在瀏覽器設置中關閉JavaScript。如果使用IE瀏覽器，將安全級別設置到「高」。具體可以參照瀏覽器安全的相關文章。
這里需要再次提醒的是，XSS攻擊其實伴隨著社會工程學的成功應用，需要增強安全意識，只信任值得信任的站點或內容。可以通過一些檢測工具進行xss的漏洞檢測，類似工具有億思網站安全檢測平台。針對xss的漏洞帶來的危害是巨大，如有發現，應立即修復漏洞。
『伍』 跨站腳本攻擊,如何利用工具和測試防範跨站點腳本攻擊
跨站點腳本（XSS）允許攻擊者通過利用網際網路伺服器的漏洞來發送惡意代碼到其他用戶。攻擊者利用跨站點腳本（XSS）攻擊向那些看似可信任的鏈接中注入惡意代碼。當用戶點擊了鏈接後，內嵌的程序將被提交並且會在用戶的電腦上執行，這會使黑客獲取訪問許可權並偷走敏感數據。攻擊者使用XSS來攻擊受害者機器上的漏洞並且傳輸惡意代碼而不是攻擊系統本身。 通過用戶輸入的數據返回錯誤消息的Web表格，攻擊者可以修改控制Web頁面的HTML代碼。黑客能夠在垃圾信息中的鏈接里插入代碼或者使用欺詐郵件來誘使用戶對其身份產生信任。 例如攻擊者可以發送帶有URL的郵件給受害人，這個URL指向一個Web站點並且提供瀏覽器腳本作為輸入；或者在博客或諸如Facebook、Twitter這樣的社交網站上發布惡意URL鏈接。當用戶點擊這個鏈接時，該惡意站點以及腳本將會在其瀏覽器上運行。瀏覽器不知道腳本是惡意的並將盲目地運行這個程序，這轉而允許攻擊者的瀏覽器腳本使用站點的功能來竊取cookie或者冒充合法的用戶來完成交易。 一些通常的跨站點腳本預防的最佳實踐包括在部署前測試應用代碼，並且以快速、簡明的方式修補缺陷和漏洞。Web應用開發人員應該過濾用戶的輸入來移除可能的惡意字元和瀏覽器腳本，並且植入用戶輸入過濾代碼來移除惡意字元。通常管理員也可以配置瀏覽器只接受來自信任站點的腳本或者關閉瀏覽器的腳本功能，盡管這樣做可能導致使用Web站點的功能受限。 隨著時代的進步黑客們變得更加先進，使用收集的工具集來加快漏洞攻擊進程。這意味著僅僅部署這些通常的XSS預防實踐是不夠的，保護和預防過程必須從底層開始並持續提升。預防過程必須在開發階段開始，建立在一個牢靠、安全的開發生命周期方法論之上的Web應用在發布版本中不太可能暴露出漏洞。這樣以來，不僅提升了安全性，也改善了可用性而且縮減了維護的總體費用，因為在現場環境中修補問題比在開發階段會花費更多。 威脅建模在XSS預防中也是重要的一個方面，應該納入到每個組織的安全開發生命周期當中。威脅建模評估和辨識在開發階段中應用程序面臨的所有的風險，來幫助Web開發人員更好地理解需要什麼樣的保護以及攻擊一旦得逞將對組織產生怎樣的影響。要辨識一個特定應用的威脅級別，考慮它的資產以及它訪問的敏感信息量是十分重要的。這個威脅建模過程將確保在應用的設計和開發過程中戰略性地融合了安全因素源碼天空 ，並且增強了Web開發人員的安全意識。 對於大型項目的Web開發人員來說，源代碼掃描工具和Web應用漏洞掃描器是提高效率和減少工作量的通常選擇。
『陸』 跨站腳本攻擊xss的原理是什麼有什麼危害如何防範
xxs攻擊原理是網頁對用戶輸入的字元串過濾不嚴，導致在提交輸入信息的時候瀏覽器執行了黑客嵌入的xxs腳本，致使用戶信息泄露。黑客可將偽裝過的含義腳本語句的鏈接發送給受害者，當受害者點擊鏈接的時候，由於網頁沒有過濾腳本語句，所以瀏覽器執行了腳本語句，而這個腳本語句的作用是將用戶的cookie發送到黑客指定的地址，然後黑客就可以利用受害者的cookie竊取受害者的個人信息等等。這種攻擊對伺服器沒有多大危害，但對用戶危害很大，要防範這種攻擊應該在設計網站的時候對用戶提交的內容進行嚴格的過濾。
『柒』 XSS跨站腳本攻擊的防禦方法有哪些怎樣把他們分類
用護衛神高級安全防護可以解決
『捌』 等大神來，對於跨站腳本攻擊都有什麼防範的方法
跨站點腳本（XSS）允許攻擊者通過利用網際網路伺服器的漏洞來發送惡意代碼到其他用戶。攻擊者利用跨站點腳本（XSS）攻擊向那些看似可信任的鏈接中注入惡意代碼。當用戶點擊了鏈接後，內嵌的程序將被提交並且會在用戶的電腦上執行，這會使黑客獲取。
『玖』 跨站腳本攻擊有哪些類型
1、持久型跨站：最直接的危害類型，跨站代碼存儲在伺服器（資料庫）。
2、非持久型跨站：反射型跨站腳本漏洞，最普遍的類型。用戶訪問伺服器-跨站鏈接-返回跨站代碼。
3、DOM跨站（DOM XSS）:DOM(document object model文檔對象模型)，客戶端腳本處理邏輯導致的安全問題。
(9)跨站腳本攻擊方法和防範擴展閱讀：
跨站腳本攻擊產生的原因是網站過於相信用戶的輸入，那麼解決的辦法也很直接，就是從根本上不相信用戶的任何輸入。一個安全的網站應當對任何用戶的任何輸入都要進行檢查，特別是對用戶提交到伺服器中保存的數據，更要做篩選。
這種攻擊與反射型攻擊不同的是，它會把自己的攻擊代碼保存在網站的伺服器上，這樣，任何訪問了這個頁面的用戶，都會受到這個攻擊。