瀏覽器：一個家族的奮鬥

原創：

劉欣 碼農翻身 2017-12-12

我是你們每天都要使用的瀏覽器，自從90年代誕生以來，我們這個大家族變得非常的繁榮，在過去的幾十年中，我們一直兢兢業業地幫助你們人類去探索外部的網際網路世界。隨著網際網路和移動網際網路的發展，我們家族終於登上了成功的巔峰：幾乎佔據了全球每一臺電腦和手機。

大家只看到表面的光鮮，可是誰知道我們家族在背後充滿血和淚的不懈努力呢？

1起步：從簡單到混亂

最初的時候，我們瀏覽器家族的工作很簡單，就是從遠端的伺服器下載HTML頁面到本機，然後按照和你們人類的約定，把充滿標籤的HTML文字轉換成你們容易閱讀的頁面。例如當我們遇到<table> 這樣的標籤，我們就展示一個表格，遇到<p>我們就會換行顯示一個新的段落，看到<img> 就知道要顯示一個圖片等等。

由於HTML的結構很簡單，我們展示起來也不難，工作相對比較輕鬆。

可是你們人類很快就不滿足了，嚷嚷著說要看漂亮的頁面，漂亮的佈局，就像報紙雜誌那樣，分欄、圖文混排...... 

於是有不少人盯上了<table>這個標籤，這個標籤本來的目的是為了顯示資料用的，像這樣：

 但是這些人發現，既然表格能把頁面分成一塊一塊的，那完全可以來做頁面佈局啊！ 比如這個單元格可以作為頁面的頭，那個做左邊欄，右邊欄......等等。

這個口子一開，立刻成星火燎原之勢，再加上那些所見即所得的網頁編輯器（如DreamWeaver, FrontPge）推波助瀾，表格佈局大行其道。

這可苦了我們瀏覽器家族，我們經常發現HTML中那些令人恐怖的表格，一個套著一個，我見過最極端的有上百個表格套在一起，組成超級無敵的頁面。為了把這些表格解析、展示出來，我們都是戰戰兢兢、如履薄冰，生怕出什麼差錯。

有時候，程式設計師會忘記寫一些標籤的閉合標籤，例如</a> </td>，我們還得猜測、推理、論證，最後展示出來的東西你們還不滿意：這是什麼玩意兒，連個HTML都顯示不對！

我們家族的IE同學在這方面的研究可以說是登峰造極，他非常擅長處理這種亂七八糟的情形，他的縱容成功地讓你們把HTML越寫越亂！

2CSS來拯救

終於有一天這樣的HTML頁面連你們人類都看不懂了，你們吵了半天，放了一個“損招”出來：把結構和展示分開！ 

HTML只負責文件的結構，一個叫做CSS的東西來控制這個結構到底展示成什麼樣子。

在CSS中，程式設計師只需要用宣告的方式說，這個表格寬度是1px, 字型是11px, 邊框顏色是 #666666，然後你們就不管了，具體怎麼實現全部扔給了我們：

table.gridtable { 

    font-family: verdana,arial,sans-serif; 

    font-size:11px; 

    color:#333333; 

    border-width: 1px; 

    border-color: #666666; 

    border-collapse: collapse; 

}

對於你們來說變簡單了，可是對我們瀏覽器來說就太難了。我們得老老實實地去解析HTML （這HTML有可能還不規範），形成一顆叫做DOM（Document Object Model）的樹，這還不算，還要去解析CSS, 形成另外一個叫做CSSOM (CSS Object Model)的樹，然後把兩棵樹合併成一個“渲染樹” 這才能在介面上繪製出來。

現在的CSS都已經出到第三個版本了，可是我們家族還有不少人沒法完整的支援這個規範，尤其是一些老舊的瀏覽器，可見這是多麼不容易啊。

3誤入歧途

我們家族也走過一段彎路，那是一段不堪回首的瀏覽器外掛的歷史。

當時有人提出HTML+CSS太簡單了，瀏覽器中的頁面沒法和當時的桌面應用相媲美，能不能用擴充套件一下啊？

最早的嘗試來自於Java Applet，這也是Java 賴以成名，從此走上第一大程式語言的絕技。那幫瘋狂的傢伙們竟然在我們這單薄的小身板裡安裝了一個Java 虛擬機器，用於從伺服器端下載Java 程式碼、執行，展示出漂亮的動畫效果。

剛開始的時候我們努力地支援，但是它執行起來慢如蝸牛、醜陋無比。我們那些可愛的使用者也不答應，不去安裝或者禁止使用這傻大笨粗的Java 虛擬機器，於是Java Applet就慢慢地銷聲匿跡了。

與此同時，一個叫做流氓外掛的毒瘤也迅速地向我們襲來，在你瀏覽網頁的時候，這些流氓靜悄悄地潛入我們的身體，他們傳播病毒、彈出廣告、窺探使用者隱私，並且難於解除安裝，讓我們痛不欲生。後來數字公司推出了一個保鏢，殺了一個回馬槍，這次把流氓給清除了出去。

當然不能一棍子打死，外掛中也有良民，比如Flash , 這小子可是風光了好多年，收到了人民群眾的廣泛喜愛，當年出現了很多的Flash 小動畫，小視訊，小遊戲，我至今還記得有好事者竟然用Flash 去做《鹿鼎記》動畫，也不知道他做完沒有。

Flash 極為火爆，我們讓他在我們家族寄宿了20多年，直到移動網際網路時代的崛起，尤其是喬布斯的推波助瀾，這才慢慢退出歷史舞臺。

4重灌上陣：JavaScript

向我們家族裡安裝外掛的嘗試並不成功，但是我們還是想和桌面應用競爭，讓瀏覽器應用有著桌面應用的體驗，這時候有個叫JavaScript的屌絲自告奮勇，說自己可以在瀏覽器中執行程式碼，提高頁面的動態性。

剛開始的時候我們並不待見他，本來解析HTML, CSS就夠我們受的了，我們竟然還要去執行JavaScript程式碼。尤其煩人的是，JavaScript還可能對DOM進行修改，比如讓某個元素隱藏。唉，我們只好把畫好的元素重新渲染，重新繪製。

