Phone在今日迎來了iOS12正式版的更新，不過這次更新依舊沒有解決在近日出現(xiàn)的一個(gè)BUG；該BUG會(huì)導(dǎo)致蘋果瀏覽器Safari在加載部分網(wǎng)頁時(shí)，出現(xiàn)系統(tǒng)崩潰甚至重啟的現(xiàn)象。

據(jù)悉，這個(gè)系統(tǒng)漏洞是由安全研究人員在開源瀏覽器內(nèi)核WebKit，研究人員表示，利用WebKit的漏洞，攻擊者可以讓蘋果公司的設(shè)備加載植入特定CSS代碼的HTML頁面。

而Backdrop-filter是一種比較新的CSS屬性，它可以讓元素背景變得模糊，或者改變顏色。這樣的處理任務(wù)十分繁重，一些軟件工程師和WEB開發(fā)人員猜測，可能是因?yàn)樘匦т秩緦?duì)iOS圖形處理庫造成影響，結(jié)果導(dǎo)致移動(dòng)OS崩潰。

研究人員還發(fā)現(xiàn)，不僅iOS受到了這個(gè)漏洞的影響，蘋果公司的macOS也是受到了這個(gè)漏洞的影響。

而新款的iOS系統(tǒng)，在升級(jí)之前并沒有考慮到這個(gè)問題，那么蘋果公司很有可能會(huì)在近日推送一次iOS12的小版本系統(tǒng)升級(jí)；并且按照蘋果公司的一貫做法來看，這次升級(jí)的時(shí)間應(yīng)該很快。

目前iOS12正式版已經(jīng)向所有符合更新規(guī)則的設(shè)備推送，不少的用戶表示，在升級(jí)之后，流暢度有所提升，但是電池的健康程度和耐用程度似乎都出現(xiàn)了不同程度的下降，魚和熊掌自然是不可兼得的。

蘋果公司在經(jīng)歷“降頻門”之后，對(duì)于老款iPhone的性能不再限制，不過這也導(dǎo)致了老款的iPhone續(xù)航都會(huì)出現(xiàn)大幅度的下滑；畢竟性能和續(xù)航，本身就是兩個(gè)對(duì)立面。

.http和https

https的SSL加密是在傳輸層實(shí)現(xiàn)的。

(1)http和https的基本概念

http: 超文本傳輸協(xié)議，是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，是一個(gè)客戶端和服務(wù)器端請(qǐng)求和應(yīng)答的標(biāo)準(zhǔn)（TCP），用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議，它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。

https: 是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。

https協(xié)議的主要作用是：建立一個(gè)信息安全通道，來確保數(shù)組的傳輸，確保網(wǎng)站的真實(shí)性。

(2)http和https的區(qū)別？

http傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，網(wǎng)景公司設(shè)置了SSL協(xié)議來對(duì)http協(xié)議傳輸?shù)臄?shù)據(jù)進(jìn)行加密處理，簡單來說https協(xié)議是由http和ssl協(xié)議構(gòu)建的可進(jìn)行加密傳輸和身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議的安全性更高。

主要的區(qū)別如下：

• Https協(xié)議需要ca證書，費(fèi)用較高。
• http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。
• 使用不同的鏈接方式，端口也不同，一般而言，http協(xié)議的端口為80，https的端口為443
• http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

(3)https協(xié)議的工作原理

客戶端在使用HTTPS方式與Web服務(wù)器通信時(shí)有以下幾個(gè)步驟，如圖所示。

• 客戶使用https url訪問服務(wù)器，則要求web 服務(wù)器建立ssl鏈接。
• web服務(wù)器接收到客戶端的請(qǐng)求之后，會(huì)將網(wǎng)站的證書（證書中包含了公鑰），返回或者說傳輸給客戶端。
• 客戶端和web服務(wù)器端開始協(xié)商SSL鏈接的安全等級(jí)，也就是加密等級(jí)。
• 客戶端瀏覽器通過雙方協(xié)商一致的安全等級(jí)，建立會(huì)話密鑰，然后通過網(wǎng)站的公鑰來加密會(huì)話密鑰，并傳送給網(wǎng)站。
• web服務(wù)器通過自己的私鑰解密出會(huì)話密鑰。
• web服務(wù)器通過會(huì)話密鑰加密與客戶端之間的通信。

(4)https協(xié)議的優(yōu)點(diǎn)

