整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
web安全對iOS開發者來說重要嗎？重要！APP中通常會使用很多web頁面，例如廣告、登錄流程、閃屏，或者需要使用跨平臺功能的時候。你可能在頁面中僅僅一部分使用web，也可以整個頁面都是webView,甚至做一個web app。因此web安全對于app來說非常重要。
來自web的安全攻擊有以下幾種：
本文將針對這三種攻擊類型，給出安全防御措施。
網絡傳輸相信大家都很熟悉了，安全的傳輸能夠保證接收到的數據來自可信任的站點，并且在傳輸工程中不會被篡改。安全傳輸是其它安全措施的基礎，采取的措施包括：
Allow Arbitrary Loads in Web Content 這個開關一定要置為 NO！
web的內容可以來自任何站點，例如，webView上的一張圖片可以來自任何服務器，也可以從任意服務器上加載一個腳本或iframe。需要注意的是要當心來自其它服務器的資源。跨域的保護已經有20多年的歷史，并且形成了基本原則--同源策略：只有和頁面來源相同的腳本才會被該頁面執行。例如iframe來自不同的域名，同源策略不允許加載這個iframe。僅僅靠同源策略還是不夠的，還需要采取其它的防御措施。
服務器可能會發生異常導致下發錯誤的資源使得web發生crash，但是開發者通常是知道所要請求哪個資源的，在腳本里面增加一個檢查簽名。如果簽名匹配則認為是下發了正確的資源，如果不匹配仍然可以正常工作，此時嘗試從頁面的資源里查找或者從自己的服務器重新加載。這樣做雖然降低了性能，但是提升了安全性。
<script src="https://cdn.example/framework.js" integrity="sha256-8WqyJLuWKRB...oZkCnxQbWwJVw="> </script> window.framwork || // reload from own domain
HTTP response： :status:200 Content-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腳本，只從文件加載腳本，這么做分離了邏輯和文件，更加安全。
HTTPOnly cookies作為一種安全措施，已經有至少15年的使用歷史。在這之前script通過document.cookie這個強大的api能拿到文檔的cookie，留下安全隱患。HTTPOnly cookies能夠阻止這種情況，只允許HTTP請求訪問cookie，禁止使用script訪問cookie。它的使用方式很簡單，只需要在HTTP response的Header里面加上HttpOnly這一項，如下
HTTP response： :status:200 Set-Cookie: auth = abc...123; HttpOnly;
在HTTP response的Header里面將SameSite cookies這一項設置為Strict，那么將不允許把cookie從一個域名發送到另一個域名。例如其他人的web里面嵌入了我們的web，如果我們的服務器HTTP response的Header里面SameSite cookies = Strict，那么其他人將無法使用他的cookie來訪問我們的服務器。
HTTP response： :status:200 Set-Cookie: auth = abc...123; HttpOnly; SameSite=strict
Cross-Origin-Resource-Policy是推出的新功能。之前web可以加載任意web中的資源，例如圖片或者script。在HTTP response的Header里面將Cross-Origin-Resource-Policy這一項設置為Same，將不允許別人的web向我們的服務器請求圖片或者script，但是我們自己的web可以。
HTTP response： :status:200 Cross-Origin-Resource-Policy:Same
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:200 Cross-Origin-Window-Policy:Deny
Cross-Origin Attacks
Cross-Site Scripting
例如我們的web里面有一個文本框，用戶可以輸入文字，如下圖。假如攻擊者注入了這么一段腳本，如果沒有采取防御措施，那么我們web的cookie就會被盜取。
在HTTP response的Header中添加HTTPOnly這一項，就能阻止腳本訪問文檔的cookie，從而防御跨域腳本攻擊。
另外一種防御手段是Content-Security-Policy，如下
HTTP response： :status:200 Content-Security-Policy: default-src 'self'; // No inline
Content-Security-Policy能保證拒絕加載外部來源的腳本，并且不使用inline屬性的腳本，只從文件中加載腳本。
例如我們的web需要從某個外部資源裝載一個framework，攻擊者可能攔截這個請求，并把它重定向到自己的攻擊腳本上，如下圖
使用Content-Security-Policy中script-src這個屬性可以指定信任的腳本來源，并且在引用資源的時候指定來源和校驗簽名，如下
在HTTP response中：
HTTP response： :status:200 Content-Security-Policy: default-src 'self'; script-src cdn.example;
在HTML中：
<script src="https://cdn.example/framework.js" integrity="sha256-8WqyJLuWKRB...oZkCnxQbWwJVw="> </script> window.framwork || // reload from own domain
攻擊者可能在自己的web中嵌入我們的web，然后向我們的服務器發起一個偽造的網絡請求（使用的是攻擊者網站的cookie），如下圖
如果采取了防御措施，將HTTP response的Header里面的SameSite設置為strict，那么就會禁止攻擊者網站的cookie發動到我們的服務器上面，如下
HTTP response： :status:200 Set-Cookie: auth=abc...123; SameSite=strict
防御措施有：
Speculative execution 的定義：預測執行類似于批量執行條件判斷語句，例如計算機大量執行"x是否會造成數組array越界"這條指令，就能推測出這個數組的長度，進一步推測出這個數組在內存緩沖區中的地址邊界。利用緩沖區溢出這種攻擊手段，可以向web中注入攻擊腳本。當x超過數組邊界的時候，本來應該執行越界的error回調，但是確取出了攻擊腳本并執行，造成數據泄露。顯然只靠同源策略是無法防御這種攻擊的，因為攻擊腳本和文檔處在同一個域名下，并且在同一個線程中。
防御預測執行攻擊的方法是確保web內容和其他iframe（例如攻擊腳本）處在不同的線程中。
以Safari app為例，WKWebView會單獨分離出一個NetWork線程用于處理添加cookie等邏輯，而且每個網頁處在不同的線程當中，所以evil網頁是無法通過預測執行攻擊手段攻擊我們的頁面。而且因為NetWork線程也是獨立的，所以evil網頁也無法通過預測執行攻擊手段拿到重要數據，例如cookie。
如果使用UIWebView，所有的web包括NetWork線程都在app的同一個線程中，所以是無法防御預測執行攻擊手段的。
Content security policy的封鎖功能是處于Network線程中，和web線程是分離的，因此可以防御預測執行攻擊手段。
例如web要加載一個廣告iframe，但是這個廣告iframe被重定向到了一個攻擊腳本，如果使用了Content security policy，如下，因為攻擊腳本不在信任的frame-src里面，所以會禁止加載。還有一種情況，攻擊者的web引入了我們的web，因為設置了frame-ancestors為none，所以會禁止攻擊者網站引入我們的web，從而防御攻擊。
HTTP response： :status:200 Content-Security-Policy: default-src 'self'; frame-src ad.example social.example frame-ancestors 'none'
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，這樣攻擊者就無法導航到釣魚頁面。
總結
每種安全措施防御的攻擊類型
天在調試android webview加載本地html文件時，對三種不同位置html的加載方式總結如下：
1.//打開本包內asset目錄下的index.html文件
wView.loadUrl(" file:///android_asset/index.html ");
2.//打開本地sd卡內的index.html文件
wView.loadUrl("content://com.android.htmlfileprovider/sdcard/index.html");
3.//打開指定URL的html文件
wView.loadUrl(" http://m.oschina.net");
今天就分享這一個知識點，祝大家好運！
017年12月7日，國家信息安全漏洞共享平臺（CNVD）接收到騰訊玄武實驗室報送的Android WebView存在跨域訪問漏洞(CNVD-2017-36682)。攻擊者利用該漏洞，可遠程獲取用戶隱私數據（包括手機應用數據、照片、文檔等敏感信息），還可竊取用戶登錄憑證，在受害者毫無察覺的情況下實現對APP用戶賬戶的完全控制。由于該組件廣泛應用于Android平臺，導致大量APP受影響，構成較為嚴重的攻擊威脅。
一、漏洞情況分析
WebView是Android用于顯示網頁的控件，是一個基于Webkit引擎、展現web頁面的控件。WebView控件功能除了具有一般View的屬性和設置外，還可對URL請求、頁面加載、渲染、頁面交互進行處理。
該漏洞產生的原因是在Android應用中，WebView開啟了file域訪問，且允許file域對http域進行訪問，同時未對file域的路徑進行嚴格限制所致。攻擊者通過URL Scheme的方式，可遠程打開并加載惡意HTML文件，遠程獲取APP中包括用戶登錄憑證在內的所有本地敏感數據。
漏洞觸發成功前提條件如下：
1. WebView中setAllowFileAccessFromFileURLs 或setAllowUniversalAccessFromFileURLs API配置為true；
2. WebView可以直接被外部調用，并能夠加載外部可控的HTML文件。
CNVD對相關漏洞綜合評級為“高危”。
二、漏洞影響范圍
漏洞影響使用WebView控件，開啟file域訪問并且未按安全策略開發的Android應用APP。
三、漏洞修復建議
廠商暫未發布解決方案，臨時解決方案如下：
1. file域訪問為非功能需求時，手動配置setAllowFileAccessFromFileURLs或setAllowUniversalAccessFromFileURLs兩個API為false。（Android 4.1版本之前這兩個API默認是true，需要顯式設置為false）
2. 若需要開啟file域訪問，則設置file路徑的白名單，嚴格控制file域的訪問范圍，具體如下：
（1）固定不變的HTML文件可以放在assets或res目錄下，file:///android_asset和file:///android_res 在不開啟API的情況下也可以訪問；
（2）可能會更新的HTML文件放在/data/data/(app) 目錄下，避免被第三方替換或修改；
（3）對file域請求做白名單限制時，需要對“../../”特殊情況進行處理，避免白名單被繞過。
3. 避免App內部的WebView被不信任的第三方調用。排查內置WebView的Activity是否被導出、必須導出的Activity是否會通過參數傳遞調起內置的WebView等。
4. 建議進一步對APP目錄下的敏感數據進行保護。客戶端APP應用設備相關信息（如IMEI、IMSI、Android_id等）作為密鑰對敏感數據進行加密。使攻擊者難以利用相關漏洞獲得敏感信息。
來源：國家互聯網應急中心
阿勒泰地區網絡舉報
舉報電話：0906-2317252
舉報郵箱：altwljb@163.com
官方微信：阿勒泰網絡舉報（微信號：altwljb）
新疆互聯網違法和不良信息舉報中心
舉報電話：0991-2384777
舉報網址：www.xjwljb.com
舉報郵箱：xjwljb@xjts.cn
官方微博：@新疆網絡舉報
官方微信：新疆網絡舉報（微信號：xjwljb）
中國互聯網違法和不良信息舉報中心
舉報電話：12377
舉報網址：www.12377.cn
舉報郵箱：jubao@12377.cn
官方微博：中國互聯網舉報中心
官方微信：違法和不良信息舉報中心（微信號：jbzx12377）
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
