One app of the company has not been updated for nearly two years. Although the number of users is not large, it needs to be maintained in case of problems due to cooperation with a third party. However, a third party recently conducted a network security scan on all of their software, and the Android app was also not immune…

Because the APP was developed in 13 years and the maintenance only ended in 16 or 17 years, a lot of bugs were scanned. Because it is the use of webVIEW + HTML mixed development, therefore, need to solve some webView-related problems:

Webview hidden interface problem (arbitrary command execution vulnerability)

The Android WebView component contains three hidden system interfaces: searchBoxJavaBridge_, accessibilityTraversal, and accessibility. The problem appears on Android4.4 and below. So, between Android3.0 and 4.4, we solved this problem by removing these hidden interfaces:

// 19 4.4 build.version.kitkat // 11 3.0 build.version_codes.honeycombif(Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB && Build.VERSION.SDK_INT < 19 && webView ! = null) { webView.removeJavascriptInterface("searchBoxJavaBridge_");
        webView.removeJavascriptInterface("accessibility");
        webView.removeJavascriptInterface("accessibilityTraversal");
    }
Copy the code

AddJavascriptInterface Any command execution vulnerability

Using javascript to interact with HTML in webview is a good way, but in Android4.2(16, including 4.2) and below, if you use addJavascriptInterface, there will be a vulnerability of js interface injection; After 4.2, this vulnerability was fixed as Google added @javascriptInterface.

The most radical way to solve this problem is to drop addJavascriptInterface below 4.2 and use onJsPrompt or some other method instead. Alternatively, some schemes can be used to reduce the risk caused by this vulnerability, such as using HTTPS and verifying certificates, or verifying page integrity if HTTP, removing hidden interfaces as described above.

    public boolean onJsPrompt(WebView view, String url, String message,String defaultValue, JsPromptResult result) {
        result.confirm(CGJSBridge.callJava(view, message));
        Toast.makeText(view.getContext(),"message="+message,Toast.LENGTH_LONG).show();
        return true;
    }
Copy the code

Bypass certificate verification vulnerability

There is an onReceivedError method in webviewClient. In the event of a certificate verification error, we can use handler.proceed() to ignore the certificate verification and continue loading the web page, or use the default handler.cancel() for terminal loading. This “bypass certificate validation vulnerability” occurs because we used handler.proceed(). Use handler.proceed() is unnecessary if you are sure that all pages are valid for certificate validation

    @SuppressLint("NewApi") @Override public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) { //handler.proceed(); // Accept the certificate super.onReceivedSslError(view, handler, error); }Copy the code

AllowFileAccess loophole of the same Origin policy in File domain

This problem occurs if webView.getSettings ().setallowFileAccess (Boolean) is set to true; The vulnerability is caused by delayed execution of Javascript by WebView and HTML file replacement. The solution is to disable WebView pages from opening local files, i.e

    webview.getSettings().setAllowFileAccess(false);
Copy the code

Or, more directly, ban JavaScript

    webview.getSettings().setJavaScriptEnabled(false);
Copy the code

Due to business reasons, this solution is not ideal, if there is a better solution, welcome to advise!

ThinkinLiu blog: IT old five

This is all about WebView network security problems, other non-security holes here will not say ~

The longer I do development, the more I feel like I won’t have too much; If there are mistakes in the article, please point out, thank you!