web安全策略
web安全對iOS開發者來說重要嗎？重要！APP中通常會使用很多web頁面，例如廣告、登錄流程、閃屏，或者需要使用跨平臺功能的時候。你可能在頁面中僅僅一部分使用web，也可以整個頁面都是webView,甚至做一個web app。因此web安全對於app來說非常重要。
來自web的安全攻擊有以下幾種：
- 跨域攻擊
- 預測執行攻擊
- 窗口控制攻擊
本文將針對這三種攻擊類型，給出安全防禦措施。
安全傳輸
網絡傳輸相信大家都很熟悉了，安全的傳輸能夠保證接收到的數據來自可信任的站點，並且在傳輸工程中不會被篡改。安全傳輸是其它安全措施的基礎，採取的措施包括：
- HTTPS和WSS（webSocket Secure）
- Http Strict Transport Security（HSTS）遵循HTTPS安全協議的web只能訪問同樣遵循HTTPS安全協議的內容，不能訪問遵循HTTP不安全協議的內容。
- Upgrade-Insecure-Requests 請求頭中添加這一項表示web支持更加安全的升級機制，服務器可以重定向到這個站點的安全版本。
- 使用cookie確保安全，cookie只能被安全的傳輸，例如千萬不要把cookie放到粘貼板上
- 在app的info.plist文件中
Allow Arbitrary Loads in Web Content 這個開關一定要置為 NO！
跨域封鎖
web的內容可以來自任何站點，例如，webView上的一張圖片可以來自任何服務器，也可以從任意服務器上加載一個腳本或iframe。需要注意的是要當心來自其它服務器的資源。跨域的保護已經有20多年的歷史，並且形成了基本原則--同源策略：只有和頁面來源相同的腳本才會被該頁面執行。例如iframe來自不同的域名，同源策略不允許加載這個iframe。僅僅靠同源策略還是不夠的，還需要採取其它的防禦措施。
1. Subresource Integrity
服務器可能會發生異常導致下發錯誤的資源使得web發生crash，但是開發者通常是知道所要請求哪個資源的，在腳本里面增加一個檢查簽名。如果簽名匹配則認為是下發了正確的資源，如果不匹配仍然可以正常工作，此時嘗試從頁面的資源裡查找或者從自己的服務器重新加載。這樣做雖然降低了性能，但是提升了安全性。
window.framwork || // reload from own domain
2. Content Security Policy
HTTP response：:status:200Content-Security-Policy: default 'self'; // No inline script-src cdn.example; frame-src social.example; frame-ancestors news.example;
HTTP response的Header裡面，default設置成自己，默認只能加載同源的資源；script-src和frame-src 分別指定可信任的腳本和iframe的來源；frame-ancestor設置成news.example，指定只有news.example可以iframe我們的web。
另外不使用inline屬性的腳本也是一種防禦措施，不使用inline腳本，只從文件加載腳本，這麼做分離了邏輯和文件，更加安全。
3. HttpOnly cookies
HTTPOnly cookies作為一種安全措施，已經有至少15年的使用歷史。在這之前script通過document.cookie這個強大的api能拿到文檔的cookie，留下安全隱患。HTTPOnly cookies能夠阻止這種情況，只允許HTTP請求訪問cookie，禁止使用script訪問cookie。它的使用方式很簡單，只需要在HTTP response的Header裡面加上HttpOnly這一項，如下
HTTP response：:status:200Set-Cookie: auth = abc...123; HttpOnly;
4. SameSite cookies
在HTTP response的Header裡面將SameSite cookies這一項設置為Strict，那麼將不允許把cookie從一個域名發送到另一個域名。例如其他人的web裡面嵌入了我們的web，如果我們的服務器HTTP response的Header裡面SameSite cookies =
Strict，那麼其他人將無法使用他的cookie來訪問我們的服務器。HTTP response：:status:200Set-Cookie: auth = abc...123; HttpOnly; SameSite=strict
5. Cross-Origin-Resource-Policy
Cross-Origin-Resource-Policy是推出的新功能。之前web可以加載任意web中的資源，例如圖片或者script。在HTTP response的Header裡面將Cross-Origin-Resource-Policy這一項設置為Same，將不允許別人的web向我們的服務器請求圖片或者script，但是我們自己的web可以。
HTTP response：:status:200Cross-Origin-Resource-Policy:Same
6. Cross-Origin-Window-Policy
Cross-Origin-Window-Policy也是新推出的功能。之前通過window.open這個強大的api，其他人的web可以在新窗口中打開我們域名下的web，通過一些手段可以修改我們的web，導航到攻擊者指定的頁面。在HTTP response的Header裡面將Cross-Origin-Resource-Policy這一項設置為Deny，將阻止其他人修改我們web中的內容，當然別人仍然還是可以打開我們的web。Cross-Origin-Resource-Policy適用於希望使用post message 進行窗口間通信，但是不想讓別人控制我們自己web內容的情況。
HTTP response：:status:200Cross-Origin-Window-Policy:Deny
常見的web攻擊及防禦手段
Cross-Origin Attacks
- Cross-Site Scripting
- Compromised CDN
- Cross-Site Request Forgeries
Cross-Site Scripting
例如我們的web裡面有一個文本框，用戶可以輸入文字，如下圖。假如攻擊者注入了這麼一段腳本，如果沒有采取防禦措施，那麼我們web的cookie就會被盜取。
在HTTP response的Header中添加HTTPOnly這一項，就能阻止腳本訪問文檔的cookie，從而防禦跨域腳本攻擊。
另外一種防禦手段是Content-Security-Policy，如下
HTTP response：:status:200Content-Security-Policy: default-src 'self'; // No inline
Content-Security-Policy能保證拒絕加載外部來源的腳本，並且不使用inline屬性的腳本，只從文件中加載腳本。
Compromised CDN
例如我們的web需要從某個外部資源裝載一個framework，攻擊者可能攔截這個請求，並把它重定向到自己的攻擊腳本上，如下圖
使用Content-Security-Policy中script-src這個屬性可以指定信任的腳本來源，並且在引用資源的時候指定來源和校驗簽名，如下
在HTTP response中：
HTTP response：:status:200Content-Security-Policy: default-src 'self'; script-src cdn.example;
在HTML中：
window.framwork || // reload from own domain
3. Cross-Site Request Forgeries
攻擊者可能在自己的web中嵌入我們的web，然後向我們的服務器發起一個偽造的網絡請求（使用的是攻擊者網站的cookie），如下圖
如果採取了防禦措施，將HTTP response的Header裡面的SameSite設置為strict，那麼就會禁止攻擊者網站的cookie發動到我們的服務器上面，如下
HTTP response：:status:200Set-Cookie: auth=abc...123; SameSite=strict
2. Speculative execution attacks (Spectre)
防禦措施有：
- WKWebView
- Content Security Policy
- HttpOnly cookies
- SameSite cookies
- Cross-Origin-Resource-Policy
Speculative execution 的定義：預測執行類似於批量執行條件判斷語句，例如計算機大量執行"x是否會造成數組array越界"這條指令，就能推測出這個數組的長度，進一步推測出這個數組在內存緩衝區中的地址邊界。利用緩衝區溢出這種攻擊手段，可以向web中注入攻擊腳本。當x超過數組邊界的時候，本來應該執行越界的error回調，但是確取出了攻擊腳本並執行，造成數據洩露。顯然只靠同源策略是無法防禦這種攻擊的，因為攻擊腳本和文檔處在同一個域名下，並且在同一個線程中。
防禦預測執行攻擊的方法是確保web內容和其他iframe（例如攻擊腳本）處在不同的線程中。
WKWebView
以Safari app為例，WKWebView會單獨分離出一個NetWork線程用於處理添加cookie等邏輯，而且每個網頁處在不同的線程當中，所以evil網頁是無法通過預測執行攻擊手段攻擊我們的頁面。而且因為NetWork線程也是獨立的，所以evil網頁也無法通過預測執行攻擊手段拿到重要數據，例如cookie。
如果使用UIWebView，所有的web包括NetWork線程都在app的同一個線程中，所以是無法防禦預測執行攻擊手段的。
Content security policy
Content security policy的封鎖功能是處於Network線程中，和web線程是分離的，因此可以防禦預測執行攻擊手段。
例如web要加載一個廣告iframe，但是這個廣告iframe被重定向到了一個攻擊腳本，如果使用了Content security policy，如下，因為攻擊腳本不在信任的frame-src裡面，所以會禁止加載。還有一種情況，攻擊者的web引入了我們的web，因為設置了frame-ancestors為none，所以會禁止攻擊者網站引入我們的web，從而防禦攻擊。
HTTP response：:status:200Content-Security-Policy: default-src 'self'; frame-src ad.example social.example frame-ancestors 'none'
HttpOnly cookies 和 SameSite cookies
HttpOnly cookies 和 SameSite cookies的封鎖功能也是處於Network線程中，和web線程是分離的，因此可以防禦預測執行攻擊手段。
HttpOnly cookies能夠禁止攻擊者通過腳本拿到cookie。SameSite cookies設為strict能夠禁止cookie從一個域發送到另一個域。Cross-Origin-Resource-Policy
Cross-Origin-Resource-Policy的封鎖功能也是處於Network線程中，和web線程是分離的，因此可以防禦預測執行攻擊手段。Cross-Origin-Resource-Policy設置成Same能禁止攻擊者的web加載我們網站的資源。
Window Control Attacks
Cross-Origin-Window-Policy
攻擊者的頁面可以通過window.open這個api在新的窗口打開我們的web，攻擊者趁我們不注意的時候，把我們的頁面導航到釣魚頁面，然後誘導用戶填寫用戶名和密碼，這樣就竊取到了用戶信息。把HTTP response Header裡面的Cross-Origin-Window-Policy設置為Deny，能夠禁止攻擊者修改我們的web，這樣攻擊者就無法導航到釣魚頁面。
總結
每種安全措施防禦的攻擊類型
建議
- 使用安全的網絡傳輸（例如https，wss）
- 設置Cookies為HttpOnly和其它安全選項
- 把UIWebView升級到WKWebView
- 測試防禦措施是否生效，web是否仍然能正常工作。安全措施都具有一定的限制功能，因此測試web是否能正常工作非常重要。例如Content-Securityp-Policy的script-src白名單裡少些了一個允許的域名，那麼這個域名下的web就無法正常使用了。
閱讀更多 今日頭條技術團隊 的文章
