<p>For anyone checking this out in 2020, it seems like the security concern only affects Android APIs lower than 17 (Android 4.2). So, if your <code>minSdkVersion</code> is <code>17</code> or higher, then you should be safe.</p>
<p>Here are references:</p>
<ul>
<li><p><a href="https://labs.f-secure.com/archive/webview-addjavascriptinterface-remote-code-execution/" rel="nofollow noreferrer">https://labs.f-secure.com/archive/webview-addjavascriptinterface-remote-code-execution/</a></p>
<blockquote>
<p>If the linked SDK has been built for an API lower than 17, the vulnerability exists – even if the application using the SDK has been built for API 17 or above.</p>
</blockquote>
</li>
<li><p><a href="https://7asecurity.com/blog/2019/09/hacking-mandated-apps-part-5-rce-in-webview-mstg-platform-7/" rel="nofollow noreferrer">https://7asecurity.com/blog/2019/09/hacking-mandated-apps-part-5-rce-in-webview-mstg-platform-7/</a></p>
<blockquote>
<p>Android versions from Android 2.4 to Android 4.1 are affected by a vulnerability that allows remote code execution when JavaScript is injected in the WebView.</p>
</blockquote>
</li>
<li><p><a href="https://arxiv.org/pdf/1912.12982.pdf" rel="nofollow noreferrer">https://arxiv.org/pdf/1912.12982.pdf</a> (Page 7)</p>
<blockquote>
<p>Google later fixed this weakness on Android 4.2 and
above. However, if an app sets the targetSdkVersion lower than 17 and also
calls this API, the system will still render the vulnerable API behavior even when
running on Android 4.2+. Such vulnerable app examples are available at <a href="https://sites.google.com/site/androidrce/" rel="nofollow noreferrer">https://sites.google.com/site/androidrce/</a>.</p>
</blockquote>
</li>
</ul>
Android JavascriptInterface Security?
<p>From the documentation:
<a href="http://developer.android.com/reference/android/webkit/WebView.html#addJavascriptInterface%28java.lang.Object,%20java.lang.String%29" rel="noreferrer">http://developer.android.com/reference/android/webkit/WebView.html#addJavascriptInterface%28java.lang.Object,%20java.lang.String%29</a></p>

<p>"Using addJavascriptInterface() allows JavaScript to control your application. This can be a very useful feature or a dangerous security issue. When the HTML in the WebView is untrustworthy (for example, part or all of the HTML is provided by some person or process), then an attacker could inject HTML that will execute your code <strong>and possibly any code of the attacker's choosing.</strong>
    <strong>Do not use addJavascriptInterface() unless all of the HTML in this WebView was written by you.</strong>
    The Java object that is bound runs in another thread and not in the thread that it was constructed in.</p>

<p><strike>Suppose I have an interface that only shows a custom dialog box, or starts a download to sd card. Would this be unsafe to use for any url? How could an attack page use the interface to run any code of the attacker's choosing?</strike></p>

<p><strong>Update:</strong>
According to the <a href="http://developer.android.com/reference/android/webkit/WebView.html#addJavascriptInterface%28java.lang.Object,%20java.lang.String%29" rel="noreferrer">documentation</a>:</p>

<blockquote>
  <p>This method can be used to allow JavaScript to control the host
  application. This is a powerful feature, but also presents a security
  risk for applications targeted to API level JELLY_BEAN or below,
  because JavaScript could use reflection to access an injected object's
  public fields. Use of this method in a WebView containing untrusted
  content could allow an attacker to manipulate the host application in
  unintended ways, executing Java code with the permissions of the host
  application. Use extreme care when using this method in a WebView
  which could contain untrusted content.</p>
</blockquote>

<p><strike>Is there an example of how this could happen? It this just saying that <code>DOWNLOADINTERFACE.dangerousfunction</code> could be called if that's a public method on that class?</strike></p>

<p><strong><h1>Update:</h1></strong></p>

<p>I tested based on the example of the exploit below, sites <em>can</em> get access to the system through interfaces in Android 4.4, 4.1, and 3.2.</p>

<p>However, I was <em>not</em> seeing this bug on Android 2.2, or 2.3, the hack only causes a force-close. What is the best way to prevent this hack, other than not using JSInterface? Can I include bogus functions like this, to prevent unauthorized calling of functions?</p>

<pre><code>public Object getClass() {
  //throw error, return self, or something?  
}
</code></pre>

<p>Or rewrite everything using ajax and intercepting calls? Would that result in better/worse performance?</p>

<p><strong>Update:</strong></p>

<p>I succeeded in removing the JS interface, and replaced the functionality by defining window.open(specialurl) commands for all the window.(interface) functions, and overriding those in the shouldOverrideUrlLoading. Strangely enough, window.open() must be used in some cases, or the webview breaks display (like javascript is stopping?), and in other cases location.replace should be used or it will just show a "interface://specialdata" could not be found message.</p>

<p>(I set settings.setJavaScriptCanOpenWindowsAutomatically(true) so window.open works from JS all the time.)</p>

<p>Anyone know the best way to rewrite an app with this behavior?</p>