「譯」Web安全快速入門

Web安全快速入門

──幾個Web開發人員必知的安全縮略語

原文：A quick introduction to web security

做者：Austin Tackaberry 發表時間：2018/8/15

譯者：陳 昌茂 發表時間：2018/8/25

(轉載請註明出處)

你有不少理由須要瞭解Web安全，好比：

• 你是一位關心我的隱私數據正被泄露的用戶
• 你是一名Web開發人員，想要編寫更加安全的Web應用
• 你是一位正在應聘Web開發崗位，準備面試有關Web安全問題。
• 諸如此類～

本文將通俗易懂的準確地解釋一些經常使用的Web安全縮略語。

在此以前，咱們要了解兩種模式，分別表明着兩個極端，但又同屬一個觀念層次。

安全的兩個模式

一種模式是追求絕對安全，結果不管如何努力也達不到絕對安全，而弄得本身痛苦不堪。

另外一種是在採起了必定的防禦措施後，便知足地認爲已達到絕對安全，因而放鬆警戒，最後遭受安全威脅的攻擊，損失慘重。

你不能就說：

喔，由於實現了CSP，因此我是安全的。我能夠在漏洞清單中劃掉跨站腳本，由於它不會發生。

你會發現本身和其餘人同樣，也是按這種方式思考的。顯而易見，程序員們很容易按這種方式思考：非黑即白，非0即1，非對即錯。其實，安全遠沒有這麼簡單。

咱們在Web開發工做中初期就遇到會這些問題，並嘗試從StackOverflow社區中能找到解決方案。

跨源資源共享（CORS）

你是否見到相似下面的錯誤信息？

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
複製代碼

你不是一我的在戰鬥，你Google查詢，有人說用這個方法，全部問題立刻解決。

太好了，不是嗎？

CORS是來保護你而不是傷害你的

爲了解釋CORS是如何幫助你的，讓咱們先從cookie提及，特別是認證cookie。認證cookie是用來告訴後臺程序你的登陸狀態，它們自動隨任何請求發送給後臺程序。

咱們來假設：你已經登陸了Facebook帳戶，且Facebook使用cookie認證。你點擊連接bit.ly/r43nugi，它重定向到惡意網站 superevilwebsite.rocks。惡意網站 superevilwebsite.rocks中的一段腳本代碼向facebook.com 後臺程序發起請求，你的認證cookie自動隨請求發送給facebook.com 後臺程序。

在非CORS的世界，黑客能夠在你絕不知情的狀況下變動你的帳戶。只須要簡單幾步：一、黑客在你的時間線上發帖，帖子中包含bit.ly/r43nugi 惡意連接；二、你的朋友們點擊了該惡意連接，惡意腳本程序又在他們的時間線上發帖，這個過程不斷被重複，在廣度優先模式下，直到黑客佔領了所有的Facebook用戶的時間線，世界充斥着惡意網站 superevilwebsite.rocks。 😆

然而在CORS的世界，Facebook將只容許來源自facebook.com的請求方可在後臺程序中修改數據。換句話說，他們會限制跨源資源共享。你可能會問：

咱們能夠修改請求文件頭，這樣請求不就看起來是來自facebook.com嗎？

你能夠試試，但不會成功的，由於瀏覽器會忽略你的修改，它會使用真正的來源信息。

好了，那若是惡意網站修改後臺程序的請求呢？

在這種狀況下，你想繞過CORS，但你仍是不會得逞，緣由後臺程序不能同時發送你的認證cookie。腳本必須在瀏覽器上執行才能獲取到你存在瀏覽器上的cookie。

內容安全策略（CSP）

爲了便於理解CSP，咱們先談一下最多見的Web漏洞：跨站腳本攻擊（簡稱：XSS）

XSS即黑客在你的瀏覽器中注入JavaScript代碼。你可能會想：

黑客會作什麼，紅變綠嗎？

咱們假如黑客在你的瀏覽器成功中注入JavaScript代碼到你正在訪問的網站代碼中。

他們可能會作哪些邪惡的事情？

