WebView cross-source attack analysis

WebView cross-source attack analysis

Same-origin policy

The same-origin policy is one of the most important security mechanisms of browsers. It was first proposed by Netscape in 1995 and is followed by mainstream browsers. The same source usually refers to the protocol, domain name, and port are all the same, but the IE browser will ignore the port judgment. RFC 6454 defines an algorithm for calculating the same-source URL. To describe the same-source URL in an image, the following table shows whether the specific URL is the same as http://www.360.cn/weishi/index.html.

The same-origin policy limits javascript to operate only the DOM objects of the same-origin site. Use the following HTML Script to briefly describe the restrictions of the same-source policy on javascript. First, use IFrame to insert www.so.com into a certain HTML, set it to sop.html, and operate the dom object of www.so.com In the javascript of sop.html.

Upload this html file to your site. Assume It is www.yousite.com, and then visit this page. You will get the following security error exception: The following shows the chrome console output, indicates that the preceding access violates the same-source policy.
Uncaught SecurityError: Blocked a frame with origin "http://www.so.com" from accessing a frame with origin "http://www.yoursite.com". Protocols, domains, and ports must match.
Different browsers have different criteria for determining the consistency of the file protocol in different periods. When a javascript script is loaded and executed through a non-file url (such as an http url, file URLs are regarded as non-same-source URLs, which can prevent javascript on the http page from reading local files. When javascript is loaded and executed through a file url, Some browsers allow javascript to access all local files, some use directories as the same-type criteria, and some only allow access to files specified by URLs. Accessing the resources of other protocols in the javascript of file url also has different standards for different browsers in different periods. Some allow requests for http resources through XmlHttpRequest in the file protocol, while others do not.
Ii. file protocol in WebView
We use a simple example and four APIs to understand the security of the file protocol in WebView. The sample code is as follows).
public class WebViewActivity extends Activity {    private WebView webView;    public void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_webview);        webView = (WebView) findViewById(R.id.webView1);        //webView.getSettings().setAllowFileAccess(false);                    (1)        //webView.getSettings().setJavaScriptEnabled(true);                   (2)        //webView.getSettings().setAllowFileAccessFromFileURLs(true);       (3)        //webView.getSettings().setAllowUniversalAccessFromFileURLs(true); (4)        Intent i = getIntent();        String url = i.getData().toString();        webView.loadUrl(url);    } }
WebViewActivity is the exported Activity. When other applications start this Activity, the data in intent is directly loaded as a url. Drozer can easily start WebViewActivity and run the following command. WebViewActivity loads file: // data/local/tmp/attack.html
Dz> run app. activity. start
-Component com. example. webviewtest com. example. webviewtest. WebViewActivity
-Action android. intent. action. VIEW
-Data-uri file: // data/local/tmp/attack.html
Because of the existence of sandbox, Android applications are isolated from each other. Normally, application A cannot access the files of application B, however, improper use of WebView may lead to the risk of application data leakage, that is, application A can load A malicious file protocol url to application B through the Activity exported by application B to obtain the internal private files of application B. We analyze the impact of the four APIs on WebView security.
Through this API, you can set whether to allow WebView to use the File protocol. The default value is allow. If File protocol is not allowed, the following cross-source security threats do not exist, but it also limits the webview function so that it cannot load local html files. After the File protocol is disabled, run the drozer command to obtain the output shown. The file shown in the figure exists, but WebView prohibits File loading. Chrome of mobile version prohibits file protocol File loading by default.
 