• 使用HTTPS協(xié)議可認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器；
• HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。
• HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對(duì)安全，但它大幅增加了中間人攻擊的成本。
• 谷歌曾在2014年8月份調(diào)整搜索引擎算法，并稱“比起同等HTTP網(wǎng)站，采用HTTPS加密的網(wǎng)站在搜索結(jié)果中的排名將會(huì)更高”。

(5)https協(xié)議的缺點(diǎn)

• https握手階段比較費(fèi)時(shí)，會(huì)使頁面加載時(shí)間延長50%，增加10%~20%的耗電。
• https緩存不如http高效，會(huì)增加數(shù)據(jù)開銷。
• SSL證書也需要錢，功能越強(qiáng)大的證書費(fèi)用越高。
• SSL證書需要綁定IP，不能再同一個(gè)ip上綁定多個(gè)域名，ipv4資源支持不了這種消耗。

2.tcp三次握手，一句話概括

客戶端和服務(wù)端都需要直到各自可收發(fā)，因此需要三次握手。

簡化三次握手：

從圖片可以得到三次握手可以簡化為：C發(fā)起請(qǐng)求連接S確認(rèn)，也發(fā)起連接C確認(rèn)我們?cè)倏纯疵看挝帐值淖饔茫旱谝淮挝帐郑篠只可以確認(rèn) 自己可以接受C發(fā)送的報(bào)文段第二次握手：C可以確認(rèn) S收到了自己發(fā)送的報(bào)文段，并且可以確認(rèn) 自己可以接受S發(fā)送的報(bào)文段第三次握手：S可以確認(rèn) C收到了自己發(fā)送的報(bào)文段

3.TCP和UDP的區(qū)別

（1）TCP是面向連接的，udp是無連接的即發(fā)送數(shù)據(jù)前不需要先建立鏈接。

（2）TCP提供可靠的服務(wù)。也就是說，通過TCP連接傳送的數(shù)據(jù)，無差錯(cuò)，不丟失，不重復(fù)，且按序到達(dá);UDP盡最大努力交付，即不保證可靠交付。 并且因?yàn)閠cp可靠，面向連接，不會(huì)丟失數(shù)據(jù)因此適合大數(shù)據(jù)量的交換。

（3）TCP是面向字節(jié)流，UDP面向報(bào)文，并且網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使得發(fā)送速率降低（因此會(huì)出現(xiàn)丟包，對(duì)實(shí)時(shí)的應(yīng)用比如IP電話和視頻會(huì)議等）。

（4）TCP只能是1對(duì)1的，UDP支持1對(duì)1,1對(duì)多。

（5）TCP的首部較大為20字節(jié)，而UDP只有8字節(jié)。

（6）TCP是面向連接的可靠性傳輸，而UDP是不可靠的。

4.WebSocket的實(shí)現(xiàn)和應(yīng)用

(1)什么是WebSocket?

WebSocket是HTML5中的協(xié)議，支持持久連續(xù)，http協(xié)議不支持持久性連接。Http1.0和HTTP1.1都不支持持久性的鏈接，HTTP1.1中的keep-alive，將多個(gè)http請(qǐng)求合并為1個(gè)

(2)WebSocket是什么樣的協(xié)議，具體有什么優(yōu)點(diǎn)？

• HTTP的生命周期通過Request來界定，也就是Request一個(gè)Response，那么在Http1.0協(xié)議中，這次Http請(qǐng)求就結(jié)束了。在Http1.1中進(jìn)行了改進(jìn)，是的有一個(gè)connection：Keep-alive，也就是說，在一個(gè)Http連接中，可以發(fā)送多個(gè)Request，接收多個(gè)Response。但是必須記住，在Http中一個(gè)Request只能對(duì)應(yīng)有一個(gè)Response，而且這個(gè)Response是被動(dòng)的，不能主動(dòng)發(fā)起。
• WebSocket是基于Http協(xié)議的，或者說借用了Http協(xié)議來完成一部分握手，在握手階段與Http是相同的。我們來看一個(gè)websocket握手協(xié)議的實(shí)現(xiàn)，基本是2個(gè)屬性，upgrade，connection。

基本請(qǐng)求如下：

GET /chat HTTP/1.1

Host: server.example.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==

Sec-WebSocket-Protocol: chat, superchat

Sec-WebSocket-Version: 13

Origin: http://example.com

多了下面2個(gè)屬性：

Upgrade:webSocket

Connection:Upgrade

告訴服務(wù)器發(fā)送的是websocket

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==

