摘要 web前端安全方面技術含有的東西較多，這里就來理一理web安全方面所涉及的一些問題
摘要 web前端安全方面技術含有的東西較多，這里就來理一理web安全方面所涉及的一些問題
原文鏈接：http://ouvens.github.io/frontend-weboptimize/2016/03/20/web-security-and-https.html
web安全方面技術含有的東西較多，這里就來理一理web安全方面所涉及的一些問題。
一、xss與sql攻擊
入門級的安全知識，攻擊手段和防范方法這里略過，不過注意的是xss分存儲型xss、反射型xss、mxss，主要防范思路是檢查驗證要輸入到頁面上的內容是否安全。
二、csrf
入門級的安全知識，攻擊手段和防范方法這里略過
三、請求劫持與HTTPS
3.1、請求劫持
請求劫持現在主要分為兩種，DNS劫持與HTTP劫持：
DNS劫持：
DNS劫持就是通過劫持了DNS服務器，通過某些手段取得某域名的解析記錄控制權，進而修改此域名的解析結果，導致對該域名的訪問由原IP地址轉入到修改后的指定IP，其結果就是對特定的網址不能訪問或訪問的是假網址，從而實現竊取資料或者破壞原有正常服務的目的。DNS劫持通過篡改DNS服務器上的數據返回給用戶一個錯誤的查詢結果來實現的。 DNS劫持症狀：在某些地區的用戶在成功連接寬帶后，首次打開任何頁面都指向ISP提供的“電信互聯星空”、“網通黃頁廣告”等內容頁面。還有就是曾經出現過用戶訪問Google域名的時候出現了百度的網站。這些都屬於DNS劫持。 再說簡單點，當你輸入google.com這個網址的時候，你看到的網站卻是百度的首頁。
http劫持：
在用戶的客戶端與其要訪問的服務器經過網絡協議協調后，二者之間建立了一條專用的數據通道，用戶端程序在系統中開放指定網絡端口用於接收數據報文，服務器端將全部數據按指定網絡協議規則進行分解打包，形成連續數據報文。 用戶端接收到全部報文后，按照協議標准來解包組合獲得完整的網絡數據。其中傳輸過程中的每一個數據包都有特定的標簽，表示其來源、攜帶的數據屬性以及要到何處，所有的數據包經過網絡路徑中ISP的路由器傳輸接力后，最終到達目的地，也就是客戶端。 HTTP劫持是在使用者與其目的網絡服務所建立的專用數據通道中，監視特定數據信息，提示當滿足設定的條件時，就會在正常的數據流中插入精心設計的網絡數據報文，目的是讓用戶端程序解釋“錯誤”的數據，並以彈出新窗口的形式在使用者界面展示宣傳性廣告或者直接顯示某網站的內容。列入本地的fiddler為一種劫持
請求劫持唯一可行的預防方法就是盡量使用HTTPS協議訪問。
3.1、公鑰和私鑰
什么是https，這里不再解釋了，簡單理解就是通過SSL（Secure Sockets Layer）層來加密http數據來進行安全傳輸。 那使用HTTPS是怎樣進行安全數據傳輸的？
先看個有意思的問題：
A、B兩個人分別在兩個島上，並且分別有一個箱子，一把鎖，和打開這把鎖的鑰匙（A的鑰匙打不開B手上的鎖，B的鑰匙也打不開A的鎖）。此時A要跟B互通情報，此時需要借助C的船運輸，C是一個不可靠的人，如果A直接把情報送給B或把情報放在箱子里給B，都可能會被C偷走；如果A把情報鎖在箱子里，B沒有打開A鎖的鑰匙無法獲得情報內容。請問有什么辦法可以盡可能快的讓A和B互通情報。
這就是公鑰和私鑰的問題了，答案比較簡單，也對應了公鑰和私鑰在https中的應用過程。
公鑰（Public Key）與私鑰（Private Key）是通過一種算法得到的一個密鑰對（即一個公鑰和一個私鑰），公鑰是密鑰對中公開的部分，私鑰則是非公開的部分。公鑰通常用於加密會話密鑰、驗證數字簽名，或加密可以用相應的私鑰解密的數據。通過這種算法得到的密鑰對能保證在世界范圍內是唯一的。使用這個密鑰對的時候，如果用其中一個密鑰加密一段數據，必須用另一個密鑰解密。比如用公鑰加密數據就必須用私鑰解密，如果用私鑰加密也必須用公鑰解密，否則解密將不會成功。---百度百科
3.2、Https的通信過程
整個通信過程如下圖，以公鑰加密方式為例：
1、客戶端發送https請求，告訴服務器發將建立https連接 2、服務器將服務端生成的公鑰返回給客戶端，如果是第一次請求將告訴客戶端需要驗證鏈接 3、客戶端接收到請求后'client finished'報文串通過獲取到的服務器公鑰加密發送給服務器，並將客戶端生成的公鑰也發送給服務器 4、服務器獲取到加密的報文和客戶端公鑰，先使用服務器私鑰解密報文，然后將報文通過客戶端的公鑰加密返回給客戶端。 5、客戶端通過私鑰解密報文，判斷是否為自己開始發送的報文串；如果正確，說明安全連接驗證成功，將數據通過服務器公鑰加密不斷發送給服務器，服務器也不斷解密獲取報文，並通過客戶端公鑰加密返回給客戶端驗證。這樣就建立了不斷通信的連接。
3.3、Https協議頭解析
以打開 https://github.com/ 的過程為例，請求通用頭部如下
Request URL:https://github.com/ouvens\n Request Method:GET Status Code:200 OK (from cache) Remote Address:192.30.252.131:443 Response Headers
先看下請求頭的字段
再截取部分返回頭的字段
需要注意的upgrade-insecure-requests
https正常升級后chrome瀏覽器會出現下面的警告
考慮到這個問題，w3c在2015年4月份出了一個 Upgrade Insecure Requests 的草案，他的作用就是讓瀏覽器自動升級請求。在服務器的響應頭中加入：
header("Content-Security-Policy: upgrade-insecure-requests");
四、其它瀏覽器web安全控制
http層面上瀏覽器設置的安全性控制較多，這里列幾個典型的來看看：
1. X-XSS-Protection
這個header主要是用來防止瀏覽器中的反射性xss。現在，只有IE，chrome和safari（webkit）支持這個header。
正確的設置:
X-XSS-Protection:1; mode=block 0 – 關閉對瀏覽器的xss防護 1 – 開啟xss防護 1; mode=block – 開啟xss防護並通知瀏覽器阻止而不是過濾用戶注入的腳本。 1; report=http://site.com/report – 這個只有chrome和webkit內核的瀏覽器支持，這種模式告訴瀏覽器當發現疑似xss攻擊的時候就將這部分數據post到指定地址。 通常不正確的設置
2.X-Content-Type-Options
&ems; 這個header主要用來防止在IE9、chrome和safari中的MIME類型混淆攻擊。firefox目前對此還存在爭議。通常瀏覽器可以通過嗅探內容本身的方法來決定它是什么類型，而不是看響應中的content-type值。通過設置 X-Content-Type-Options：如果content-type和期望的類型匹配，則不需要嗅探，只能從外部加載確定類型的資源。舉個例子，如果加載了一個樣式表，那么資源的MIME類型只能是text/css，對於IE中的腳本資源，以下的內容類型是有效的：
application/ecmascript application/javascript application/x-javascript text/ecmascript text/javascript text/jscript text/x-javascript text/vbs text/vbscript
對於chrome，則支持下面的MIME 類型：
text/javascript text/ecmascript application/javascript application/ecmascript application/x-javascript text/javascript1.1 text/javascript1.2 text/javascript1.3 text/jscript text/live script
nosniff – 這個是唯一正確的設置，必須這樣。
3. Strict-Transport-Security
Strict Transport Security (STS) 是用來配置瀏覽器和服務器之間安全的通信。它主要是用來防止中間人攻擊，因為它強制所有的通信都走TLS。目前IE還不支持 STS頭。需要注意的是，在普通的http請求中配置STS是沒有作用的，因為攻擊者很容易就能更改這些值。為了防止這樣的現象發生，很多瀏覽器內置了一個配置了STS的站點list。
正確的設置 : 注意下面的值必須在https中才有效，如果是在http中配置會沒有效果。
max-age=31536000 – 告訴瀏覽器將域名緩存到STS list里面，時間是一年。 max-age=31536000; includeSubDomains – 告訴瀏覽器將域名緩存到STS list里面並且包含所有的子域名，時間是一年。 max-age=0 – 告訴瀏覽器移除在STS緩存里的域名，或者不保存此域名。 通常不正確的設置
判斷一個主機是否在你的STS緩存中，chrome可以通過訪問chrome://net-internals/#hsts，首先，通過域名請求選項來確認此域名是否在你的STS緩存中。然后，通過https訪問這個網站，嘗試再次請求返回的STS頭，來決定是否添加正確。
4.Content-Security-Policy
CSP是一種由開發者定義的安全性政策性申明，通過CSP所約束的的規責指定可信的內容來源（這里的內容可以指腳本、圖片、iframe、fton、style等等可能的遠程的資源）。通過CSP協定，讓WEB能夠加載指定安全域名下的資源文件，保證運行時處於一個安全的運行環境中。
正確配置：
Content-Security-Policy:default-src *; base-uri 'self'; block-all-mixed-content; child-src 'self' render.githubusercontent.com; connect-src 'self' uploads.github.com status.github.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com wss://live.github.com; font-src assets-cdn.github.com; form-action 'self' github.com gist.github.com; frame-src 'self' render.githubusercontent.com; img-src 'self' data: assets-cdn.github.com identicons.github.com www.google-analytics.com collector.githubapp.com *.gravatar.com *.wp.com *.githubusercontent.com; media-src 'none'; object-src assets-cdn.github.com; plugin-types application/x-shockwave-flash; script-src assets-cdn.github.com; style-src 'self' 'unsafe-inline' assets-cdn.github.com
5.X-Frame-Options
這個header主要用來配置哪些網站可以通過frame來加載資源。它主要是用來防止UI redressing 補償樣式攻擊。IE8和firefox 18以后的版本都開始支持ALLOW-FROM。chrome和safari都不支持ALLOW-FROM，但是WebKit已經在研究這個了。
正確的設置
X-Frame-Options: deny deny – 禁止所有的資源（本地或遠程）試圖通過frame來加載其他也支持X-Frame-Options 的資源。 sameorigion – 只允許遵守同源策略的資源（和站點同源）通過frame加載那些受保護的資源。 allow-from http://www.example.com – 允許指定的資源（必須帶上協議http或者https）通過frame來加載受保護的資源。這個配置只在IE和firefox下面有效。其他瀏覽器則默認允許任何源的資源（在X-Frame-Options沒設置的情況下）。
6.Access-Control-Allow-Origin
Access-Control-Allow-Origin是從Cross Origin Resource Sharing (CORS)中分離出來的。這個header是決定哪些網站可以訪問資源，通過定義一個通配符來決定是單一的網站還是所有網站可以訪問我們的資源。需要注意的是，如果定義了通配符，那么 Access-Control-Allow-Credentials選項就無效了，而且user-agent的cookies不會在請求里發送。
正確的設置
Access-Control-Allow-Origin : * *– 通配符允許任何遠程資源來訪問含有Access-Control-Allow-Origin 的內容。 http://www.example.com – 只允許特定站點才能訪問(http://[host], 或者 https://[host])
7.Public-Key-Pins
公鑰固定（Public Key Pinning）是指一個證書鏈中必須包含一個白名單中的公鑰，也就是說只有被列入白名單的證書簽發機構（CA）才能為某個域名*.example.com簽發證書，而不是你的瀏覽器中所存儲的任何 CA 都可以為之簽發。可以理解為https的證書域名白名單。 Public-Key-Pins (PKP)的目的主要是允許網站經營者提供一個哈希過的公共密鑰存儲在用戶的瀏覽器緩存里。跟Strict-Transport-Security功能相似的是，它能保護用戶免遭中間人攻擊。這個header可能包含多層的哈希運算，比如pin-sha256=base64(sha256(SPKI))，具體是先將 X.509 證書下的Subject Public Key Info (SPKI) 做sha256哈希運算，然后再做base64編碼。然而，這些規定有可能更改，例如有人指出，在引號中封裝哈希是無效的，而且在33版本的chrome中也不會保存pkp的哈希到緩存中。
這個header和 STS的作用很像，因為它規定了最大子域名的數量。此外，pkp還提供了一個Public-Key-Pins-Report-Only 頭用來報告異常，但是不會強制阻塞證書信息。當然，這些chrome都是不支持的。
請求頭說明參考：
https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers/
五、總結
總結下web的安全策略，主要介紹了websql注入防范、xss防范、csrf防范、劫持與https、Content-Security-Policy、Strict-Transport-Security、Access-Control-Allow-Origin、X-Frame-Options等。
參考文章
https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html
https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers/
https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html
https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers/
原文鏈接：http://ouvens.github.io/frontend-weboptimize/2016/03/20/web-security-and-https.html