hacktricks/mobile-pentesting/android-app-pentesting/android-applications-basics.md

Androidアプリケーションの基礎

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• サイバーセキュリティ会社で働いていますか？ HackTricksで会社を宣伝したいですか？または、PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロードしたいですか？SUBSCRIPTION PLANSをチェックしてください！
• The PEASS Familyを見つけてください。独占的なNFTのコレクションです。
• 公式のPEASS＆HackTricksのグッズを手に入れましょう。
• 💬 Discordグループまたはテレグラムグループに参加するか、Twitterでフォローしてください🐦@carlospolopm。
• ハッキングのトリックを共有するには、PRを hacktricks repo と hacktricks-cloud repo に提出してください。

HackenProofはすべての暗号バグバウンティの場所です。

遅延なしで報酬を受け取る
HackenProofのバウンティは、顧客が報酬予算を入金した後にのみ開始されます。バグが検証された後に報酬を受け取ることができます。

Web3ペントestingの経験を積む
ブロックチェーンプロトコルとスマートコントラクトは新しいインターネットです！上昇期のweb3セキュリティをマスターしましょう。

Web3ハッカーレジェンドになる
各検証済みのバグごとに評判ポイントを獲得し、週間リーダーボードのトップを制覇しましょう。

HackenProofでサインアップしてハッキングから収益を得ましょう！

{% embed url="https://hackenproof.com/register" %}

Androidセキュリティモデル

2つのレイヤーがあります：

• OSは、インストールされたアプリケーションを互いに分離します。
• アプリケーション自体は、開発者が特定の機能を公開し、アプリケーションの機能を設定できるようにします。

UIDの分離

各アプリケーションには特定のユーザーIDが割り当てられます。これはアプリのインストール時に行われるため、アプリは自分のユーザーIDが所有するファイルと共有されるファイルにしかアクセスできません。したがって、アプリ自体、OSの特定のコンポーネント、およびルートユーザーのみがアプリのデータにアクセスできます。

UIDの共有

2つのアプリケーションは同じUIDを使用するように設定できます。これは情報を共有するために便利ですが、1つのアプリケーションが侵害されると、両方のアプリケーションのデータが侵害されます。そのため、この動作は推奨されません。
同じUIDを共有するには、アプリケーションはマニフェストで同じ android:sharedUserId の値を定義する必要があります。

サンドボックス

Androidアプリケーションサンドボックスは、各アプリケーションを別のユーザーIDで別のプロセスとして実行することを可能にします。各プロセスには独自の仮想マシンがあり、アプリのコードは他のアプリから分離して実行されます。
Android 5.0（L）以降、SELinuxが強制されています。基本的に、SELinuxはすべてのプロセス間の相互作用を拒否し、それらの間の予想される相互作用のみを許可するポリシーを作成します。

権限

アプリをインストールすると、アプリは権限を要求します。これは、AndroidManifest.xmlファイルの**uses-permission要素で構成された権限を要求していることを意味します。uses-permission要素は、name属性内の要求された権限の名前を示します。また、maxSdkVersion属性もあり、指定したバージョンよりも高いバージョンでは権限を要求しないようにします。
Androidアプリケーションは最初からすべての権限を要求する必要はありませんが、動的に権限を要求することもできますが、すべての権限はマニフェストで宣言**する必要があります。

アプリが機能を公開する場合、指定された権限を持つアプリのみがアクセスできるように制限することができます。
権限要素には3つの属性があります：

• 権限の名前
• 関連する権限をグループ化するためのpermission-group属性
• 権限がどのように付与されるかを示すprotection-level。4つのタイプがあります：
  • Normal：アプリに既知の脅威がない場合に使用されます。ユーザーは承認する必要はありません。
  • Dangerous：要求するアプリケーションに特権アクセスを付与することを示します。ユーザーに承認を要求します。
  • Signature：コンポーネントをエクスポートする同じ証明書で署名されたアプリのみが権限を付与できます。これは最も強力な保護のタイプです。
  • SignatureOrSystem：コンポーネントをエクスポートする同じ証明書で署名されたアプリまたはシステムレベルのアクセスで実行されるアプリのみが権限を付与できます。