Sec-WebSocket-Protocol: chat, superchat

Sec-WebSocket-Version: 13

5.HTTP請(qǐng)求的方式，HEAD方式

• head：類似于get請(qǐng)求，只不過返回的響應(yīng)中沒有具體的內(nèi)容，用戶獲取報(bào)頭
• options：允許客戶端查看服務(wù)器的性能，比如說服務(wù)器支持的請(qǐng)求方式等等。

6.一個(gè)圖片url訪問后直接下載怎樣實(shí)現(xiàn)？

請(qǐng)求的返回頭里面，用于瀏覽器解析的重要參數(shù)就是OSS的API文檔里面的返回http頭，決定用戶下載行為的參數(shù)。

下載的情況下：

1. x-oss-object-type:

Normal

2. x-oss-request-id:

598D5ED34F29D01FE2925F41

3. x-oss-storage-class:

Standard

7.web Quality （無障礙）

能夠被殘障人士使用的網(wǎng)站才能稱得上一個(gè)易用的（易訪問的）網(wǎng)站。

殘障人士指的是那些帶有殘疾或者身體不健康的用戶。

使用alt屬性：

<img src="person.jpg" alt="this is a person"/>

有時(shí)候?yàn)g覽器會(huì)無法顯示圖像。具體的原因有：

• 用戶關(guān)閉了圖像顯示
• 瀏覽器是不支持圖形顯示的迷你瀏覽器
• 瀏覽器是語音瀏覽器（供盲人和弱視人群使用）
• 如果您使用了 alt 屬性，那么瀏覽器至少可以顯示或讀出有關(guān)圖像的描述。

8.幾個(gè)很實(shí)用的BOM屬性對(duì)象方法?

什么是Bom? Bom是瀏覽器對(duì)象。有哪些常用的Bom屬性呢？

(1)location對(duì)象

location.href-- 返回或設(shè)置當(dāng)前文檔的URL

location.search -- 返回URL中的查詢字符串部分。例如 http://www.dreamdu.com/dreamdu.php?id=5&name=dreamdu 返回包括(?)后面的內(nèi)容?id=5&name=dreamdu

location.hash -- 返回URL#后面的內(nèi)容，如果沒有#，返回空

location.host -- 返回URL中的域名部分，例如www.dreamdu.com

location.hostname -- 返回URL中的主域名部分，例如dreamdu.com

location.pathname -- 返回URL的域名后的部分。例如 http://www.dreamdu.com/xhtml/ 返回/xhtml/

location.port -- 返回URL中的端口部分。例如 http://www.dreamdu.com:8080/xhtml/ 返回8080

location.protocol -- 返回URL中的協(xié)議部分。例如 http://www.dreamdu.com:8080/xhtml/ 返回(//)前面的內(nèi)容http:

location.assign -- 設(shè)置當(dāng)前文檔的URL

location.replace() -- 設(shè)置當(dāng)前文檔的URL，并且在history對(duì)象的地址列表中移除這個(gè)URL location.replace(url);

location.reload() -- 重載當(dāng)前頁面

(2)history對(duì)象

history.go() -- 前進(jìn)或后退指定的頁面數(shù) history.go(num);

history.back() -- 后退一頁

history.forward() -- 前進(jìn)一頁

(3)Navigator對(duì)象

navigator.userAgent -- 返回用戶代理頭的字符串表示(就是包括瀏覽器版本信息等的字符串)

navigator.cookieEnabled -- 返回瀏覽器是否支持(啟用)cookie

9.HTML5 drag api

• dragstart：事件主體是被拖放元素，在開始拖放被拖放元素時(shí)觸發(fā)，。
• darg：事件主體是被拖放元素，在正在拖放被拖放元素時(shí)觸發(fā)。
• dragenter：事件主體是目標(biāo)元素，在被拖放元素進(jìn)入某元素時(shí)觸發(fā)。
• dragover：事件主體是目標(biāo)元素，在被拖放在某元素內(nèi)移動(dòng)時(shí)觸發(fā)。
• dragleave：事件主體是目標(biāo)元素，在被拖放元素移出目標(biāo)元素是觸發(fā)。
• drop：事件主體是目標(biāo)元素，在目標(biāo)元素完全接受被拖放元素時(shí)觸發(fā)。
• dragend：事件主體是被拖放元素，在整個(gè)拖放操作結(jié)束時(shí)觸發(fā)

10.http2.0

首先補(bǔ)充一下，http和https的區(qū)別，相比于http,https是基于ssl加密的http協(xié)議