2 setJavaScriptEnabled
This API allows you to set whether to allow WebView to use JavaScript. By default, this API is not allowed. However, many apps, including mobile browsers, actively allow WebView to execute javascript in http to allow WebView to execute Javascript, it does not treat different protocols differently. It is safer to enable javascript if the url to be loaded is http or https. If it is another dangerous protocol, such as the file protocol, disable javascript. Disabling file protocol javascript can greatly reduce the threat of cross-source vulnerabilities to WebView. Of course, Disabling javascript Execution of the file protocol does not completely prevent cross-source file leaks. For example, some applications enable the download function. Non-rendered pages are automatically downloaded to the SD card because all files in the SD card can be accessed, therefore, you can construct a file URL to point to the private file of the attacked application, and then start the Activity with this URL to read the private file of the attacked application from the SD card.
3 setAllowFileAccessFromFileURLs
Through this API, you can set whether to allow reading other local files through Javascript loaded by file url. This setting is allowed by default in versions earlier than JELLY_BEAN, JELLY_BEAN and later versions are disabled by default. The following code segment corresponds to attack.html in the drozercommand.
<script>function loadXMLDoc(){    var arm = "file:///etc/hosts";    var xmlhttp;    if (window.XMLHttpRequest)    {        xmlhttp=new XMLHttpRequest();    }    xmlhttp.onreadystatechange=function()    {        //alert("status is"+xmlhttp.status);        if (xmlhttp.readyState==4)        {              console.log(xmlhttp.responseText);        }    }    xmlhttp.open("GET",arm);    xmlhttp.send(null);}loadXMLDoc();</script>
If the value of AllowFileAccessFromFileURLs is true, the above javascript can successfully read the content of/etc/hosts, but is set to false, the above script will cause the following error, indicates that the browser prohibits javascript from reading other local files from the file url.
I/chromium (27749): [INFO: CONSOLE (0)] "XMLHttpRequest cannot load file: // etc/hosts. cross origin requests are only supported for HTTP. ", source: file: // data/local/tmp/attack.html
4 setAllowUniversalAccessFromFileURLs
Through this API, you can set whether to allow Javascript loaded with file URLs to access other sources, including other sources such as http and https. This setting is allowed by default in versions earlier than JELLY_BEAN. It is forbidden by default in JELLY_BEAN and later versions. .
<script>function loadXMLDoc(){    var arm = "http://www.so.com";    var xmlhttp;    if (window.XMLHttpRequest)    {        xmlhttp=new XMLHttpRequest();    }    xmlhttp.onreadystatechange=function()    {        //alert("status is"+xmlhttp.status);        if (xmlhttp.readyState==4)        {             console.log(xmlhttp.responseText);        }    }    xmlhttp.open("GET",arm);    xmlhttp.send(null);}loadXMLDoc();</script>
When AllowFileAccessFromFileURLs is true, the above javascript can successfully read the content of the http://www.so.com, but set to false, the above script execution will cause the following error, indicates that the browser prohibits javascript in the file url from accessing resources from other sources.
I/chromium (28336): [INFO: CONSOLE (0)] "XMLHttpRequest cannot
Load the http://www.so.com/. Origin null is not allowed
Access-Control-Allow-Origin. ", source: file: // data/local/tmp/attack.html
3. Use symbolic links for cross-Origin
 
To safely use WebView, both AllowUniversalAccessFromFileURLs and AllowFileAccessFromFileURLs should be set to disabled. In JELLY_BEAN and later versions, these two settings are also disabled by default, however, even if both are set to False. Using javascript in the File URL, you can still access other local files. This can be achieved through symbolic link attacks, provided that file
 
The URL executes javascript. The reason for this attack is that no matter how the same-source check of the file protocol is restricted, its javascript should be able to access the current file, by using javascript delayed execution and replacing the current file with a soft link pointing to another file, you can read the file referred to by the symbolic link. For detailed attack steps, see Chromium
Bug 144866 [3]. because the file protocol is disabled by default in the latest version of Chrome, this vulnerability does not exist in the latest version of chrome, and Google does not fix it, but it is widely used in WebView applications and browsers, all of them may be affected by this vulnerability. For example, a mobile browser has this vulnerability. By exploiting this vulnerability, malicious apps without special permissions can steal any private files of the browser, including but not limited to cookies, stored passwords, favorites, history, and can upload the stolen files to the attacker's server. To read the Cookie of a mobile browser through the file URL

Only the obtained Cookie file alert is simple, and the actual attack can upload files to the attacker's server. We analyzed 20 applications with exported WebView, and found that 30% of applications cannot resist this attack.
4. Security suggestions
1. Disable the file protocol for applications that do not require the file protocol.
2. for applications that require the file protocol, prohibit the file protocol from calling javascript.