事前インストールされたアプリケーション

これらのアプリは一般的に**/system/appまたは/system/priv-appディレクトリにあり、一部は最適化されている**場合があります（classes.dexファイルが見つからない場合があります）。これらのアプリケーションは、実行時に多くの権限で実行されている場合があるため、確認する価値があります。

• AOSP（Android OpenSource Project）ROMに含まれるもの
• デバイスの製造元によって追加されたもの
• 携帯電話プロバイダーによって追加されたもの（それらから購入した場合）

ルーティング

物理的なAndroidデバイスにルートアクセスを取得するためには、通常、デバイスとバージョンに特有の1つまたは2つの脆弱性を悪用する必要があります。
エクスプロイトが成功した後、通常はLinuxのsuバイナリがユーザーのPATH環境変数で指定された場所（/system/xbinなど）にコピーされます。

suバイナリが設定されると、別のAndroidアプリがsuバイナリとのインターフェースを使用してルートアクセスのリクエストを処理します。これには、Google Playストアで利用可能なSuperuserやSuperSUなどのアプリが使用されます。

{% hint style="danger" %} ルーティングプロセスは非常に危険で、デバイスに重大な損害を与える可能性があります。 {% endhint %}

ROM

カスタムファームウェアをインストールしてOSを置き換えることができます。これにより、古いデバイスの有用性を拡張したり、ソフトウェアの制限を回避したり、最新のAndroidコードにアクセスしたりすることができます。
OmniROMとLineageOSは、最も人気のあるファームウェアの2つです。

デバイスにカスタムファームウェアをインストールするためには、必ずしもデバイスをルート化する必要はありません。一部のメーカーは、ブートローダーのアンロックを公式にサポートしています。

影響

デバイスがルート化されると、任意のアプリがルートアクセスを要求することができます。悪意のあるアプリがそれを取得した場合、ほとんどすべてにアクセスでき、電話を破損させることができます。

Androidアプリケーションの基礎

この紹介はhttps://maddiestone.github.io/AndroidAppRE/app_fundamentals.htmlから引用されています。

基礎の復習

• Androidアプリケーションは_APKファイル形式_であり、APKは基本的にZIPファイルです（ファイルの拡張子を.zipに変更して、unzipを使用して内容を開くことができます）。
• APKの内容（完全ではありません）
• AndroidManifest.xml
• resources.arsc/strings.xml
• resources.arsc：バイナリXMLなどの、事前にコンパイルされたリソースを含むファイルです。
• res/xml/files_paths.xml
• META-INF/
• 証明書がここにあります！
• classes.dex
• アプリケーションがデフォルトで実行するJava（またはKotlin）コードのDalvikバイトコードです。
• lib/
• アプリケーションのネイティブライブラリは、デフォルトではここにあります！ lib/ディレクトリの下に、cpu固有のディレクトリがあります。
• armeabi：すべてのARMベースのプロセッサのコンパイル済みコードのみ
• armeabi-v7a：すべてのARMv7およびそれ以上のベースのプロセッサのコンパイル済みコードのみ
• x86：X86のコンパイル済みコード
• mips：MIPSプロセッサのコンパイル済みコードのみ
• assets/
• アプリが必要とする他のファイルが含まれる場所です。
• ここには、追加のネイティブライブラリやDEXファイルが含まれる場合があります。これは、マルウェアの作成者が追加のコード（ネイティブまたはDalvik）を「隠す」ために、デフォルトの場所に含めない場合に特に発生します。
• res/
• resources.arscにコンパイルされていないリソースが含まれるディレクトリ

DalvikとSmali

ほとんどのAndroidアプリケーションはJavaで書かれています。Kotlinもサポートされており、Javaとの相互運用が可能です。このワークショップの残りの部分では、私が「Java」と言及するときは「JavaまたはKotlin」という意味だと思ってください。デスクトップアプリケーションのようにJavaコードがJava仮想マシン（JVM）で実行されるのではなく、AndroidではJavaは_Dalvik Executable（DEX）バイトコード_**形式にコンパイルされます**。Androidの以前のバージョンでは、バイトコードはDalvik仮想マシンによって変換されました。最近のAndroidのバージョンでは、Androidランタイム（ART）が使用されています。
開発者がJavaで書き、コードがDEXバイトコードにコンパイルされる場合、逆アセンブルするためには逆の方向で作業します。
\