簡要概括：http2.0是基于1999年發(fā)布的http1.0之后的首次更新。

• 提升訪問速度（可以對(duì)于，請(qǐng)求資源所需時(shí)間更少，訪問速度更快，相比http1.0）
• 允許多路復(fù)用：多路復(fù)用允許同時(shí)通過單一的HTTP/2連接發(fā)送多重請(qǐng)求-響應(yīng)信息。改善了：在http1.1中，瀏覽器客戶端在同一時(shí)間，針對(duì)同一域名下的請(qǐng)求有一定數(shù)量限制（連接數(shù)量），超過限制會(huì)被阻塞。
• 二進(jìn)制分幀：HTTP2.0會(huì)將所有的傳輸信息分割為更小的信息或者幀，并對(duì)他們進(jìn)行二進(jìn)制編碼
• 首部壓縮
• 服務(wù)器端推送

11.補(bǔ)充400和401、403狀態(tài)碼

(1)400狀態(tài)碼：請(qǐng)求無效

產(chǎn)生原因：

• 前端提交數(shù)據(jù)的字段名稱和字段類型與后臺(tái)的實(shí)體沒有保持一致
• 前端提交到后臺(tái)的數(shù)據(jù)應(yīng)該是json字符串類型，但是前端沒有將對(duì)象JSON.stringify轉(zhuǎn)化成字符串。

解決方法：

• 對(duì)照字段的名稱，保持一致性
• 將obj對(duì)象通過JSON.stringify實(shí)現(xiàn)序列化

(2)401狀態(tài)碼：當(dāng)前請(qǐng)求需要用戶驗(yàn)證

(3)403狀態(tài)碼：服務(wù)器已經(jīng)得到請(qǐng)求，但是拒絕執(zhí)行

12.fetch發(fā)送2次請(qǐng)求的原因

fetch發(fā)送post請(qǐng)求的時(shí)候，總是發(fā)送2次，第一次狀態(tài)碼是204，第二次才成功？

原因很簡單，因?yàn)槟阌胒etch的post請(qǐng)求的時(shí)候，導(dǎo)致fetch 第一次發(fā)送了一個(gè)Options請(qǐng)求，詢問服務(wù)器是否支持修改的請(qǐng)求頭，如果服務(wù)器支持，則在第二次中發(fā)送真正的請(qǐng)求。

13.Cookie、sessionStorage、localStorage的區(qū)別

共同點(diǎn)：都是保存在瀏覽器端，并且是同源的

• Cookie：cookie數(shù)據(jù)始終在同源的http請(qǐng)求中攜帶（即使不需要），即cookie在瀏覽器和服務(wù)器間來回傳遞。而sessionStorage和localStorage不會(huì)自動(dòng)把數(shù)據(jù)發(fā)給服務(wù)器，僅在本地保存。cookie數(shù)據(jù)還有路徑（path）的概念，可以限制cookie只屬于某個(gè)路徑下,存儲(chǔ)的大小很小只有4K左右。 （key：可以在瀏覽器和服務(wù)器端來回傳遞，存儲(chǔ)容量小，只有大約4K左右）
• sessionStorage：僅在當(dāng)前瀏覽器窗口關(guān)閉前有效，自然也就不可能持久保持，localStorage：始終有效，窗口或?yàn)g覽器關(guān)閉也一直保存，因此用作持久數(shù)據(jù)；cookie只在設(shè)置的cookie過期時(shí)間之前一直有效，即使窗口或?yàn)g覽器關(guān)閉。（key：本身就是一個(gè)回話過程，關(guān)閉瀏覽器后消失，session為一個(gè)回話，當(dāng)頁面不同即使是同一頁面打開兩次，也被視為同一次回話）
• localStorage：localStorage 在所有同源窗口中都是共享的；cookie也是在所有同源窗口中都是共享的。（key：同源窗口都會(huì)共享，并且不會(huì)失效，不管窗口或者瀏覽器關(guān)閉與否都會(huì)始終生效）

補(bǔ)充說明一下cookie的作用：

