上記の2つを組み合わせて、違う名前にすることが可能。objectに元々生えているメソッドについては、deleteや上書きが無効。descriptorsによる制御ではない。いう文字列が返ってくる。(これJavaのtoString()のデフォルト挙動だっけか)addJavascriptInterfaceを読んだWebView内の全てのwindowについて、window.androidは利用可能になる。iframe内のwindowなど。下から二番目の挙動を利用することで、例えば以下のようなコードを用いてaddJavascriptInterfaceで公開されたobjectを探索することができます。}}段々雲行きが怪しくなってきましたね。APIを叩いて様々なことが出来てしまいます。そのサブクラスのインスタンスが公開されてしまうとアウト」ということです。この記事の例ではAndroidのActivity(のサブクラス)を公開しているので、「流石にActivityをそのまま公開するとかしないわー、俺のは大丈夫だわー」とかミサワ風に安心してしまった人もいるかと思います。Applicationやそれらのサブクラスを公開しない、という対策だけでは不十分です。fieldにContextを持ってしまっている場合。field.get(jsInterface);fieldの可視性を変更した上で、簡単にContextが取得できてしまいます。この記事に限らず、インターネット上に公開されているaddJavascriptInterfaceの利用例では公開されるオブジェクトのfieldとしてContextを持たせている例が非常に多いです。情報のレプリケーションが行われているようです。このパターン以外でも、要はreflection経由で辿れる所にContextのインスタンスを置いてしまった時点でアウト、ということです。僕のJava力は低いため、reflectionを上手くつかいこなせる人にかかると、更に容易な方法があるかもしれません。Java側での"con"とか"context"とか"m_context"とかのfield名をどうやって知るの!という疑問もあるかと思います。APIのClass#getDeclaredFieldsはJS側からうまく叩くことが出来ないようで、reflectionを使ってfieldを探索することは出来ません。実はJS側からfield名を探索する必要はないのです。Android本体からアプリのapkをぶっこ抜き、apktoolを用いてapkをバラし、.smailファイルを解析してどこかにContextをお漏らししてないか調べるのは非常に簡単です。Androidにはproguardというソースコード難読化ツールがありますが、これを使った場合でもユーザの定義したclass名やfield名などのシンボルが"a"や"b"になるだけなので、解析の簡単さはほぼ変わりありません。以下の条件さえ揃えば、第三者のJSからAndroid端末内の個人情報を比較的簡単に取得できてしまいます。Androidアプリが、READ_PHONE_STATEなどの個人情報にアクセスできる権限を持っている。該当のAndroidアプリが、WebView#addJavascriptInterfaceを使って、reflection経由(または他の方法)でContextを取得できるようなobjectを公開している。該当のAndroidアプリのWebView内で任意のサイトに移動できる、XSS脆弱性のあるサイトを表示している、第三者のページをiframeなどで開くことができる。要は任意のJSコードを実行できる。addJavascriptInterfaceはこのようなものであるため、上記の条件をちゃんと回避できる、という自信のある方以外は基本「使わない」という選択肢を取ることをおすすめします。この記事を読んで「よくわからないんだけど」という方も同様です。Java間通信の代替手段としては、インタフェースは貧弱になりますが安全なWebChromeClient#onJsAlertやWebChromeClient#onJsPromptを用いるとよいのではないかと。個人でAndroidアプリ開発は儲かるのかって...最初に書いておくと、これはサクセスストーリーじゃないぞよ。(1)はてなブログをはじめよう!zentooさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。