SmaliはDalvikバイトコードの人間が読めるバージョンです。厳密には、Smaliとbaksmaliはツール（アセンブラとディスアセンブラ）の名前ですが、Androidでは、私たちはしばしば「Smali」という用語を命令に使用します。コンパイルされたC/C++コードのリバースエンジニアリングやコンピュータアーキテクチャを行ったことがある場合、「SMALIはアセンブリ言語のようなものです：高レベルのソースコードとバイトコードの間のものです」。

HackenProofはすべての暗号バグバウンティの場所です。

遅延なしで報酬を受け取る
HackenProofのバウンティは、顧客が報酬予算を入金した後に開始されます。バグが検証された後に報酬を受け取ることができます。

Web3ペントテストの経験を積む
ブロックチェーンプロトコルとスマートコントラクトは新しいインターネットです！成長途中のweb3セキュリティをマスターしましょう。

Web3ハッカーレジェンドになる
各検証済みのバグで評判ポイントを獲得し、週間リーダーボードのトップを制覇しましょう。

HackenProofでサインアップしてハッキングから報酬を得ましょう！

{% embed url="https://hackenproof.com/register" %}

インテント

インテントは、Androidアプリがコンポーネント間または他のアプリとの間で通信するための主要な手段です。これらのメッセージオブジェクトは、HTTP通信でのGET/POSTリクエストのように、アプリ間またはコンポーネント間でデータを運ぶこともできます。

したがって、インテントは基本的には**コ

暗黙的なインテント

インテントは、Intentコンストラクタを使用してプログラムで作成されます。

Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));

以前に宣言されたインテントのアクションはACTION_SENDであり、エクストラはmailto Uriです（エクストラはインテントが期待する追加情報です）。

このインテントは、次の例のようにマニフェスト内で宣言する必要があります：

<activity android:name="ShareActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>

インテントフィルタは、メッセージを受け取るためにアクション、データ、およびカテゴリと一致する必要があります。

「インテントの解決」プロセスは、どのアプリが各メッセージを受け取るかを決定します。このプロセスでは、優先度属性が考慮されます。この属性は、インテントフィルタの宣言で設定でき、優先度が高いものが選択されます。この優先度は、-1000から1000まで設定でき、アプリケーションはSYSTEM_HIGH_PRIORITYの値を使用することができます。競合が発生した場合、ユーザーが決定できるように「選択ウィンドウ」が表示されます。

明示的インテント

明示的インテントは、ターゲットとなるクラス名を指定します：

Intent downloadIntent = new (this, DownloadService.class):

他のアプリケーションでは、事前に宣言されたインテントにアクセスするために次のように使用することができます：

Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);

保留中のインテント

これにより、他のアプリケーションがあなたのアプリケーションのアイデンティティと権限を使用してアクションを実行できます。保留中のインテントを構築する際には、インテントと実行するアクションを指定する必要があります。宣言されたインテントが明示的でない場合（どのインテントが呼び出せるかを宣言しない場合）、悪意のあるアプリケーションは被害者アプリの代わりに宣言されたアクションを実行することができます。さらに、アクションが指定されていない場合、悪意のあるアプリは被害者の代わりに任意のアクションを実行することができます。

ブロードキャストインテント

以前のインテントとは異なり、ブロードキャストインテントは複数のアプリケーションによって受信されることができます。ただし、APIバージョン14以降では、Intent.setPackageを使用してメッセージを受信するアプリを指定することが可能です。

また、ブロードキャストを送信する際には、パーミッションを指定することも可能です。受信側のアプリはそのパーミッションを持っている必要があります。

ブロードキャストには2つのタイプがあります：通常（非同期）と順序付けられた（同期）。順序は、受信側の要素内で設定された優先度に基づいています。各アプリはブロードキャストを処理、中継、または破棄することができます。