• 保存用戶登錄狀態(tài)。例如將用戶id存儲(chǔ)于一個(gè)cookie內(nèi)，這樣當(dāng)用戶下次訪問該頁面時(shí)就不需要重新登錄了，現(xiàn)在很多論壇和社區(qū)都提供這樣的功能。 cookie還可以設(shè)置過期時(shí)間，當(dāng)超過時(shí)間期限后，cookie就會(huì)自動(dòng)消失。因此，系統(tǒng)往往可以提示用戶保持登錄狀態(tài)的時(shí)間：常見選項(xiàng)有一個(gè)月、三個(gè) 月、一年等。
• 跟蹤用戶行為。例如一個(gè)天氣預(yù)報(bào)網(wǎng)站，能夠根據(jù)用戶選擇的地區(qū)顯示當(dāng)?shù)氐奶鞖馇闆r。如果每次都需要選擇所在地是煩瑣的，當(dāng)利用了 cookie后就會(huì)顯得很人性化了，系統(tǒng)能夠記住上一次訪問的地區(qū)，當(dāng)下次再打開該頁面時(shí)，它就會(huì)自動(dòng)顯示上次用戶所在地區(qū)的天氣情況。因?yàn)橐磺卸际窃诤?臺(tái)完成，所以這樣的頁面就像為某個(gè)用戶所定制的一樣，使用起來非常方便
• 定制頁面。如果網(wǎng)站提供了換膚或更換布局的功能，那么可以使用cookie來記錄用戶的選項(xiàng)，例如：背景色、分辨率等。當(dāng)用戶下次訪問時(shí)，仍然可以保存上一次訪問的界面風(fēng)格。

14.web worker

在HTML頁面中，如果在執(zhí)行腳本時(shí)，頁面的狀態(tài)是不可相應(yīng)的，直到腳本執(zhí)行完成后，頁面才變成可相應(yīng)。web worker是運(yùn)行在后臺(tái)的js，獨(dú)立于其他腳本，不會(huì)影響頁面你的性能。并且通過postMessage將結(jié)果回傳到主線程。這樣在進(jìn)行復(fù)雜操作的時(shí)候，就不會(huì)阻塞主線程了。

如何創(chuàng)建web worker：

• 檢測瀏覽器對(duì)于web worker的支持性
• 創(chuàng)建web worker文件（js，回傳函數(shù)等）
• 創(chuàng)建web worker對(duì)象

15.對(duì)HTML語義化標(biāo)簽的理解

HTML5語義化標(biāo)簽是指正確的標(biāo)簽包含了正確的內(nèi)容，結(jié)構(gòu)良好，便于閱讀，比如nav表示導(dǎo)航條，類似的還有article、header、footer等等標(biāo)簽。

16.iframe是什么？有什么缺點(diǎn)？

定義：iframe元素會(huì)創(chuàng)建包含另一個(gè)文檔的內(nèi)聯(lián)框架

提示：可以將提示文字放在<iframe></iframe>之間，來提示某些不支持iframe的瀏覽器

缺點(diǎn)：

• 會(huì)阻塞主頁面的onload事件
• 搜索引擎無法解讀這種頁面，不利于SEO
• iframe和主頁面共享連接池，而瀏覽器對(duì)相同區(qū)域有限制所以會(huì)影響性能。

17.Doctype作用? 嚴(yán)格模式與混雜模式如何區(qū)分？它們有何意義?

Doctype聲明于文檔最前面，告訴瀏覽器以何種方式來渲染頁面，這里有兩種模式，嚴(yán)格模式和混雜模式。

• 嚴(yán)格模式的排版和 JS 運(yùn)作模式是 以該瀏覽器支持的最高標(biāo)準(zhǔn)運(yùn)行。
• 混雜模式，向后兼容，模擬老式瀏覽器，防止瀏覽器無法兼容頁面。

18.Cookie如何防范XSS攻擊

XSS（跨站腳本攻擊）是指攻擊者在返回的HTML中嵌入javascript腳本，為了減輕這些攻擊，需要在HTTP頭部配上，set-cookie：

• httponly-這個(gè)屬性可以防止XSS,它會(huì)禁止javascript腳本來訪問cookie。
• secure - 這個(gè)屬性告訴瀏覽器僅在請(qǐng)求為https的時(shí)候發(fā)送cookie。

結(jié)果應(yīng)該是這樣的：Set-Cookie=.....

19.Cookie和session的區(qū)別

HTTP是一個(gè)無狀態(tài)協(xié)議，因此Cookie的最大的作用就是存儲(chǔ)sessionId用來唯一標(biāo)識(shí)用戶

20. 一句話概括RESTFUL

就是用URL定位資源，用HTTP描述操作

21.講講viewport和移動(dòng)端布局

可以參考我的這篇文章：

