微軟：“白屏死機”不算漏洞

日，CyberArk安全研究員Eviatar Gerzi發(fā)現(xiàn)Windows終端和基于Chrome的網(wǎng)頁瀏覽器上存在多個高危DoS（拒絕服務）漏洞。

Gerzi在2003年的一個通過修改窗口標題執(zhí)行代碼的舊安全公告（https://marc.info/?l=bugtraq&m=104612710031920&q=p3）嘗試了各種潛在的濫用途徑，并發(fā)現(xiàn)了一種在PuTTY上誘導快速窗口標題更改的方法。

這種非典型的攻擊方式導致測試設備進入一種被稱為“白屏死機”的狀態(tài)，除了鼠標光標外，屏幕上所有的應用程序界面都凍結(jié)了（失去響應）。

研究人員對存在類似漏洞的本地應用程序的實施攻擊后，導致程序調(diào)用過多的操作系統(tǒng)內(nèi)核，系統(tǒng)立即進入白屏死機狀態(tài)。

被濫用的函數(shù)是“SetWindowText”，可用于更改指定窗口標題欄的文本。

需要注意的是，這個簡單的攻擊技巧可以導致大量“無辜”應用程序也一并被拖入白屏死機狀態(tài)，而擺脫白屏死機狀態(tài)的唯一方法是重新啟動計算機。

研究人員還發(fā)現(xiàn)，“SetWindowText”并不是唯一導致白屏死機的手段，在其中一個案例中，研究人員測試了MobaXterm終端，令我驚訝的是它沒有使用SetWindowText函數(shù)來更改窗口標題，而是使用了一個名為GdipDrawString的函數(shù)。

在這種情況下，有趣的是GdipDrawString并沒有像SetWindowText那樣導致整個計算機失去響應。它只影響了最終崩潰的應用程序。

Gerzi確認以下Windows終端受到白屏死機漏洞的影響：

PuTTY–CVE-2021-33500（凍結(jié)整個計算機），已在0.75版中修復
MobaXterm–CVE-2021-28847（僅凍結(jié)應用程序），已在21.0預覽版3中修復
MinTTY（和Cygwin）–CVE-2021-28848（凍結(jié)整個計算機），已在3.4.6版中修復
Git–使用MinTTY，已在2.30.1版中修復
ZOC–CVE-2021-32198（僅凍結(jié)應用程序），無修復
XSHELL–CVE-2021-42095（凍結(jié)整個計算機），在版本7.0.0.76中修復

主流瀏覽器未能幸免

意識到幾乎所有的GUI圖形界面應用程序都使用SetWindowText函數(shù)，研究人員嘗試了針對Chrome等流行的網(wǎng)絡瀏覽器的攻擊。

研究人員創(chuàng)建了一個HTML文件，該文件會導致標題在無限循環(huán)中快速變化，從而迫使瀏覽器凍結(jié)。

結(jié)果Edge、Torch、Maxthon、Opera和Vivaldi等所有基于Chromium的主流瀏覽器，全部中招，失去響應，而Firefox和Internet Explorer雖然沒有癱瘓，但性能也受到了影響。

由于現(xiàn)代瀏覽器都是基于沙盒技術(shù)，因此濫用SetWindowText函數(shù)并不會影響到底層操作系統(tǒng)，讓整個系統(tǒng)白屏死機。但是，當研究者嘗試在虛擬機內(nèi)進行瀏覽器攻擊時，會出現(xiàn)資源耗盡問題，導致虛擬化系統(tǒng)顯示“藍屏死機”。

廠商回應：不是漏洞

研究人員指出，除了實驗已經(jīng)驗證的Windows終端模擬器和主流瀏覽器以外，任何使用SetWindowText或GdipDrawString函數(shù)的應用程序都可能受此攻擊影響。

有些應用例外，例如Slack。像Slack這樣的應用程序在函數(shù)調(diào)用上具有速率限制器，因此它們能夠抵御這種DoS攻擊。