• 他們能冒充你向其餘網站發送HTTP請求。
• （這句不會翻，囧）
• 他們能加script標籤，內嵌的一段JavaScript代碼。
• 他們能加script標籤，引用遠程的JavaScript代碼。
• 他們能內嵌一個網頁覆蓋正常網頁之上，提示你輸入密碼。
• 罄竹難書，發揮你的想象力吧。

CSP經過限制功能提供保護：

• 什麼能在框架內打開。
• 什麼樣式表能夠被加載。
• 哪些請求能夠發送，等等。

那它時怎麼工做的呢？

等你點擊連接或在瀏覽器地址欄輸入網址的時候，瀏覽器發送GET請求。服務器返回HTTP頭信息以及HTML內容。若是你對返回頭信息是什麼很好奇，（以谷歌Chrome瀏覽器爲例，打開瀏覽器開發者模式。括弧內爲譯者補充，下同）切換到「網絡」標籤，訪問網站facebook.com。

你可能會看到以下返回頭信息：

content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
複製代碼

這些是facebook.com的安全內容策略。讓咱們調整成可讀性強的格式。

content-security-policy:
default-src * data: blob:;
script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';
style-src data: blob: 'unsafe-inline' *;
connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
複製代碼

如今，咱們逐條分解這些指令。

• **default-src** 限制全部其餘沒有顯示列出的CSP指令。
• **script-src** 限制腳本加載。
• **style-src** 限制樣式表加載。
• **connect-src** 限制可使用腳本接口（如獲取、XHR、ajax等）的URL連接。

注意遠不止這3條指令，還有更多的CSP指令。瀏覽器將讀取CSP頭信息並加載、渲染HTML文件時執行這些指令。若是恰當地設置指令，瀏覽器將僅容許必要的操做。

若是沒有CSP頭信息，那麼全部的操做都不會被限制。你能夠想象這些指令所有替換成通配符*，任何操做都將被容許。

HTTPS 或 HTTP安全

你確定據說過HTTPS。人們可能會這麼說：

爲什麼我要關心一個我玩遊戲的網站是否啓用了HTTPS呢？

或者是這樣滴。。。

太瘋狂了，你的網站竟然沒有啓用HTTPS。都2018年了，別信其餘人（潛臺詞：必須啓用HTTPS）。

或許你據說谷歌Chrome瀏覽器（自7月24日發佈的Chrome 68起）將把全部HTTP網站標記「不安全「。

重點是，HTTPS是加密的而HTTP不是。

若是你不發送敏感信息，（是否加密）有那麼重要嗎？

準備下一個縮寫MITM，它表明中間人攻擊。

若是你在咖啡館使用無密碼的公共Wi-Fi，任何人都很容易地冒充成路由器，使所有的請求和返回都經過該路由器。若是你的數據沒有加密，那麼他們能夠作任何事。好比在HTML, CSS, 或 JavaScript到達你的瀏覽器以前修改。假如你已經知道XSS，那麼能夠作什麼樣的壞事。

那麼怎樣才能夠實現個人電腦和服務器之間通訊加密而不被中間人攻擊呢？

最初SSL協議就是爲了解決這個問題而設計的，1999年，TLS協議取代SSL協議用在HTTPS上。至於TLS如何工做已經超出本文範圍。

HSTS協議

讓咱們還用Facebook的頭信息爲例，如下是一條很簡潔的指令。

strict-transport-security: max-age=15552000; preload
複製代碼

• max-age 標明HSTS在瀏覽器的生效時間。
• preload 對本文不重要。

這個頭信息僅在用HTTPS訪問時生效，在用HTTP訪問時會被忽略。緣由很簡單，HTTPS時如此不安全，很難被信任。

讓咱們用Facebook的例子來描述下。你首次訪問facebook.com，並且知道HTTPS比HTTP安全，因此你使用https://facebook.com。當瀏覽器接收到HTML，收到頭信息，告知瀏覽器在後續訪問中強制重定向到HTTPS網站。一個月後，有人經過HTTP給你發送一個Facebook的連接，好比http://facebook.com，在max-age時間範圍內，瀏覽器會強制使用HTTPS，防止潛在的中間人攻擊。

結論

不管你在Web開發旅程中的什麼時候何地Web安全都很重要。你越重視它，安全威脅離你越遠。安全時對每一個人都很重要的事情，而不只是對於工做中。👮