Passer-by · 2015/12/25 12:11

0 x00 preface

Now more and more Android apps use WebView, and the attacks against WebView are diversified. Here is a brief introduction to the current WebView File domain attack some common methods, and focus on the examples of manufacturers to repair some problems still exist. (Affecting Android 4.4 and below)

0x01 File protocol in WebView

We know that in later versions of Android JELLY_BEAN, we can use the file domain to attack if the WebView does not prohibit the use of the file domain and JavaScript support is turned on by the WebView.

In the File domain, arbitrary JavaScript code can be executed, same-origin policy cross-domain access can access private directory files, and so on. If the WebView component used in APP does not restrict the URL in the form of file protocol header, privacy information will be leaked. For IM software, chat information, contacts and other important information will be leaked. For browser software, cookies and other information will be leaked.

For example, a file field exploit was discovered on Wooyun.

The code is as follows:

var request = false;
    if(window.XMLHttpRequest) {
        request = new XMLHttpRequest();
        if(request.overrideMimeType) {
            request.overrideMimeType('text/xml');
        }
    }
        xmlhttp = request;
    var prefix = "file:////data/data/com.qihoo.browser/databases";
    var postfix = "/webviewCookiesChromium.db"; //取保存cookie的db
    var path = prefix.concat(postfix);
    // 获取本地文件代码 

    xmlhttp.open("GET", path, false);
    xmlhttp.send(null);
Copy the code

0x02 Bypass using symbolic Link Same Origin policy

WebKit has cross-domain access checks, and its rule is that Ajax access to the same path file allow, otherwise deny. Using symbolic links to point to private files with the same file name will result in invalid same-origin policy check. Attackers bypass the same origin policy by using symbolic links and File urls through local files, and then carry out cross-site scripting attacks or obtain passwords and cookie information.

Javascript loaded through File URL is not allowed to read other local files in JELLY_BEAN and later versions. Javascript loaded through File URL is not allowed to access other sources, including other files and HTTP, HTTPS, and other sources. There is still a way to access other local files through the javascript in the File URL, which can be achieved through symbolic link attacks, provided that the File URL is allowed to execute javascript.

It is now known that the file domain attack can affect Android 4.4 by using symbolic link same-origin policy bypassing, further expanding the attack scope.

For a typical vulnerability analysis, see [2] in the reference column.

0x03 Problem still exists

Since the file domain security issue was raised in 2013, some vendors have made fixes accordingly. Due to the awareness of some developers and the actual product demand, although various manufacturers have made a lot of targeted patch work, various problems still occur. Of course, the premise here is that the WebView does not disable the file protocol and does not prohibit javascript calls, that is, the WebView setAllowFileAccess(true) and setJavaScriptEnabled(true). Here are a few examples:

A. During the repair of an app, determine whether the url starts with file:/// in A certain process and return it if so; if not, loadUrl

At first glance, this fix seems to prevent file domain attacks. However, it ignores the question of whether loadUrl can still work properly if we add a space before file:///. After trying to find the protocol header will be corrected, that is, the file field before adding a space, is normal access. So we constructed the following POC to circumvent this limitation:

Intent i = new Intent(); i.setClassName("xxx.xxx.xxx","xxx.xxx.xxx.xxxxxx"); i.putExtra("url", " file:///mnt/sdcard/filedomain.html"); // Add the space startActivity(I) before the file field;Copy the code

B. Naturally, some developers want to trim the space and fix it, so we see the following example

This type of repair is generally considered to have solved the problem described above. However, there is a trick to this header, that is, the protocol header does not include /// and can still be loadUrl normal. To circumvent this limitation, we constructed the following POC:

Intent i = new Intent(); i.setClassName("xxx.xxx.xxx","xxx.xxx.xxx.xxxxxx"); i.putExtra("url", "file:mnt/sdcard/filedomain.html"); StartActivity (I);Copy the code

Through these two simple examples, we can see from the details that although more and more developers have noticed some problems of file field attacks and have taken corresponding countermeasures, there are still many ways to bypass due to poor repair. The root cause is the problem of obtaining the protocol header.

0 x04 reference

  • 【 1 】 blogs. 360. Cn / 360 mobile / 2…
  • 【 2 】 jaq.alibaba.com/blog.htm?sp…

0 x05 summary

Summarize the fixes for this type of problem

  1. Disable file for applications that do not need the file protocol
  2. For applications that need to use file, disable the File protocol from calling javascript
  3. Set not to export components that do not need to be exported

The problem of File field attacks is now a commonplace, but there are still a lot of obscene means to use. Here do not say clearly, in short, how far thought, how wide the attack surface! Have Fun!