不僅是控制介面，JavaScript還要執行邏輯，剛開始的時候我們覺得這小子沒啥用處，無非就是做點簡單的判斷，像什麼表單中使用者名稱不能為空了，密碼和確認密碼兩個輸入框的值必須得相等之類。

後來有人搞了一個叫做AJAX的東西出來，從此發展出一堆類似JQuery 、 Bootstrap、ExtJS 這樣的類庫，瀏覽器中的頁面可用性越來越高，體驗越來越好。

最後隨著前端框架（Angular, Backbone, React 等）出現，我們家族在瀏覽器中完全實現了介面的展示和頁面的調整，成功地做了前後端分離，把端伺服器做的生意給搶過來一大部分，把他們氣得夠嗆。

5替人類儲存資料

HTML來負責結構，CSS負責展示，JavaScript負責行為，這是我們每天要做的三件大事，還有一件重要的事情就是儲存資料。

想當年，人類把HTTP設計成一個沒有狀態的協議，即使是同一個人，在極短的時間內訪問同一個伺服器，伺服器也會認為這是完全兩個不同的請求，根本不知道是同一個人發出的。

當有成千上萬的人都來訪問同一個伺服器的時候，伺服器怎麼才能把大家區分開呢？要是不區分開，伺服器端怎麼才能實現購物車的功能？伺服器怎麼才能記住這個褲子是張三買的，那個羽絨服是李四買的？

後來人類出了一個損招：當用戶使用我們訪問伺服器的時候，會給每個使用者都建立一個會話，每個會話都有一個獨一無二的ID。這個ID伺服器端會儲存，同時也會發回到我們瀏覽器這邊，讓我們暫存起來，美名其曰小餅乾(cookie)，聽起來不錯，但是這個小餅乾卻不能吃。

當用戶訪問同一網站的時候，我們還得把這個cookie 向伺服器傳送過去，伺服器通過cookie取到那個會話ID，於是就知道是誰在訪問它了。

我們儲存了這個小餅乾，但是大家覺得這個小餅乾能儲存的資料量太小，於是我們就在瀏覽器中又開闢了兩塊巨大的空間，給JavaScript 那小子提供了介面，讓他把字串儲存到瀏覽器中。

這兩塊空間一個叫localStorage, 一個叫sessionStorage 。他們倆的用法非常相似，例如：

localStorage.setItem("username", "Andy");

alert("username=" + localStorage.getItem("username"));

這樣以來使用者就可以放心地在我們這裡儲存大量的資料了。只不過這個sessionStorage 和cookie類似，表示的是一個會話的概念，所以一般來說，頁面一旦關閉，儲存的資料就會消失。

但是這個localStorage 就不同了，只要你不把資料刪除，它會一直存在。這引起了我們家族有些人的強烈抗議：如果JavaScript那小子忘記刪除，那垃圾豈不越來越多？

沒辦法，只有拜託各位程式設計師了，對於無用的資料，及時刪除吧。

6向多媒體和遊戲進軍

要讓瀏覽器變成一個和桌面應用相媲美的平臺，僅僅有展示頁面和儲存資料的能力是不夠的。我們決定增加對視訊和音訊的支援，這一次直接撕去了外掛的偽裝，“赤裸裸”地在HTML中加了<video>和<audio>這兩個新標籤，從此以後，家族的每個成員都得想辦法去播放音訊和視訊了：

<video src="movie.mp4" width="320" height="240" controls="controls">

你的瀏覽器不支援video標籤

</video>

<audio src="song.mp3" controls="controls"> 你的瀏覽器不支援audio標籤 </audio>

我們在手機上的瀏覽器兄弟們更加地努力，他們還支援直接呼叫手機的攝像頭去拍攝照片，這實在是太方便了。

既然都能支援音訊、視訊、攝像頭了，何不更進一步，在瀏覽器中搞一把實時通訊？

不用額外安裝外掛或者第三方軟體，在兩個瀏覽器之間就能進行語音或者視訊的聊天，這個想法確實是挺激動人心的，我們把它稱為WebRTC。不過這個想法的實現比較困難，雖說我們家族的Chrome再不遺餘力地推動，但是要讓我們家族在所有的平臺上（Windows, Android, iOS,mac）都實現了還需要繼續努力。

此外我們還一直惦記著遊戲這個令人垂涎三尺的大市場，絕對不能放過！ 於是我們添加了<canvas>的標籤，意思是畫布，這樣JavaScript那小子就可以在畫布上去繪製路徑、各種形狀、新增圖片...... 總而言之，程式設計師終於可以寫出一個只依賴瀏覽器就可以執行的遊戲了，完全不用什麼Flash 。

看看下面這兩個簡單的小遊戲，如果我不告訴你，估計你都不知道這完全是HTML+JavaScript  做出來的吧：

水果忍者

中國象棋

7讓伺服器從被動變為主動

你們人類原來指定的HTTP協議都是從我們這裡向伺服器端發出請求，然後伺服器響應，一個請求，一個響應，嚴格對應。

後來大家發現這樣不好，伺服器一直處於被動的地位，伺服器端的資料有了變化（例如股票又漲了）後，瀏覽器如果不主動訪問的話是不知道的，所以瀏覽器只好一遍遍不厭其煩地傳送請求：　

瀏覽器：股票漲了沒有？　伺服器：沒有

瀏覽器：股票漲了沒有？　伺服器：沒有

瀏覽器：股票漲了沒有？　伺服器：沒有

......

瀏覽器：股票漲了沒有？　伺服器：漲了　

這種方式叫做輪詢，效率極為低下。

能不能讓伺服器向我們主動地推送資料呢 ？股票一漲，立刻就向瀏覽器推送，瀏覽器即刻展示。

我們和伺服器做了多次談判，終於建立了這麼一個辦法：雙方建立連線以後就不要斷開了，一直保持住，我們可以通過這個通道向伺服器傳送資料，伺服器也可以主動向我們推送資料。

這個技術，我們把它稱為Web socket。

8總結

CSS, JavaScript , 本地儲存，多媒體和遊戲，Web Socket ...... 這只是我們家族提供的一部分服務，還有很多其他的服務例如HTML標籤的語義化：我們提供了很多諸如<article> , <section> , <nav> ,<aside>, <header>,<footer>這樣的標籤來幫助你們人類更好的定義網頁的結構。