響應(yīng)式布局的常用解決方案對(duì)比(媒體查詢、百分比、rem和vw/vh）（https://github.com/forthealllight/blog/issues/13）

22. click在ios上有300ms延遲，原因及如何解決？

(1)粗暴型，禁用縮放

<meta name="viewport" content="width=device-width, user-scalable=no">

(2)利用FastClick，其原理是：

檢測到touchend事件后，立刻出發(fā)模擬click事件，并且把瀏覽器300毫秒之后真正出發(fā)的事件給阻斷掉

作者：forthealllight

https://github.com/forthealllight/blog/issues/19

洞最有可能影響使用WebKit呈現(xiàn)引擎顯示網(wǎng)頁的任何IOS和macOS應(yīng)用程序。到目前為止Apple仍然在調(diào)查。安全研究人員發(fā)現(xiàn)Safari使用的WebKit渲染引擎中存在一個(gè)漏洞，該漏洞會(huì)令使用IOS操作系統(tǒng)的iPhone和iPad系統(tǒng)崩潰并重新啟動(dòng)。

可以通過加載使用特制CSS代碼的HTML頁面來利用此漏洞。CSS代碼不是很復(fù)雜，并嘗試將一種稱為backdrop-filter的CSS效果應(yīng)用于一系列嵌套頁面段（DIV）。

背景過濾器是一種相對(duì)較新的CSS屬性，通過模糊或顏色移動(dòng)到元素后面的區(qū)域來工作。這是一項(xiàng)繁重的處理任務(wù)，一些軟件工程師和Web開發(fā)人員推測，這種效果的渲染會(huì)對(duì)IOS的圖形處理庫造成影響，最終導(dǎo)致移動(dòng)操作系統(tǒng)崩潰。

Sabri Haddouche是加密即時(shí)消息應(yīng)用程序Wire的軟件工程師和安全研究員，也是他發(fā)現(xiàn)了這個(gè)漏洞，并在近日早些時(shí)候在Twitter上發(fā)布了概念驗(yàn)證代碼。

此鏈接將使您的iOS設(shè)備崩潰，而此鏈接將顯示此漏洞背后的源代碼。Haddouche還在推特上發(fā)布了一個(gè)漏洞導(dǎo)致手機(jī)崩潰的視頻短片。Haddouche 在采訪中稱“攻擊使用webkit-backdrop-filter CSS屬性中的弱點(diǎn)，該屬性使用3D加速來處理它們背后的元素”。“通過使用具有該屬性的嵌套div，我們可以快速消耗所有圖形資源并凍結(jié)或內(nèi)核恐慌OS。”Haddouche還表示該漏洞也會(huì)影響macOS系統(tǒng)，而不僅僅是iOS。

研究人員告訴媒體說：“利用當(dāng)前的攻擊（僅限CSS / HTML），它只會(huì)凍結(jié)Safari一分鐘然后放慢速度。” “之后你就可以關(guān)閉標(biāo)簽了。”“為了使它適用于macOS，它需要一個(gè)包含Javascript的修改版本，” “我沒有發(fā)布它的原因是，似乎Safari在強(qiáng)制重啟后仍然存在并且瀏覽器再次啟動(dòng)，因此在惡意頁面再次執(zhí)行時(shí)會(huì)破壞用戶的會(huì)話。”

研究人員表示，在Twitter上發(fā)布代碼之前，他已經(jīng)通知了Apple這個(gè)問題。“我使用他們的安全產(chǎn)品電子郵件聯(lián)系了他們，”Haddouche告訴媒體“他們證實(shí)他們收到了這個(gè)問題并正在調(diào)查它。”

Haddouche告訴媒體稱他在研究多個(gè)瀏覽器上可靠的拒絕服務(wù)（DoS）錯(cuò)誤時(shí)發(fā)現(xiàn)了這個(gè)漏洞。在本月初，Haddouche還發(fā)布了另一個(gè)利用一行JavaScript破壞Chrome和Chrome OS的漏洞。

另一方面，正如一位iOS開發(fā)人員告訴媒體的那樣，這個(gè)漏洞可能比以前想象的存在更廣泛。這是因?yàn)锳pple強(qiáng)制App Store上列出的所有瀏覽器和支持HTML的應(yīng)用程序都使用其WebKit渲染引擎，這意味著該問題很可能會(huì)導(dǎo)致任何能夠加載網(wǎng)頁的應(yīng)用程序崩潰。

目前蘋果公司還未對(duì)這一事件做出正面回應(yīng)。