Gerzi聯(lián)系了受影響的供應商并收到以下回復：

Google：DoS問題被視為濫用或穩(wěn)定性問題，而不是安全漏洞。注意：該問題在Mac上未觀察到，但在Linux上觀察到。我們再次審查了這個問題。我們無法在最新版本的WS16.1.2build-17966106和Chrome92.0.4515.131中重現(xiàn)崩潰。我們認為您觀察到的行為可能取決于所使用的chrome版本，因為我們沒有看到任何藍屏死機問題。因此，我們認為這不是漏洞。
Vivaldi：這是Windows10的設計局限；它不限制應用程序內(nèi)存的使用，并且在RAM用完時僅使用頁面文件（虛擬內(nèi)存）。這導致響應較慢，因為此時必須從磁盤讀取。
微軟：我們的團隊能夠重現(xiàn)此問題，但它不符合我們通過立即安全更新提供服務的標準。雖然這構(gòu)成了導致拒絕服務攻擊的條件，但這只能在本地觸發(fā)并且是資源耗盡的結(jié)果。攻擊者將無法觸發(fā)任何其他易受攻擊的條件或檢索對系統(tǒng)的其他攻擊有益的信息。我們將關(guān)閉此案例，但我們已向我們的開發(fā)團隊報告了該錯誤，他們可能會考慮在未來的Windows版本中解決此問題。

雖然谷歌和微軟都否認白屏死機是漏洞，但是安全研究人員指出，可以通過在遠程服務器上創(chuàng)建惡意文件并從在存在漏洞的終端中打開來遠程觸發(fā)攻擊。

、首先說說瀏覽器的加載流程：

(1) 用戶在地址欄中打開一個URL，瀏覽器首先會尋找該URL所在服務器，通過DNS服務器查詢?yōu)g覽器會獲

得該URL所在網(wǎng)站的IP地址，然后向該地址發(fā)起請求，連接到服務器；

(2) 建立連接后，向服務器發(fā)送http請求，請求對應的HTML文檔；

(3) 解析HTML文檔，目的是知道該頁面需要哪些資源以及生成DOM樹；生成DOM樹和獲取到相應需要的

資源文件同時進行；解析HTML文檔時，一旦發(fā)現(xiàn)一個標簽，就會根據(jù)標簽的要求分配對指定的資源進行下載，當DOM樹生成后，DOMContentLoaded事件被觸發(fā)；

理論上瀏覽器并行下載頁面所需要的資源會帶來更好的性能體驗！

(4) Onload事件，當解析完成后，生成了DOM樹，所有頁面需要的資源文件都已經(jīng)成功下載和執(zhí)行后，

瀏覽器會發(fā)出Onload事件并回調(diào)HTML文檔中的onload函數(shù)。

2、對于優(yōu)化頁面速度的必要性：

頁面的打開速度對于網(wǎng)站的優(yōu)化有極大的意義，如果打開一個頁面長時間處于白屏狀態(tài)，如果超過5s，暴脾氣

的我是會直接關(guān)閉這個網(wǎng)頁；或者是頁面加載出來了，但是比較慢，頁面顯示不完整，標簽一直在轉(zhuǎn)圈，頁面處于不可交互狀態(tài)，這也是一種很不好的體驗；

一個頁面的打開速度快不快，可以用兩個指標來描述，一個是ready時間，一個是load時間，chrome控制臺可以看到；

一共是加載了19.2KB，ready時間是133ms，load時間是147ms；

3、分點介紹優(yōu)化策略：

(1) 避免head標簽js堵塞：

所有放在head標簽里面的js和css都會堵塞渲染；如果這些css和js需要加載很久的話，那么頁面就空白了；

[html] view plain copy

<head>

</head>

用google的cdn加載一個jQuery文件是訪問不了的，所以標簽一直在轉(zhuǎn)圈，頁面沒有任何顯示；