ContextクラスのsendBroadcast(intent, receiverPermission)関数を使用してブロードキャストを送信することができます。また、LocalBroadCastManagerのsendBroadcast関数を使用すると、メッセージがアプリを離れることはありません。これを使用すると、受信側コンポーネントをエクスポートする必要もありません。

スティッキーブロードキャスト

この種のブロードキャストは、送信後も長時間アクセスできます。これらはAPIレベル21で非推奨となっており、使用しないことが推奨されています。これにより、任意のアプリケーションがデータを嗅覚するだけでなく、変更することも可能です。

「sticky」を含む関数（sendStickyBroadcastやsendStickyBroadcastAsUserなど）が見つかった場合は、その影響を確認し、削除を試みてください。

ディープリンク/URLスキーム

ディープリンクは、URLを介してインテントをトリガーすることができます。アプリケーションは、アクティビティ内にURLスキームを宣言することができます。したがって、Androidデバイスがそのスキームを使用してアドレスにアクセスしようとするたびに、アプリケーションのアクティビティが呼び出されます。

この場合、スキームはmyapp://です（また、**category BROWSABLE**にも注意してください）。

intent-filter内に次のようなものが見つかった場合：

それはhttp://www.example.com/gizmosのようなものを期待していることを意味します。

次のようなものが見つかった場合：

それはexample://gizmosで始まるURLを期待していることを意味します。この場合、以下のペイロードを使用して機能を悪用し、任意のページに移動し、JSを実行しようとすることができます。

<a href="example://gizmos/https://google.com">click here</a>
<a href="example://gizmos/javascript://%250dalert(1)">click here</a>

アプリで実行されるコードを見つけるために、ディープリンクで呼び出されるアクティビティに移動し、onNewIntent 関数を検索します。

HTML ページを使用せずにディープリンクを呼び出す方法を学びます。

AIDL - Android Interface Definition Language

Android Interface Definition Language（AIDL）を使用すると、クライアントとサービスが相互プロセス通信（IPC）を使用してお互いと通信するために合意するプログラミングインターフェースを定義できます。Androidでは、通常、1つのプロセスは他のプロセスのメモリにアクセスできません。そのため、通信するために、オブジェクトをオペレーティングシステムが理解できるプリミティブに分解し、オブジェクトをその境界を越えてマーシャリングする必要があります。そのマーシャリングを行うコードは書くのが面倒なので、AndroidはAIDLで処理します。

AIDLを使用するサービスは、バウンドサービスと呼ばれます。サービスのクラスには、onBind メソッドがあります。これが相互作用が始まる場所であり、潜在的な脆弱性を探すためにレビューするコードの最初の部分です。

バウンドサービスは、クライアント-サーバーインターフェースのサーバーです。コンポーネント（アクティビティなど）がサービスにバインドし、リクエストを送信し、レスポンスを受け取り、相互プロセス通信（IPC）を実行できるようにします。バウンドサービスは通常、他のアプリケーションコンポーネントを提供する間だけ存在し、無期限にバックグラウンドで実行されません。

Messenger

Messengerは、別のIPCメカニズムの一種です。**Messengerも「バウンドサービス」**であるため、クライアントアプリから渡されるデータもonBindメソッドを介して処理されます。したがって、コードレビューはこのメソッドから始め、機密な機能の呼び出しやデータの安全な処理を探す必要があります。

Binder

Binderクラスが直接呼び出されることは珍しいですが、Binderクラスを抽象化するAIDLを使用する方が簡単です。ただし、Binderはカーネルレベルのドライバであり、データを1つのプロセスのメモリから別のプロセスのメモリに移動します（https://www.youtube.com/watch?v=O-UHvFjxwZ8）。

コンポーネント

これには、アクティビティ、サービス、ブロードキャストレシーバー、プロバイダーが含まれます。

ランチャーアクティビティとその他のアクティビティ

Androidアクティビティは、Androidアプリのユーザーインターフェースの1つの画面です。このように、Androidアクティビティはデスクトップアプリケーションのウィンドウに非常に似ています。Androidアプリには1つ以上のアクティビティが含まれる場合があります。