這樣的東西非常非常的多，我想你應該明白我們家族的不斷努力了吧，如果你一邊聽我講一邊在思考，也許會悟出我們的使命：不斷提升應用程式在Web端的體驗。

也許有一天，所有的桌面應用都消失了，全部變成了在瀏覽器中執行的程式，那將是我們瀏覽器家族榮耀的頂峰，我們期待著這一天早日到來。

（完）

黑客三兄弟

原創： 老劉 碼農翻身 2017-12-26

建立Beauty.com的黑客三兄弟最近可謂是春風得意，他們的這個網站精準地利用了人類的本性，竊取了不少登入使用者的cookie。

（碼農翻身注：參見前文《瀏覽器的安全反擊戰》）

利用別人的cookie，他們可以冒充真實的使用者，在頒發cookie的那個網站中為所欲為，個人隱私在他們面前根本不存在。

運氣好的話連別人的使用者名稱和密碼都能得到，那就一通百通，因為大家都嫌麻煩，總是使用同一套使用者名稱和密碼來登入各種不同系統。

可是好景不長，這一天黑客老三慌慌張張地找到了老大：“大哥，大事不好！ ”

“老三，你這慌慌張張的毛病什麼時候能改改？ 這點兒你可得學學你二哥。” 老大訓斥道。

“不是，大哥，這次真是大事不妙，瀏覽器家族最近頒佈了一個什麼同源策略，我們原來偷Cookie的招數都不管用了！ 今天我連一個Cookie，使用者名稱密碼都沒有偷到。”

“什麼叫偷，說了多少次了，那就借，知道不？！”

（碼農翻身注：同源策略參見前文《瀏覽器的安全反擊戰》）

“我早就料到了，這麼重大的安全漏洞肯定肯定會補上的，他們不會這麼輕易地讓我們來跨域來訪問別人的Cookie，修改別人的DOM，呼叫別人的服務的。”  老成持重的黑客老二說道。

“那怎麼辦？ 沒有Cookie，難道我們三兄弟以後就餓肚子了嗎？”  老三很緊張。

“別擔心，我們哥仨勾兌勾兌，他們肯定有漏洞的，” 老大安慰到，“老二，你先說說你的看法。”

“其實吧，我們想去借一個Cookie來用，關鍵是要讓我們Beauty.com的JavaScript在目標瀏覽器上執行，然後訪問愛存不存銀行(icbc.com.cn)的cookie，可是現在他們用了同源策略，我們網站的JavaScript不允許訪問別人網站的東西，那這條路就行不通了。”

“我想到一個招數，” 老三興奮地說，“我們可以想辦法修改下icbc.com.cn伺服器端的JavaScript， 把偷Cookie的程式碼加上去！”

“你想得美，那豈不得到icbc.com.cn的伺服器去修改了！還得黑掉別人的伺服器，這就難了，即使你修改了，人家程式設計師再次釋出新版本，那不就把我們的修改給覆蓋掉了？” 老大再次訓斥。

“那我們就想辦法去黑掉程式設計師的SVN，Github，直接把上面的程式碼給改了.....”  老三的聲音越來越小。

“唉，算了吧，我們盜亦有道，只做Web端黑客。” 老大重申三人組織的性質。

這時候老二想了一個辦法：“其實老三說的也有道理，我們只要想辦法把JavaScript程式碼注入到目標頁面中，就能繞過同源策略了，這讓我想到了HTML中的<input>，這個標籤會在瀏覽器中產生一個輸入框，讓使用者輸入資料，我們可以把JavaScript程式碼當做資料輸入進去， 等到資料提交到伺服器端，會儲存下來，下次展示頁面的時候不就可以執行了嗎？！”

老三說：“二哥我聽不太明白，你能不能舉個例子？”

老二說道：“好吧，有這麼一個網站，可以讓你對某個文章輸入評論：”

“然後，你在評論區輸入了這樣的程式碼，注意，我們注入了一段'JavaScript'”

“等到再次有人訪問這個頁面的時候，會發生什麼呢？”  老二啟發老三。

“奧，我明白了，那就可以把那個人的cookie顯示出來了！”老三一點都不笨。

興奮之餘，老三撓撓頭：“ 但是這只是在人家的瀏覽器中顯示，怎麼才能發到我們的伺服器呢？ 用JavaScript來發？ 那也不行， 因為同源策略嚴格限制JavaScript的跨域訪問吶！”

老大也說：“是啊，這個人看到自己的cookie被alert出來，估計會嚇一跳吧。”

老二說：“嗯，確實不能這麼辦，讓我想想。”

一炷香時間過去，老二說：“有了！ 那個同源策略並不限制<img>這樣的標籤從別的網站（跨域）去下載圖片，我們在注入JavaScript程式碼的時候，同時建立一個使用者不可見的<img>，通過這個<img>發cookie發給我們。”

老三還是不明白， 要求再詳細解釋一下，老二就上了程式碼：