有兩種解決辦法，第一種是把script放到body后面，這也是很多網(wǎng)站采取的方法。第二種是給script加defer或者async的屬性，一旦script是defer或者async延遲的，那么這個script將會異步加載，但不會馬上執(zhí)行，會在readystatechange變?yōu)镮nteractive后按順序依次執(zhí)行；

兩者相同點：

加載文件時不阻塞頁面渲染

對于inline的script無效

使用這兩個屬性的腳本中不能調(diào)用document.write方法

有腳本的onload的事件回調(diào)

兩者不同點：

async下，js一旦下載好了就會執(zhí)行，所以很有可能不是按照原本的順序來執(zhí)行的。如果js前后有依賴性，用async，就很有可能出錯。

如果一個script加了defer屬性，即使放在head里面，它也會在html頁面解析完畢之后再去執(zhí)行，也就是類似于把這個script放在了頁面底部。

(2) 減少head里面的css資源：

css必須放在head標簽里面，如果放在body里面會造成對layout好的dom進行重排造成頁面閃爍；但是一旦

放在head標簽里面又會堵塞頁面渲染；所以要盡可能的減小css體積；

例：不要放太多base64在css里面，webpack構(gòu)建工具常常會配置圖片體積小于多少的直接轉(zhuǎn)換成base64加載，這

里是挺影響性能的，一個是不能用到緩存機制，另一個就是加大了css的體積；個人建議上線項目直接把圖片用cdn托

管；

在這里給大家推薦一個前端交流學習qun，想要學習的朋友可以加入進來，免費帶你入門。前面是554，中間是224，后面是926.

(3)延遲加載圖片：

對于很多網(wǎng)站來說，圖片汪汪是占用最多流量和帶寬的資源；

[html] view plain copy

</body>

window.onload=function(){

$("#imgTest").attr("src",$("#imgTest").data("src"));

}

</script></span>

這里沒有直接給src路徑，而是在頁面加載完成后用js操作src，減少了頁面加載圖片的時間，首先把整個頁面結(jié)構(gòu)呈現(xiàn)給用戶；惰性加載圖片也是差不多；當用戶滑動頁面到一定高度時（監(jiān)聽scroll事件），再動態(tài)的依次對圖片進行處理；

(4) 壓縮和緩存：

壓縮就不說了；緩存會在后續(xù)文章中具體寫一個demo，持續(xù)更新；

(5) DNS解析優(yōu)化：

DNS查詢需要花費大量時間來返回一個主機名的IP地址；

在我們的網(wǎng)站中，可能會加載到很多個域的東西，比如引入了百度地圖啊之類的sdk和一些自己的子域名服務；第一次打開網(wǎng)站時要做很多次DNS查找；DNS預讀取能夠加快網(wǎng)頁打開時間；

[html] view plain copy

在head中寫上幾個link標簽，對標簽中的地址提前解析DNS，這個解析是并行發(fā)生的，不會堵塞頁面渲染；

還有非常多的頁面優(yōu)化技巧，html別嵌套太多層，加重頁面layout的壓力；css選擇器的合理運用，減少匹配的計算量；js中別濫用閉包，會加深作用域鏈，增加變量查找時間；減少http請求之類的等等；

我是一名前端開發(fā)程序員，自己整理了一份2019最全面前端學習資料，從最基礎(chǔ)的HTML+CSS+JS到移動端HTML5到各種框架都有整理，送給每一位前端小伙伴，這里是小白聚集地，歡迎初學和進階中的小伙伴
前端資料獲取方式：
1.在你手機的右上角有【關(guān)注】選項，點擊關(guān)注！
2.關(guān)注后，手機客戶端點擊我的主頁面，右上角有私信，請私信回復：【學習】
電腦已經(jīng)設置好了關(guān)鍵詞自動回復，所以回復的時候請注意關(guān)鍵詞喲~

