モバイル Agentic Deep Scan のレポートをご覧ください

OWASP のトレーニングで使われる、意図的に脆弱性を持たせた Android アプリ AndroGoat のスキャンの、編集なしの完全なレポートです。各検出事項が脆弱なコードまで追跡され、実証され、修正される様子がわかります。

対象
AndroGoat(Android)
スキャン
Mobile Agentic Deep Scan
ページ数
200 ページ
結果
全体のリスク: 高

意図的に脆弱性を持たせたトレーニング用アプリで実施しています。顧客データは含まれていません。

脆弱なコードを含む検出事項手法表紙とリスク評価

レポートの内容

範囲と背景

検出事項の前に、何をどのようにテストしたか、アプリが何をするかを説明しています。

エグゼクティブサマリー

安全でないデータ保存からインジェクションまで、主なリスクをわかりやすく説明しています。

コードレベルの検出事項

各検出事項について、根本原因、脆弱なコード、悪用の証拠を示しています。

検証と修正

2 回目の確認で各検出事項を検証し、推奨される修正方法と参考資料を示しています。

解説付きの検出事項

1つの検出事項をステップごとに

レポートが1つの検出事項を、テストした正確なビルドから修正まで、どのように扱うかを示します。各ステップに、完全版レポートの該当ページを記載しています。

  1. ビルド

    AndroGoat 1.0 (1)、パッケージ owasp.sat.agoat

    レポートはSHA-256ハッシュで対象のAPKを特定し、公開されているAndroGoatリポジトリのコミット 1f38398 と照合しています。

    レポート 2 ページ
  2. デバイス

    Android 11 エミュレーター

    動的テストはroot権限付きのAndroid 11(API 30)エミュレーターで実行し、エージェントがアプリをインストールして起動しました。

    レポート 7 ページ
  3. スコープ

    Androidアプリのみ、テスト用認証情報なし

    2026年5月19日〜20日に実行したAPKのMobile Agentic Deep Scanです。iOS、バックエンドAPI、Webコンポーネントはスコープ外です。

    レポート 2 ページ
  4. フロー

    アプリ自体のログイン画面

    AndroGoatにはサーバーがなく、ログイン画面とPIN画面は端末上で動作します。エージェントは、これらの画面が入力されたユーザー名とパスワードをどう扱うかを追跡しました。

    レポート 27 ページ
  5. 検出事項

    高:認証情報の平文保存

    ユーザー名とパスワードが、SharedPreferences、SQLiteデータベース、一時ファイルに平文で書き込まれ、その1つは共有ストレージ上にあります。バックアップも有効になっています。

    レポート 27 ページ
  6. エビデンス

    別のユーザーが読み取れる認証情報ファイル

    レポートは脆弱なコードを示したうえで、実行時の証拠を示しています。SDカード上の認証情報ファイルを別のユーザーとして読み取ると、内容がすべて平文で取得できました。

    レポート 8 ページ
  7. 修正

    暗号化し、認証情報を共有ストレージに置かない

    すぐにバックアップを無効にし、保存データを暗号化します。恒久的な修正では、認証情報をKeyStoreを利用するEncryptedSharedPreferencesに移行します。コード例付きです。

    レポート 29 ページ
  8. 検証

    修正を確認する方法

    逆コンパイルしたアプリで、ストレージ呼び出しに平文の認証情報が渡されていないか検索し、adbバックアップで読み取り可能な認証情報ファイルが出てこないことを確認します。

    レポート 29 ページ

エージェントの判断

リスクと判断した理由

スキャナーはルールに一致したものをすべて報告します。エージェントは報告する前に、手がかりが実際の被害につながるかを確かめます。AndroGoat アプリで見つかった手がかりについて、エージェントがどう判断したかを示します。

  1. ステップ 1

    このアドレスはアプリの中で何をしているのか?

    アプリのリソース res/values/strings.xml に、Firebase データベースのアドレス androgoat-42597.firebaseio.com が含まれていました。

    レポート 79 ページ
  2. ステップ 2

    アプリは実際にそれを使っているのか?

    いいえ。Firebase ライブラリはなく、この値を読み込むコードもありません。ルールベースのチェックなら、使われていない残骸として片付けて先に進むところです。

    レポート 10 ページ
  3. ステップ 3

    データベース自体は公開されているのか?

    エージェントはログインせずにデータベースへリクエストを 1 回送りました。200 OK が返り、ユーザー名とパスワードが含まれていました。

    レポート 80 ページ
  4. ステップ 4

    では、リスクなのか?

    はい、高(High)です。アプリがアドレスを使っていなくても関係ありません。アプリを展開すれば誰でもデータベースを見つけ、アカウントなしで読み取れます。

    レポート 41 ページ
  5. ステップ 5

    どう修正するか?

    Firebase Authentication とセキュリティルールを有効にして、データベースの読み取りにログイン済みユーザーを必須にし、使われていないアドレスをアプリから削除します。

    レポート 41 ページ

自社アプリでこのレポートを作成しませんか?

デモをご予約いただければ、お客様のモバイルアプリ、Web アプリ、API のスキャンをご案内します。