老二說：“看到了吧，只要這段程式碼被執行，使用者的cookie就會發到我們伺服器上(http://beauty.com/log)，我們就等著收取cookie吧！”

老三感慨道：“二哥你真厲害，天馬行空，竟然想到了使用<img>的src屬性來發送資料！”

老大說：“我們乾脆把這段程式碼封裝成一個js檔案，嗯，就叫做beauty.js吧， 這樣以後我們用起來會很方便！”

老三看到又可以‘借到’cookie了，興奮得直搓手： “大哥二哥，我這就去把JS寫出來，找個網站試一試。”

老大說道：“我們把這種方法叫做Cross Site Scripting ，簡稱CSS，二弟意下如何？”

老二說：“大哥， CSS已經名花有主了，意思是層疊樣式表，我們還是叫做XSS吧！”

（碼農翻身注：按照XSS的分類方法， 上面介紹的叫做儲存性XSS， 危害最大。 還有反射型XSS,基於DOM的XSS，本文不再展開。）

大家都表示同意。

老三很快寫出了beauty.js， 也折騰出了http://beauty.com/log 專門用於記錄‘借’來的cookie。

他找了一家網站做實驗，注入了beauty.js， 沒過多久，cookie就源源不斷地發過來了。大家都非常高興，馬上擴大範圍，在多個知名網站上都做了手腳。

一週以後，負責監控的老三發現，cookie越來越少，老三趕緊調查，發現很多網站的Cookie都加上了HttpOnly這樣的屬性：

Set-Cookie：JSESSIONID=xxxxxx;Path=/;Domain=book.com;HttpOnly

這個cookie一旦加上HttpOnly，瀏覽器家族就禁止JavaScript讀取了！ 自然也就無法發回到beauty.com。

老三趕緊向組織彙報。

老大說道：“看來瀏覽器家族又升級了啊！”

老二說：“其實吧， 既然我們可以往指定的頁面注入JavaScript程式碼，那這個JavaScript可以做的事情就多了去了，不一定只是借Cookie。例如我們可以用這個JS程式碼畫一個假的登入框，覆蓋到真的登入框之上，讓使用者信以為真，這樣就可以偷到真實的使用者名稱和密碼了。 或者通過JavaScript構造GET,POST請求，可以模擬使用者在該網站做點手腳，刪點什麼東西，從一個賬號往另外一個賬戶轉賬，都是可以的嘛！”

“妙極， 老二，真有你的，老三，你去找點網站，按二哥說的試試。”

又過了幾天，老三哭喪著臉說道：“大哥二哥，這些徹底玩完，現在人類出手了，來了幾個必殺技。”

“什麼必殺技？”

“一方面他們有人會對輸入進行過濾，發現不符合他們要求的輸入例如<,>等就會過濾掉，我們的<script>可能會變成'script' 被存到資料庫裡。”

“另一方面有人還會對輸出進行編碼/轉義操作，例如會把'<'變成 '&lt;'，把 '>' 變成‘&gt;’ ，然後再輸出，這樣一來我們的<script>就會變成&lt;script&gt; ， 瀏覽器收到以後，就會認為是資料，把<script>作為字串給顯示出來，而不是執行後面的程式碼！”

老二說：“三弟別失望， 幹我們這行的，就是矛和盾之間的較量，雖然在原理上大家已經知道了怎麼防範XSS，但是在實踐中總會有漏洞，我們只要耐心尋找就行了。 此外，我們還要想想別的辦法，看看能不能開闢其他路子。”

“什麼路子？” 老三問道。

“你們應該知道，一個使用者的會話cookie在瀏覽器沒有關閉的時候，是不會被刪除的，對吧？”

“是的，我和老三都知道，我們不是一直試圖去拿到這個cookie嗎，只是越來越難了。”

“我們換下思路，不再去偷這個cookie了，相反，我們在我們的Beauty.com中構造一個領獎頁面，裡邊包含一個連線，讓使用者去點選，例如：”

恭喜你獲得了iPhone X一臺,快來 <a href="www.icbc.com.cn/transfer?toBankId=黑客三兄弟的賬戶&money=金額">領取吧！</a>

“當然，” 老二補充道，“我們得事先知道icbc.com.cn的轉賬操作的url和引數名稱。如果這個使用者恰好登入了icbc.com， 那他的cookie還在， 當他禁不住誘惑，點了這個連結後，一個轉賬操作就神不知鬼不覺的發生了。”

（碼農翻身注：為了方便展示，本文舉了一個非常簡單的案例，銀行實際的轉賬操作要遠遠比文章描述安全得多。）

“那要是使用者就是不點選呢？”

“你忘了我們XSS中使用過的img了嗎， 也可以應用到這裡來啊，建立一個看不見的圖片：”

<img src="www.icbc.com.cn/transfer?toAccountID=黑客三兄弟的賬戶&money=金額">

“只要他打開了這個頁面，不用點選任何東西，就會發生轉賬操作。”  老二再次祭出了img大法。

“怪不得現在有很多郵箱預設不顯示郵件中的圖片呢！”老三說，那要是人家icbc.com.cn的轉賬操作需要form表單，是POST操作呢？”

“那也不怕啊，我們可以把這個表單建立起來，放到一個不可見的iframe中，使用者只要一訪問，就用JavaScript自動提交。” 老大對這種辦法駕輕就熟。

“總之，只要這個使用者在訪問icbc.com.cn的時候， 訪問了我們的網站，就極有可能中招，我們這種方式，只是利用了一下合法的Cookie，在伺服器看來，我們發出的請求，那就是一次合法的請求啊，哈哈！” 老二很得意。

“老二，你這叫跨站請求偽造啊，Cross Site Request Forgery（CSRF），這個縮寫應該不會重複了吧！” 老大做了總結。

用了CSRF， 三兄弟果然獲利頗豐，但是人類也很快也意識到了這一點，應對手段馬上就來了，步驟特別簡單：

1. 使用者在icbc.com.cn轉賬，顯示轉賬的form，除了常用的欄位之外，額外新增一個token ：

這個token是icbc.com伺服器端生成的，是一個隨機的數字。

2. 使用者的轉賬資料傳送的伺服器端， icbc.com就會檢查從瀏覽器發過來的資料中有沒有token,並且這個token的值是不是和伺服器端儲存的相等，如果相等，就繼續執行轉賬操作，如果不相等，那這次POST請求肯定是偽造的。

老三愁眉苦臉地對大家說：“這個token是伺服器端生成的，我們無法偽造的，CSRF的手段也不行了。”

老大安慰道：“錢哪有那麼容易就好掙的？ 我們還是想想辦法，多利用XSS漏洞吧，如果可以注入JavaScript， 就可以讀取Token,為所欲為了。 ”

老二說：“大哥，Web端的油水越來越少，我們也得與時俱進，擴充套件下業務啊，黑客三兄弟向伺服器端進軍吧！”

“二弟所言極是，下週我們再討論吧。”

（完）

瀏覽器家族的安全反擊戰

原創： 老劉 碼農翻身 2017-12-19

1前言

上次我說過，我們瀏覽器的主要工作就是把HTML，JavaScript，CSS等檔案從伺服器端取下來，然後解析、渲染，展示成美奐美倫的頁面呈現給人類。

我們還替人類保護一個叫做Cookie的小東西，網站會把Cookie傳送給瀏覽器讓我們儲存起來，等到訪問同一個網站的時候，我們再把他發過去。

這個Cookie用來證明某個使用者已經和伺服器互動過，更重要的是證明已經登入過系統，不用再次登入了。

JavaScript這小子在我們這裡承擔了越來越重要的職責，從對DOM樹的改動，到利用AJAX訪問伺服器端，他可以說是風光無限。

可是我們都忽視了一個重要的問題：安全，這個東西差點讓我們家族遭受滅頂之災。

2Cookie失竊

有一天，我的主人登入了"愛存不存"銀行(www.icbc.com)，這個銀行網站給我發了一個Cookie，證明主人登入過了， 主人在“愛存不存”銀行網站做了一些操作，但是忘記了退出，然後開了一個新的Tab頁訪問了一個叫做www.beauty.com ,我知道這個網站不懷好意，拼命地提醒主人，但是他仍然經不住網站上那些圖片的誘惑，執意把這個網站開啟。

我沒有辦法，只好下載這個不懷好意網站的HTML,JavaScript，CSS， 讓我沒有想到的是這裡的JavaScript竟然想訪問“愛存不存”銀行的Cookie。

“這個Cookie是愛存不存銀行給我的，不屬於www.beauty.com，你為啥要訪問？” 我問他。

“沒事，我好奇，想看看別的網站的Cookie長什麼樣”  他輕鬆地回答。

我將信將疑地把Cookie給了他，他不知道做了什麼花樣，似乎是往www.beauty.com發了一個請求，然後就把Cookie還給了我。

很快我的主人就發現，他在“愛存不存”銀行的私房錢不翼而飛了。

FireFox嘲笑我說：“你這個傢伙啊，怎麼能夠把Cookie這麼重要的東西隨隨便便地給別人呢？ ‘愛存不存’銀行的Cookie被黑客偷走了，那些黑客不用登入就可以冒充使用者在‘愛存不存’網站做操作了。”

“啊？ 有這麼嚴重？ 可他是JavaScript，照理說可以訪問啊？”

“唉，你要知道，這個JavaScript和那個Cookie不是同一個網站的，怎麼能訪問呢。”

由於這件事，主人再我不理我了，從此開始寵幸FireFox。

3密碼失竊

FireFox也沒得意很久，他也很快中了招。

這一次，主人還是忍不住去www.beauty.com看圖片，FireFox這次很小心，不把任何別的網站的Cookie發給這裡的JavaScript。

但這一次beauty.com改變了策略，它用iframe的方式放置了一個淘寶的登入網頁到beauty.com頁面中，淘寶恰恰是主人最喜歡的，主人一看，不錯啊，還有快捷登入方式，於是主人就輸入了自己真實的使用者名稱和密碼，沒想到Beauty.com的JavaScript 已經把這個淘寶登入Form的action指向了自家網站，等到主人點了登入按鈕以後， 使用者名稱和明文的密碼就這樣被竊取了。

於是FireFox也被打入冷宮。

4家族會議

黑客猖獗，類似的安全事故不斷出現，我們家族的成員紛紛中招，家族趕緊召集會議，商量對策，防止人類把我們家族給廢掉。

我和FireFox在會議上聲討現在的人類實在是喜歡訪問那些不良網站，族長Mozilla說沒辦法這是人類的本性，無論如何也無法改變，如果改了就不是人類了。

“雖然我們控制不了人類的行為，但是我們瀏覽器家族可以做點改變，增加安全性！” Mozilla族長充滿正義感和使命感，他下達了一個命令：“以後我們家族確定一條鐵規：除非兩個網頁是來自於統一‘源頭’， 否則不允許一個網頁的JavaScript訪問另外一個網頁的內容，像Cookie，DOM，LocalStorage統統禁止訪問！” 

我仔細咂摸這句話的含義，其實是說各個網頁如果不同源的，就被隔離了，只能在自己的一畝三分地中折騰。

“什麼叫同一個源頭？” FireFox問道。

“就是說{protocol,host,port} 這三個東西必須得一樣！ 我給你們舉個例子， 例如有這麼一個網頁： http://www.store.com/product/page.html， 下面的表格列出了各種不同情況。”

這個同源策略確實嚴格， 不同源的網頁無法訪問另外一個網頁的DOM,Cookie, 像beauty.com那樣的惡意網站想偷走Cookie/密碼就不容易了。

我想到了主人之前購物經常訪問的http://www.store.com/, 這個頁面中有一段裝載jquery.js的程式碼：

<script src="//static.store.com/jquery.js > </script>

這個jquery.js是來自於不同的源（static.store.com）， 難道他就沒法操作www.store.com頁面的內容了嗎？ 如果不能操作，這個jquery.js就沒有任何用處啦！

我把這個困惑給大家說了下， FireFox馬上附和： “沒錯，難道我們要強制人類把所有的JavaScript程式碼放到www.store.com下嗎？ 人類肯定不能容忍！ ”

“嗯，這是個好問題”  Mozilla族長說，“這樣，我給你們開個口子，對於使用<script src='xxxxx'> 載入的JavaScript，我們認為它的源屬於www.store.com， 而不屬於static.store.com，這樣就可以操作www.store.com的頁面了，行不行？”

我和FireFox都表示贊同，其實這種“嵌入式”的跨域載入資源的方式還有<img>,<link>等，相當於我們瀏覽器發起了一次GET請求，取到相關資源，然後放到本地而已。

同源策略就這麼確定下來了， 我們這些瀏覽器都開始嚴格遵守執行，果然，安全事故大大減少。

5凡事都有例外

過了一段時間，JavaScript這小子便跑來抱怨了：“你們這個同源策略實在太嚴格了，太不方便了。”

我說：“這也是為了大家好啊，省得那些不良網站幹壞事。”

JavaScript說：“好什麼好？ 現在人類的系統越來越大，大部分都拆分成分散式的了，每個系統都有子域名，像login.store.com, payment.store.com， 雖然二級域名不同，但是他們屬於一個大的系統，由於同源策略的鐵規，cookie不能在這個系統之間共享，麻煩死了。”

這確實是個問題，我帶著JavaScript找到到Mozilla組長，說明情況，希望他網開一面。

族長說：“好吧，我再給你們開個口子，如果兩個網頁的一級域名是相同的，他們可以共享cookie, 不過cookie的domain一定要設定為那個一級域名才可以，例如：”

document.cookie = 'test=true;path=/;domain=store.com'

JavaScript說：“還有個大問題，你們為什麼不讓我使用XMLHttpRequest訪問不同的網站啊！”

我心想JavaScript說的可能是AJAX，可以建立一個XMLHttpRequest物件去非同步的訪問伺服器端提供的服務，做到區域性重新整理頁面，使用者體驗很好。

難道這個XMLHttpRequest物件只能訪問源伺服器（如book.com），不能訪問其他伺服器(如beauty.com)?

族長說：“是啊，XMLHttpReqeust也要遵守同源策略。”

JavaScript說：“可是這沒有道理啊！我雖然是從book.com來的，但是為什麼不讓我訪問beauty.com？”

族長說：“我這也是為了防止黑客攻擊，給你舉個例子，假設你的主人登入了book.com , 然後又去訪問beauty.com，如果這個beauty.com是個惡意網站，它也要求你建立一個XMLHttpRequest物件，通過這個物件向book.com（不同源）發起請求，獲取你主人的賬戶資訊，會發生什麼情況？ ”

JavaScript恍然大悟：“奧，我懂了，由於主人登入過了book.com，登入cookie什麼的都在，那beauty.com的JavaScript 向book.com發起的XMLHttpRequest請求也會成功，我主人的賬戶資訊就會被黑客給獲取了。”

我說：“看來對XMLHttpReqeust物件施加同源策略也是非常重要的啊！”

JavaScript沉默了半天說：“那怎麼辦？”

Mozilla族長說：“你可以通過伺服器端中轉啊，例如你是來自book.com的， 現在想訪問movie.com，那可以讓那個book.com把請求轉發給movie.com嘛！人類好像給這種方式起了個名字，叫什麼代理模式，那個book.com就是代理人。”

JavaScript急忙說：“不不， 這樣太麻煩了，族長你想想，如果我要訪問多個不同源的系統，要是都通過book.com中轉，該多麻煩！”

族長想了想說：“你說得有一定道理，我給你出個主意，既然伺服器（domain）之間是互信的，那一個伺服器(domain)可以設定一個白名單，裡邊列出它允許哪些伺服器(domain)的AJAX請求。假設movie.com的白名單中有book.com， 那當屬於book.com的JavaScript試圖訪問movie.com的時候......”

JavaScript馬上介面說：“ 這時候，我們瀏覽器做點手腳，悄悄地把當前的源(book.com)發過去，詢問下movie.com, 看看他是否允許我們訪問，如何允許，你們就繼續訪問，否則就報錯！”

組長說：“就是這個意思，這樣以來，那些黑客就沒有辦法假冒使用者向這些互信的伺服器傳送請求了， 我把這個方法叫做Cross Origin Resource Sharing，簡稱CORS，只不過這個方法需要伺服器的配合了”

(碼農翻身注：上面說的是CORS的簡單請求，對於Preflight請求，本文不在展開描述)

JavaScript表示同意，這也算是一個不錯的妥協方法了。

（完）

一個故事講完https

原創： 老劉 碼農翻身 2017-07-17

1  序言

今天來聊一聊https 安全傳輸的原理。

在開始之前，我們來虛構兩個人物， 一個是位於中國的張大胖（怎麼又是你？！）， 還有一個是位於米國的Bill (怎麼還是你？！)。

這倆哥們隔著千山萬水，通過網路聯絡上了， 兩個人臭味相投，聊得火熱。

此時正值米國大選， 張大胖親切地“致電”Bill, 對米國總統大選的情況表示強烈地關注。 Bill則回電說謝謝關心米國人的事情我們米國人自己做主，不用你們歪果仁瞎操心......

張大胖繼續“致電”說其實我們支援特朗普， 因為希拉里太情緒化，太難打交道了， 我們挺希望看到特朗普上臺這樣米國就會變成 The Divided State of America ......

Bill 回電： 拉倒你吧你， 我們米國的政體有著強大的糾錯性， 雖然有時候發展得慢， 有時候會走上岔路， 但很快就會回到正途，幾百年來穩定得很，不像你們像坐了過山車一樣.....

兩個人越聊越投機，天南地北，海闊天空，還夾雜著不少隱私的話題。

2 總是有一種被偷看的感覺

有一天， Bill 突然意識到： 壞了， 我們的通訊是明文的， 這簡直就是網路上裸奔啊， 任何一個不懷好意的傢伙都可以監聽我們通訊，開啟我們傳送的資料包，窺探我們的隱私啊。

張大胖說： “你不早點說，我剛才是不是把我的微訊號給你發過去了？ 我是不是告訴你我上週去哪兒旅遊了?   估計已經被人截取了吧！”

Bill  提議： “要不我們做個數據的加密？ 每次傳輸之前， 你把訊息用一個加密演算法加密， 然後發到我這裡以後我再解密， 這樣別人就無法偷窺了，像這樣： ”

張大胖冰雪聰明，一看就明白了， 這加密和解密演算法是公開的，那個金鑰是保密的， 只有兩人才知道， 這樣生成的加密訊息（密文） 別人就無法得知了。 他說： “Bill 老兄，你生成一個金鑰， 然後把金鑰發給我， 咱們這就開啟加密訊息， 讓那些偷窺狂人們哭去吧！”

（碼農翻身注：這叫對稱加密演算法， 因為加密和解密用的是同一個金鑰）

一炷香功夫過去了， Bill 還是沒有迴音， 張大胖忍不住地催促： “快發啊？！！！”

Bill 終於回覆了： “ 我感覺有一雙眼睛正在虎視眈眈地盯著我們的通話， 如果我把金鑰發給你， 也被他截取了， 那加密豈不白費工夫？”

張大胖沉默了， 是啊， 網路是不安全的， 這金鑰怎麼安全地發過來啊 ？　

“奧，對了，我下週要去米國旅遊，到時候我們見一面，把密碼確定下來，寫到紙上，誰也偷不走， 這不就結了？”　

“哈哈， 這倒是終極解決之道 ”  Bill 笑了， “不過，我不僅僅和你聊天， 我還要和易卜拉欣，阿卜杜拉， 弗拉基米爾，克里斯托夫，瑪格麗特， 橋本龍太郎， 李賢俊， 許木木，郭芙蓉，呂秀才等人通訊， 我總不能打著飛的，滿世界的和人交換密碼吧？ ”

張大胖心裡暗自佩服Bill同學的好友竟然遍佈全球，看來他對加密通訊的要求更加強烈啊！

可是這個加密解密演算法需要的金鑰雙方必須得知道啊， 但是金鑰又無法通過網路傳送， 這該死的偷窺者！

3  RSA : 非對稱加密

Bill 和 張大胖的通訊無法加密，說話謹慎了不少， 直到有一天， 他們聽說了一個叫做RSA的非對稱加密演算法，一下子來了靈感。

這個RSA演算法非常有意思，它不是像之前的演算法， 雙方必須協商一個保密的金鑰， 而是有一對兒鑰匙， 一個是保密的，稱為私鑰，另外一個是公開的，稱為公鑰。

更有意思的是，用私鑰加密的資料，只有對應的公鑰才能解密，用公鑰加密的資料， 只有對應的私鑰才能解密。

有了這兩個漂亮的特性， 當張大胖給Bill發訊息的時候， 就可以先用Bill的公鑰去加密（反正Bill的公鑰是公開的，地球人都知道）， 等到訊息被Bill 收到後， 他就可以用自己的私鑰去解密（只有Bill才能解開，私鑰是保密的 ）

反過來也是如此， 當Bill 想給張大胖發訊息的時候，就用張大胖的公鑰加密， 張大胖收到後，就用自己的私鑰解密。

這樣以來，通訊安全固若金湯， 沒有任何人能窺探他們的小祕密了。

4 非對稱加密+對稱加密

兩人實驗了幾次，  張大胖說： “Bill  , 你有沒有感覺這個RSA的加密和解密有點慢啊？”

Bill嘆了口氣 ：“是啊， 我也注意到了， 剛才搜了一下，這個RSA演算法比之前的對稱金鑰演算法要慢上百倍。我們就是加個密而已，現在搞得都沒法用了”

“回到咱們最初的問題，我們想用一個金鑰來加密通訊，那個對稱加密演算法是非常快的，但是苦於金鑰無法安全傳輸， 現在有了RSA ,我想可以結合一下， 分兩步走　(1) 我生成一個對稱加密演算法的金鑰， 用RSA的方式安全發給你，  (2) 我們隨後就不用RSA了， 只用這個金鑰，利用對稱加密演算法來通訊,  如何？   ”

Bill 說： “你小子可以啊， 這樣以來既解決了金鑰的傳遞問題， 又解決了RSA速度慢的問題，不錯。”　

於是兩人就安全地傳遞了對稱加密的金鑰， 用它來加密解密，果然快多了！

5 中間人攻擊

張大胖把和Bill 聊天的情況給老婆彙報了一次。

老婆告誡他說： “你要小心啊， 你確定網路那邊坐著的確實是Bill ?”

張大胖著急地辯解說：“肯定是他啊，我都有他的公鑰，我們倆的通訊都是加密的。”

老婆提醒道：＂假如啊，Bill給你發公鑰的時候， 有個中間人，截取了Bill的公鑰， 然後把自己的公鑰發給了你，冒充Bill ，你發的訊息就用中間人的公鑰加了密，　那中間人不就可以解密看到訊息了？＂

張大胖背後出汗了，是啊，這個中間人解密以後，還可以用Bill的公鑰加密，發給Bill ,  Bill和我根本都意識不到， 還以為我們在安全傳輸呢！

看來問題出現在公鑰的分發上！  雖然這個東西是公開的， 但是在別有用心的人看來，擷取以後還可以幹壞事 ！

6 你到底是誰？

但是怎麼安全地分發公鑰呢？ 似乎又回到了最初的問題： 怎麼安全的保護金鑰？

可是似乎和最初的問題還不一樣，這一次的公鑰不用保密，但是一定得有個辦法宣告這個公鑰確實是Bill的， 而不是別人的。

怎麼宣告呢？

張大胖突然想到： 現實中有公證處，它提供的公證材料大家都信任，那在網路世界也可以建立一個這樣的具備公信力的認證中心， 這個中心給大家頒發一個證書， 用於證明一個人的身份。

這個證書裡除了包含一個人的基本資訊之外，還有包括最關鍵的一環：這個人的公鑰！

這樣以來我拿到證書就可以安全地取到公鑰了 ！ 完美！

可是Bill 馬上潑了一盆冷水：證書怎麼安全傳輸？ 要是證書傳遞的過程中被篡改了怎麼辦？

張大胖心裡不由地咒罵起來： 我操， 這簡直就是雞生蛋，蛋生雞的問題啊。

天無絕人之路， 張大胖很快就找到了突破口： 數字簽名。

簡單來講是這樣的， Bill可以把他的公鑰和個人資訊用一個Hash演算法生成一個訊息摘要， 這個Hash演算法有個極好的特性，只要輸入資料有一點點變化，那生成的訊息摘要就會有鉅變，這樣就可以防止別人修改原始內容。

可是作為攻擊者的中間人笑了： “雖然我沒辦法改公鑰，但是我可以把整個原始資訊都替換了， 生成一個新的訊息摘要， 你不還是辨別不出來？”

張大胖說你別得意的太早 ， 我們會讓有公信力的認證中心（簡稱CA）用它的私鑰對訊息摘要加密，形成簽名：

這還不算， 還把原始資訊和資料簽名合併， 形成一個全新的東西，叫做“數字證書”

張大胖接著說：當Bill把他的證書發給我的時候， 我就用同樣的Hash 演算法， 再次生成訊息摘要，然後用CA的公鑰對數字簽名解密， 得到CA建立的訊息摘要， 兩者一比，就知道有沒有人篡改了！

如果沒人篡改， 我就可以安全的拿到Bill的公鑰嘍，有了公鑰， 後序的加密工作就可以開始了。

雖然很費勁， 但是為了防範你們這些偷窺者，實在是沒辦法啊。

中間人惡狠狠地說： “算你小子狠！ 等著吧，我還有別的招。 對了，我且問你， 你這個CA的公鑰怎麼拿到？　難道不怕我在你傳輸ＣＡ公鑰的時候發起中間人攻擊嗎？　如果我成功的偽裝成了ＣＡ，你這一套體系徹底玩完。”

張大胖語塞了，折騰了半天，又回到了公鑰安全傳輸的問題！

不過轉念一想，想解決雞生蛋，蛋生雞的問題必須得打破這個怪圈才行，我必須得信任ＣＡ，並且通過安全的的方式獲取他們的公鑰，這樣才能把遊戲玩下去。

（公眾號碼農翻身注：這些ＣＡ本身也有證書來證明自己的身份，並且ＣＡ的信用是像樹一樣分級的，高層的ＣＡ給底層的ＣＡ做信用背書，而作業系統／瀏覽器中會內建一些頂層的ＣＡ的證書，相當於你自動信任了他們。　這些頂層的ＣＡ證書一定得安全地放入作業系統／瀏覽器當中，否則世界大亂。）

7  https 

終於可以介紹https了，前面已經介紹了https的原理， 你把張大胖替換成瀏覽器， 把Bill 替換成某個網站就行了。

一個簡化的（例如下圖沒有包含Pre-Master Secret）https流程圖是這樣的， 如果你理解了前面的原理，這張圖就變得非常簡單：

（完）

深入淺出HTTPS工作原理

HTTP協議由於是明文傳送，所以存在三大風險：

1、被竊聽的風險：第三方可以截獲並檢視你的內容

2、被篡改的危險：第三方可以截獲並修改你的內容

3、被冒充的風險：第三方可以偽裝成通訊方與你通訊

HTTP因為存在以上三大安全風險，所以才有了HTTPS的出現。

HTTPS涉及到了很多概念，比如SSL/TLS，數字證書、數字簽名、加密、認證、公鑰和私鑰等，比較容易混淆。我們先從一次簡單的安全通訊故事講起吧，其中穿插複習一些密碼學的概念。

一. 關於Bob與他好朋友通訊的故事

這個故事的原文是：

http://www.youdzone.com/signature.html

阮一峰老師也翻譯過：

http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html

（不過阮老師裡面沒有很好的區分加密和認證的概念，以及最後HTTPS的說明不夠嚴謹，評論區的針對這些問題的討論比較激烈，挺有意思的）

這裡重新敘述一下這個故事：

故事的主人公是Bob，他有三個好朋友Pat、Doug和Susan。Bob經常跟他們寫信，因為他的信是明文傳輸的，在傳遞過程可能被人截獲偷窺，也可能被人截獲然後又篡改了，更有可能別人偽裝成Bob本人跟他的好朋友通訊，總之是不安全的。他很苦惱，經過一番苦苦探索，誒，他發現電腦保安學裡有一種叫非對稱加密演算法的東東，好像可以幫助他解決這個問題

說明：非對稱加密演算法（RSA）是內容加密的一類演算法，它有兩個祕鑰：公鑰與私鑰。公鑰是公開的鑰匙，所有人都可以知道，私鑰是保密的，只有持有者知道。通過公鑰加密的內容，只能通過私鑰解開。非對稱加密演算法的安全性很高，但是因為計算量龐大，比較消耗效能。

好了，來看看Bob是怎麼應用非對稱加密演算法與他的好朋友通訊的：

1、首先Bob弄到了兩把鑰匙：公鑰和私鑰。

2、Bob自己保留下了私鑰，把公鑰複製成三份送給了他的三個好朋友Pat、Doug和Susan。

3、此時，Bob總算可以安心地和他的好朋友愉快地通訊了。比如Susan要和他討論關於去哪吃午飯的事情，Susan就可以先把自己的內容（明文）首先用Bob送給他的公鑰做一次加密，然後把加密的內容傳送給Bob。Bob收到信後，再用自己的私鑰解開信的內容。

說明：這其實是電腦保安學裡加密的概念，加密的目的是為了不讓別人看到傳送的內容，加密的手段是通過一定的加密演算法及約定的金鑰進行的（比如上述用了非對稱加密演算法以及Bob的公鑰），而解密則需要相關的解密演算法及約定的祕鑰（如上述用了非對稱加密演算法和Bob自己的私鑰），可以看出加密是可逆的（可解密的）。

4、Bob看完信後，決定給Susan回一封信。為了防止信的內容被篡改（或者別人偽裝成他的身份跟Susan通訊），他決定先對信的內容用hash演算法做一次處理，得到一個字串雜湊值，Bob又用自己的私鑰對雜湊值做了一次加密得到一個簽名，然後把簽名和信（明文的）一起傳送給Susan。

說明：Bob的內容實質是明文傳輸的，所以這個過程是可以被人截獲和窺探的，但是Bob不擔心被人窺探，他擔心的是內容被人篡改或者有人冒充自己跟Susan通訊。這裡其實涉及到了電腦保安學中的認證概念，Bob要向Susan證明通訊的對方是Bob本人，另外也需要確保自己的內容是完整的。

5、Susan接收到了Bob的信，首先用Bob給的公鑰對簽名作了解密處理，得到了雜湊值A，然後Susan用了同樣的Hash演算法對信的內容作了一次雜湊處理，得到另外一個雜湊值B，對比A和B，如果這兩個值是相同的，那麼可以確認信就是Bob本人寫的，並且內容沒有被篡改過。

說明：4跟5其實構成了一次完整的通過數字簽名進行認證的過程。數字簽名的過程簡述為：傳送方通過不可逆演算法對內容text1進行處理（雜湊），得到的結果值hash1，然後用私鑰加密hash1得到結果值encry1。對方接收text1和encry1，用公鑰解密encry1得到hash1，然後用text1進行同等的不可逆處理得到hash2，對hash1和hash2進行對比即可認證傳送方。

6、此時，另外一種比較複雜出現了，Bob是通過網路把公鑰寄送給他的三個好朋友的，有一個不懷好意的傢伙Jerry截獲了Bob給Doug的公鑰。Jerry開始偽裝成Bob跟Doug通訊，Doug感覺通訊的物件不像是Bob，但是他又無法確認。

7、Bob最終發現了自己的公鑰被Jerry截獲了，他感覺自己的公鑰通過網路傳輸給自己的小夥伴似乎也是不安全的，不懷好意的傢伙可以截獲這個明文傳輸的公鑰。為此他想到了去第三方權威機構“證書中心”（certificate authority，簡稱CA）做認證。證書中心用自己的私鑰對Bob的公鑰和其它資訊做了一次加密。這樣Bob通過網路將數字證書傳遞給他的小夥伴後，小夥伴們先用CA給的公鑰解密證書，這樣就可以安全獲取Bob的公鑰了。

相關推薦