場詩

曲木為直終必彎，養(yǎng)狼當犬看家難；
墨染鸕鶿黑不久，粉刷烏鴉白不天。
蜜餞黃蓮終需苦，強摘瓜果不能甜；
好事總得善人做，哪有凡人做神仙。

前言

該篇文章會為您分享在前端性能優(yōu)化中非常重要的一環(huán)-白屏時間，將從白屏時間的概念、重要性以及白屏的過程一一進行闡述，同時提供性能優(yōu)化的策略與實踐。

一、概念

白屏時間：即用戶點擊一個鏈接或打開瀏覽器輸入URL地址后，從屏幕空白到顯示第一個畫面的時間。

白屏時間的長短將直接影響用戶對該網(wǎng)站的第一印象。

二、白屏時間的重要性

當用戶點開一個鏈接或者是直接在瀏覽器中輸入URL開始進行訪問時，就開始等待頁面的展示。頁面渲染的時間越短，用戶等待的時間就越短，用戶感知到頁面的速度就越快。這樣可以極大的提升用戶的體驗，減少用戶的跳出，提升頁面的留存率。

打開一個頁面就像你的女票召喚你一樣，你出現(xiàn)的越迅速，女票肯定會愈加欣喜！反之，你千呼萬喚始出來，那么你的女票很可能又要拋棄你了(為什么要對你說又呢? ...)

三、白屏是一個怎樣的過程呢？

讓我們一起來揭秘：從打開一個頁面，到頁面的畫面展示經(jīng)歷了怎樣的過程！

1. DNS Lookup

DNS Lookup 即瀏覽器從DNS服務器中進行域名查詢。

瀏覽器會先對頁面進行域名解析，獲取到服務器的IP地址后，進而和服務器進行通信。

Tips: 通常在整個加載頁面的過程中，瀏覽器會多次進行DNS Lookup，包括頁面本身的域名查詢以及在解析HTML頁面時加載的JS、CSS、Image、Video等資源產(chǎn)生的域名查詢。

2. 建立TCP請求連接

瀏覽器和服務端TCP請求建立的過程，是基于TCP/IP，該協(xié)議由網(wǎng)絡層的IP和傳輸層的TCP組成。IP是每一臺互聯(lián)網(wǎng)設備在互聯(lián)網(wǎng)中的唯一地址。

TCP通過三次握手建立連接，并提供可靠的數(shù)據(jù)傳輸服務。

3. 服務端請求處理響應

在TCP連接建立后，Web服務器接受請求，開始進行處理，同時瀏覽器端開始等待服務器的處理響應。

Web服務器根據(jù)請求類型的不同，進行相應的處理。靜態(tài)資源如圖片、CSS文件、靜態(tài)HTML直接進行響應；如其他注冊的請求轉(zhuǎn)發(fā)給相應的應用服務器，進行如數(shù)據(jù)處理、緩存中取數(shù)據(jù)，將數(shù)據(jù)按照約定好的格式響應給瀏覽器。

在大型應用中，通常為分布式服務架構(gòu)，應用服務器的處理有可能經(jīng)過很多個系統(tǒng)的中間件，最終獲取到需要的數(shù)據(jù)

4. 客戶端下載、解析、渲染顯示頁面

在服務器返回數(shù)據(jù)后，客戶端瀏覽器接收數(shù)據(jù)，進行HTML下載、解析、渲染顯示。

a. 如果是Gzip包，則先解壓為HTML
b. 解析HTML的頭部代碼，下載頭部代碼中的樣式資源文件或腳本資源文件
c. 解析HTML代碼和樣式文件代碼，構(gòu)建HTML的DOM樹以及與CSS相關(guān)的CSSOM樹
d. 通過遍歷DOM樹和CSSOM樹，瀏覽器依次計算每個節(jié)點的大小、坐標、顏色等樣式，構(gòu)造渲染樹
e. 根據(jù)渲染樹完成繪制過程