ランチャーアクティビティは、ほとんどの人がAndroidアプリケーションのエントリーポイントと考えるものです。ランチャーアクティビティは、ユーザーがアプリケーションのアイコンをクリックしたときに起動されるアクティビティです。ランチャーアクティビティは、アプリケーションのマニフェストを見ることで特定できます。ランチャーアクティビティは、以下のMAINとLAUNCHERのインテントがリストされています。

UIを持たないアプリケーション、特にバックグラウンドでサービスを実行するプリインストールされたアプリケーション（例：ボイスメール）には、ランチャーアクティビティがない場合があることに注意してください。

<activity android:name=".LauncherActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

アクティビティは、デバイス上の他のプロセスがアクティビティを起動できるようにエクスポートすることができます。デフォルトでは、エクスポートされませんが、以下の設定を行うことでエクスポートすることができます。

android:exported="true"

この設定を行うことで、他のプロセスからアクティビティが起動できるようになります。

<service android:name=".ExampleExportedService" android:exported="true"/>

注意：アクティビティの保護をバイパスする能力は常に脆弱性ではありません。アクセスしたデータを確認する必要があります。 また、一部のアクティビティは呼び出し元にデータを返します。この場合、**setResult**メソッドを検索し、Intentパラメータに渡されるデータを確認する必要があります。もしデータが機密情報であれば、情報漏洩の脆弱性が存在し、アクティビティと通信可能なアプリで悪用される可能性があります。

アクティビティのコードはonCreateメソッドで始まります。

アプリケーションのサブクラス

Androidアプリケーションは、Applicationのサブクラスを定義することができます。AndroidアプリがApplicationのサブクラスを定義する場合、このクラスはアプリケーション内の他のクラスよりも先にインスタンス化されます。

アプリケーションのサブクラスで**attachBaseContextメソッドが定義されている場合、onCreate**メソッドの前に呼び出されます。

サービス

サービスはUIを持たずにバックグラウンドで実行されます。ユーザーが別のアプリケーションを使用し始めても、長時間実行されるプロセスを実行するために使用されます。

サービスはさまざまな方法で開始されるため、アプリケーションのエントリーポイントとなります。サービスをエントリーポイントとして開始するデフォルトの方法は、Intentsを使用することです。

サービスを開始するために**startServiceメソッドが呼び出されると、サービス内のonStartメソッドが実行されます。このメソッドはstopServiceメソッドが呼び出されるまで無期限に実行されます。クライアントが接続されている間だけサービスが必要な場合は、bindService**メソッドを使用してクライアントがサービスに「バインド」する必要があります。

バインドされたサービスの場合（前のセクションを参照）、データは**onBind**メソッドに渡されます。

たとえば、サービスはユーザーが別のアプリケーションにいる間にバックグラウンドで音楽を再生したり、ネットワーク経由でデータを取得したりする場合があります。

サービスはエクスポートされることがあり、デバイス上の他のプロセスからサービスを開始できます。デフォルトでは、サービスはエクスポートされませんが、マニフェストで設定することができます。

<service android:name=".ExampleExportedService" android:exported="true"/>

ブロードキャストレシーバー

ブロードキャストはメッセージングシステムと考えることができ、ブロードキャストレシーバーはリスナーです。アプリケーションが特定のブロードキャストのためにレシーバーを登録している場合、システムがブロードキャストを送信すると、そのレシーバー内のコードが実行されます。なお、この場合、複数のアプリが同じメッセージを受け取ることができます。

アプリは2つの方法でレシーバーを登録することができます。アプリのマニフェストに登録するか、アプリのコードで**registerReceiver** API呼び出しを使用して動的に登録するかです。マニフェストでは、レシーバー要素内でパーミッションを使用して受け入れるブロードキャストを制限することができます。動的に定義する場合は、registerReceiverメソッドにパーミッションを渡すことができます。

いずれの場合でも、レシーバーを登録するためには、レシーバーのインテントフィルターを設定する必要があります。これらのインテントフィルターは、レシーバーをトリガーするべきブロードキャストです。

レシーバーが登録されている特定のブロードキャストが送信されると、BroadcastReceiverクラスの**onReceiveが実行**されます。

例えば、アプリケーションは低電池メッセージのためにレシーバーを登録し、その情報に基づいて動作を変更することができます。

