作為一個前端，可以如何機智地弄壞一臺電腦？

有人說，前端的界限就在瀏覽器那兒。

無論你觸發了多少bug，最多導致瀏覽器崩潰，對系統影響不到哪去。

這就像二次元各種炫酷的毀滅世界，都不會導致三次元的世界末日。

然而，作為一個前端，我發現是有方式開啟次元大門的…

這個實驗腦洞較大，動機無聊，但某種意義上反映了一些安全問題。

想象一下，有天你在家裡上網，吃著火鍋還唱著歌，點開一個連結，電腦突然就藍屏了！想想還真有點小激動。

起因

故事得從localStorage說起。

html5的本地儲存，相信大家都不陌生。將資料以二進位制檔案形式儲存到本地，在當前應用得非常廣泛。

windows下的chrome，localStorage儲存於C:UsersxxxAppDataLocalGoogleChromeUser DataDefaultLocal Storage資料夾中。但如果任由網頁無限寫檔案，對使用者硬碟的傷害可想而知，因而瀏覽器對其做了大小限制。

對於一個域名+埠，PC端的上限是5M-10M之間，移動端的則是不大於2.5M。

那麼問題就變成：這樣的限制足夠保護使用者硬碟了嗎？

關鍵

關鍵的問題在於，這一限制，針對的是一個域名+埠。

也就是說，你訪問同一個域名的不同埠，它們的localStorage並無關聯，是分開儲存的。

我用node簡單地開啟了伺服器，這時，使用者訪問http://127.0.0.1:1000到http://127.0.0.1:1099這100個埠，會請求到同一個頁面index.html。

當然，這個index.html裡涉及了localStorage寫操作。

我試著用瀏覽器分別訪問了幾個埠，結果是分開儲存。一切跟劇本一樣。

自動遍歷

但這種程度還不夠。

如果要讓實驗變得更好（xie）玩（e）一些，問題就變成如何讓使用者自動遍歷這些埠？

iframe是個好的嘗試。

只要一開啟http://127.0.0.1: 1000，頁面的指令碼就會建立一個iframe，去請求http://127.0.0.1: 1001，一直迴圈下去。

當然iframe我們還可以設定為不可見，以掩蓋這種不厚道的行為…

比方說，有人發給你一個連結，你開啟後發現是個視訊，而你根本注意不到背後的指令碼，在視訊播放的幾分鐘裡，快要把你的C盤寫滿。

然後我就看到請求如潮水漸漲：

但是，請求到1081埠，最新的chrome就崩潰掉了…原來iframe巢狀太多，已經到達了瀏覽器的極限。

防止瀏覽器崩潰

C盤還未撐滿，同志還需努力。怎麼辦？

突然想到，到達iframe極限之前，我們可以重定向啊。

每訪問50個埠，就使用window.location.href重定向一次，去確保瀏覽器不崩潰。

事實證明，這種野蠻的方法的確可行。

至此，只要訪問http://127.0.0.1: 1000，就會往Local Storage資料夾裡寫入近500M無用資料：

裡面的資料是這樣的：

繼續實驗的黑科技

算了下我的C盤還有空間嘛，那就把埠數量從100增長到200個。

結果是這樣的，到達了1.17G大小。

在後續的實驗中，我就慢慢地把埠數量與儲存的資料調大。

電腦也執行得越來越慢。這是為什麼呢？

我觀察到，有時候執行localStorage.setItem()後，在資料夾裡不一定立即能看到資料檔案。

我懷疑這些資料會被chrome先放到記憶體裡，以避免重複讀寫帶來的消耗，在空閒或關閉的時機，再寫進硬碟裡。

但此時，瀏覽器已經影響到系統了。它處於一種“不會崩潰”，但“因為佔用了許多記憶體，已經妨礙使用者電腦的正常使用”的狀態。

即使使用者關閉了瀏覽器視窗，也不會很快恢復。

要知道讀寫任務並不是隨視窗關閉而終止的，否則瀏覽器會丟失資料。

遭遇黑科技的人們能做的只有：

等待；

用工作管理員關掉chrome程式，再等待；

相信並嘗試“重啟電腦解決90%電腦問題”的科學論斷。

可以說，瀏覽器的內心幾乎是崩潰的。

最後

最後，還是得用嚴肅臉告誡一下：害人之心不可無。

本實驗，從一開始就是懷揣著將安全問題上交給國家的初衷去做的（是的就是這麼純粹）。

後續，看著C盤還有2G空間，我又把埠增長到2000個，試下會發生什麼。

由於請求過多，需要一定時間，我就去做別的事情了。

回來後發現房間安靜祥和，美輪美奐，一片藍光，像是加了特技。

那麼…

問題來了，計算機修理哪家強？

有點急…

原文釋出時間為：2018-08-27

本文作者：Litten

本文來自雲棲社群合作伙伴“資料與演算法之美”，瞭解相關資訊可以關注“資料與演算法之美”。