瀏覽器下載HTML后，首先解析頭部代碼，進行樣式表下載，然后繼續(xù)向下解析HTML代碼，構(gòu)建DOM樹，同時進行樣式下載。當DOM樹構(gòu)建完成后，立即開始構(gòu)造CSSOM樹。理想情況下，樣式表下載速度夠快，DOM樹和CSSOM樹進入一個并行的過程，當兩棵樹構(gòu)建完畢，構(gòu)建渲染樹，然后進行繪制。

Tips:瀏覽器安全解析策略對解析HTML造成的影響：

當解析HTML時遇到內(nèi)聯(lián)JS代碼，會阻塞DOM樹的構(gòu)建
特別悲慘的情況： 當CSS樣式文件沒有下載完成時，瀏覽器解析HTML遇到了內(nèi)聯(lián)JS代碼，此時！！！根據(jù)瀏覽器的安全解析策略，瀏覽器暫停JS腳本執(zhí)行，暫停HTML解析。直到CSS文件下載完成，完成CSSOM樹構(gòu)建，重新恢復原來的解析。

一定要合理放置JS代碼！！！

四、白屏-性能優(yōu)化

至此，我們已經(jīng)了解了從瀏覽器在打開一個鏈接開始，到屏幕展示的過程-白屏時間的歷程，那這對每個環(huán)節(jié)中發(fā)生的事情，我們可以有針對性的進行相關(guān)的優(yōu)化。

1. DNS解析優(yōu)化

針對DNS Lookup環(huán)節(jié)，我們可以針對性的進行DNS解析優(yōu)化。

DNS緩存優(yōu)化
DNS預加載策略
穩(wěn)定可靠的DNS服務器

2. TCP網(wǎng)絡鏈路優(yōu)化

針對網(wǎng)絡鏈路的優(yōu)化，好像除了花錢沒有什么更好的方式！

3. 服務端處理優(yōu)化

服務端的處理優(yōu)化，是一個非常龐大的話題，會涉及到如Redis緩存、數(shù)據(jù)庫存儲優(yōu)化或是系統(tǒng)內(nèi)的各種中間件以及Gzip壓縮等...

4. 瀏覽器下載、解析、渲染頁面優(yōu)化

根據(jù)瀏覽器對頁面的下載、解析、渲染過程，可以考慮一下的優(yōu)化處理：

盡可能的精簡HTML的代碼和結(jié)構(gòu)
盡可能的優(yōu)化CSS文件和結(jié)構(gòu)
一定要合理的放置JS代碼，盡量不要使用內(nèi)聯(lián)的JS代碼

聲明

本文為胡哥拜讀周濤明、張榮華、張新兵幾位大佬所著《大型網(wǎng)站性能優(yōu)化實戰(zhàn)》一書并結(jié)合自身經(jīng)驗所得，愿對諸位小伙伴有所幫助。手動微笑.gif

后記

以上就是胡哥今天給大家分享的內(nèi)容，喜歡的小伙伴記得收藏、轉(zhuǎn)發(fā)、點擊右下角按鈕在看，推薦給更多小伙伴呦，歡迎多多留言交流...

胡哥有話說，一個有技術(shù)，有情懷的胡哥！京東開放平臺首席前端攻城獅。與你一起聊聊大前端，分享前端系統(tǒng)架構(gòu)，框架實現(xiàn)原理，最新最高效的技術(shù)實踐！

長按掃碼關(guān)注，更帥更漂亮呦！關(guān)注胡哥有話說公眾號，可與胡哥繼續(xù)深入交流呦！

在線咨詢

上一篇：有哪些不用寫代碼就能輕松制作HTML5網(wǎng)頁的工具？
下一篇：Word、Excel表格互換絕不是復制粘貼那么簡單

您的項目需求

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

整合營銷服務商

微軟：“白屏死機”不算漏洞

您的項目需求