ブロードキャストは非同期（すべてのレシーバーが受信する）または同期（優先度に基づいて順序付けられた方法でブロードキャストが受信される）のいずれかです。

{% hint style="danger" %} 注意：どのアプリケーションでも自身を最優先でブロードキャストを受け取るように設定できます。 {% endhint %}

ブロードキャストレシーバーに実装されたコードを調査するには、レシーバーのクラスの**onReceive**メソッドを検索する必要があります。
なお、順序付けられたブロードキャストは受信したIntentを破棄したり、変更したりすることができます。そのため、レシーバーはデータを検証する必要があります。

コンテンツプロバイダー

コンテンツプロバイダーは、関係データベースなどの構造化データをアプリ間で共有する方法です。そのため、これらを保護するためにパーミッションを使用し、適切な保護レベルを設定することが非常に重要です。
コンテンツプロバイダーは、アプリが持つ必要のあるパーミッションを指定するために**readPermissionおよびwritePermission属性を使用することができます。これらのパーミッションは、permission属性よりも優先されます。
さらに、grantUriPermissionをtrueに設定し、その後、マニフェストファイル内のプロバイダ要素内のgrant-uri-permission**要素で適切なパラメータを設定することで、一時的な例外を許可することもできます。

**grant-uri-permission**には、path、pathPrefix、pathPatternの3つの属性があります。

• path: 除外するための完全なパスを指定する
• pathPrefix: パスの先頭部分を指定する
• pathPattern: ワイルドカードとシンボリック置換を使用して、より細かい制御を行うことができる

潜在的な脆弱性（SQLインジェクションなど）を回避するために、受け取った入力を検証およびサニタイズすることが重要です。

コンテンツプロバイダーの特徴:

• コンテンツプロバイダーコンポーネントは、他のアプリケーションからのリクエストに応じてデータを供給します。
• データはファイルシステム、SQLiteデータベース、Web上、またはアプリがアクセスできる他の永続ストレージ場所に保存することができます。
• コンテンツプロバイダーを介して、他のアプリケーションはデータをクエリしたり、変更したりすることができます（コンテンツプロバイダーが許可している場合）。
• コンテンツプロバイダーは、アプリが他のアプリとデータを共有したい場合に便利です。
• データベースと非常に似ており、4つのメソッドがあります。
• insert()
• update()
• delete()
• query()

FileProvider

これは、フォルダからファイルを共有するタイプのコンテンツプロバイダーです。次のようにファイルプロバイダーを宣言できます：

<provider android:name="androidx.core.content.FileProvider"
android:authorities="com.example.myapp.fileprovider"
android:grantUriPermissions="true" android:exported="false">
<meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/filepaths" />
</provider>

android:exported 属性に注意してください。もし true であれば、外部のアプリケーションが共有フォルダにアクセスできるようになります。
android:resource="@xml/filepaths" という設定は、ファイル res/xml/filepaths.xml が FileProvider が 共有するフォルダ の設定を含んでいることを示しています。以下は、そのファイルでフォルダを共有する方法の例です：

<paths>
<files-path path="images/" name="myimages" />
</paths>

path="."のようなものを共有することは、プロバイダがエクスポートされていなくても、コードの他の部分で脆弱性がある場合には危険です。
content://com.example.myapp.fileprovider/myimages/default_image.jpgを使用して、そのフォルダ内の画像にアクセスすることができます。

<paths>要素には複数の子要素を持つことができ、それぞれが共有する異なるディレクトリを指定します。**<files-path>要素に加えて、<external-path>要素を使用して外部ストレージのディレクトリを共有し、<cache-path>**要素を使用して内部キャッシュディレクトリのディレクトリを共有することもできます。
特定のファイルプロバイダ属性の詳細については、こちらを参照してください。

FileProvidersに関する詳細はこちらを参照してください。.

WebViews

WebViewsはAndroidアプリに埋め込まれた実質的なウェブブラウザです。
WebViewsのコンテンツはリモートサイトから取得することも、アプリに含まれるファイルから取得することもできます。
WebViewsは他のウェブブラウザと同じ脆弱性に対しても脆弱です。ただし、攻撃の表面を制限するためのいくつかの設定があります。

Androidには2つのタイプのWebViewsがあります：

• WebViewClientは、シンプルなHTMLのレンダリングに最適です。これはJSのalert関数を実行しません。したがって、この関数を使用したXSSテストは無効になります。
• WebChromeクライアントは、Chromeブラウザです。

なお、WebViewブラウザはネイティブブラウザのクッキーにアクセスできません。

URLまたはファイルを読み込むには、loadUrl、loadData、または**loadDataWithBaseURL関数を使用することができます。サニタイズされたURLにのみアクセスすることが重要です。
WebViewのセキュリティは、WebSettingsオブジェクトを介して設定することができます。
たとえば、JSコードの実行を無効にするには、setJavaScriptEnabledメソッドをfalse**の値で使用します。これにより、XSSやその他のJS関連の脆弱性の可能性がなくなります。

JavaScriptの「Bridge」機能は、JavaオブジェクトをWebViewに注入し、JSからアクセス可能にします。Android 4.2以降では、JavaScriptからアクセス可能にするためにメソッドに**@JavascriptInterface**を注釈する必要があります。

setAllowContentAccessにtrueを渡すと、WebViewsはcontent://スキームを介してコンテンツプロバイダにアクセスできます。これは明らかにセキュリティリスクを引き起こします。このアクセスが与えられる場合、content:// URLが安全であることを確認することが非常に重要です。

デフォルトでは、ローカルファイルはWebViewからfile:// URLを介してアクセスできますが、この動作を防ぐためのいくつかの方法があります：

• **setAllowFileAccessにfalse**を渡すと、file:///android_assetおよびfile:///android_resを除くファイルシステムへのアクセスが防止されます。これらのパスは非機密データ（画像など）にのみ使用する必要があるため、これは安全です。
• **setAllowFileAccess**メソッドは、file:// URLのパスが他のfileスキームURLからコンテンツにアクセスできるかどうかを示します。
• **setAllowUniversalAccessFromFileURLs**メソッドは、file:// URLのパスが任意のオリジンからコンテンツにアクセスできるかどうかを示します。

その他のアプリコンポーネント

アプリケーションの署名

• Androidでは、アプリをインストールする前に、すべてのアプリがデジタル証明書で署名される必要があります。Androidはこの証明書を使用してアプリの作者を識別します。
• デバイスでアプリを実行するには、アプリは署名されている必要があります。アプリがデバイスにインストールされると、パッケージマネージャはapkファイルの証明書が正しく署名されているかどうかを検証します。
• アプリは自己署名されるか、CAを介して署名されることがあります。
• アプリケーションの署名により、アプリはよく定義されたIPCを介して他のアプリにアクセスすることはできませんし、変更されずにデバイスに渡されることも保証されます。

アプリケーションの検証

• Android 4.2以降、アプリケーションの検証がサポートされています。ユーザーは「アプリの検証」を有効にすることができ、アプリケーションがインストール前にアプリケーション検証プログラムによって評価されます。
• アプリケーションの検証では、ユーザーが有害なアプリをインストールしようとした場合にユーザーに警告することができます。特に悪質なアプリケーションの場合、インストールをブロックすることもできます。

モバイルデバイス管理

MDMまたはモバイルデバイス管理は、モバイルデバイス上での制御とセキュリティ要件を確保するために使用されるソフトウェアスイートです。これらのスイートは、デバイス管理APIと呼ばれる機能を使用し、Androidアプリのインストールが必要です。

一般的に、MDMソリューションはパスワードポリシーの強制、ストレージの暗号化の強制、デバイスデータのリモートワイプの有効化などの機能を実行します。

HackenProofはすべての暗号バグバウンティの場所です。

遅延なしで報酬を受け取る
HackenProofのバウンティは、顧客が報酬予算を入金した後に開始されます。バグが検証された後に報酬を受け取ることができます。

Web3ペントestingの経験を積む
ブロックチェーンプロトコルとスマートコントラクトは新しいインターネットです！成長するWeb3セキュリティをマスターしましょう。

Web3ハッカーレジェンドになる
各検証済みのバグで