Zenn
📑

OWASP Mobile Top 10 (2024年版) の要点まとめ

2024/02/02に公開
Android
iOS
Security
スマートフォン
モバイルアプリ
tech

はじめに

先日(2024年1月21日)、「OWASP Mobile Top 10」の最新版となる2024年版が公開されました。

https://github.com/OWASP/www-project-mobile-top-10/releases/tag/v1.0

「OWASP Mobile Top 10」は、OWASP(Open Web Application Security Project)が公開する"Top 10"プロジェクトの一つで、モバイルアプリの開発者に対してセキュリティ意識の向上を促すことを目的とした文書です。モバイルアプリを開発する上で注意しなければならないセキュリティリスク10項目がリストアップされており、モバイルアプリの開発者なら一度は目を通しておくべき資料といえるでしょう。

しかし、リストアップされている項目は10件のみとはいえ、1つ1つを見ていくとかなりボリュームがあることに気づきます。また、セキュリティに明るくない方には一読では理解しづらい個所もあるように思います。(オリジナルは英語ですし…)

そこで本記事では、セキュリティに詳しくない方でもサッとその内容を理解できるよう「OWASP Mobile Top 10 (2024年版)」の要点をまとめてみたいと思います。本記事の内容を参考に、モバイルアプリが直面する最新のセキュリティリスクへの理解を深め、より安全性の高いモバイルアプリの開発に役立てていただければ幸いです。

前置き

本記事では、セキュリティに詳しくない方でも内容を理解できるよう、オリジナルの文章から要点となる一部のみを抜粋し、必要に応じて表現を補足しています。そのため、オリジナルの文章をそのまま日本語訳した内容になっているわけではないという点をご留意ください。

なお、オリジナルの文章が意図する内容に沿った解説となるよう十分注意していますが、もし誤った表現や理解が含まれているようでしたら、コメント等でお知らせいただけますと幸いです。

OWASP Mobile Top 10 (2024年版) 各項目とその概要

「OWASP Mobile Top 10 (2024年版)」にリストアップされた10項目と、そのざっくりとした概要を以下に記載します。まずはこちらを参考に、どのような項目が列挙されているのかイメージを掴んでいただければと思います。

※項目名から内容を何となくイメージできる方は、この章は読み飛ばしていただいて構いません。

  1. M1: Improper Credential Usage (クレデンシャルの不適切な使用)
    これは、APIキーやクラウドサービスのクレデンシャルなどの重要情報に対して、十分な保護措置がとられていない場合に発生しうるリスクについて記載された項目です。
    モバイルアプリがクレデンシャル情報を適切に扱っていない場合、そのクレデンシャル情報を攻撃者に窃取され、正規利用者になりすましてサービスを悪用される恐れがあります。

  2. M2: Inadequate Supply Chain Security (不十分なサプライチェーンセキュリティ)
    これは、モバイルアプリの開発～リリースに至るまでのサプライチェーンプロセスにおいて、開発コードや利用するサードパーティ製ライブラリの検証が十分に行われていない場合に発生しうるリスクについて記載された項目です。
    サプライチェーンプロセスが適切に監視されていない場合、悪意のある内部関係者やサードパーティ製ライブラリにより不正な機能がアプリ内に注入され、利用者の機密情報が漏えいしたり、アプリやデバイスを不正に制御される等の被害が発生する恐れがあります。

  3. M3: Insecure Authentication/Authorization (安全でない認証/認可制御)
    これは、モバイルアプリが行う認証/認可制御が適切に実装されていない場合に発生しうるリスクについて記載された項目です。
    認証/認可制御が適切に実装されていない場合、正規利用者になりすました攻撃者によってサービスを不正に利用されたり、本来、対象のユーザでは利用できないはずの機能を利用されてしまうといった被害が生じる恐れがあります。

  4. M4: Insufficient Input/Output Validation (不十分な入力/出力値検証)
    これは、ユーザから入力された値やサーバから出力される値に対して、十分な検証処理が実施されていない場合に発生しうるリスクについて記載された項目です。
    モバイルアプリおよび通信するサーバ側で、入力/出力値検証とサニタイズが適切に行われていない場合、SQLインジェクションやクロスサイトスクリプティング(XSS)等の脆弱性を生み、攻撃を受ける恐れがあります。

  5. M5: Insecure Communication (安全でない通信)
    これは、モバイルアプリが行う通信が平文で送信されていたり、非推奨の暗号化プロトコルが使用されていたりする場合に発生しうるリスクについて記載された項目です。
    安全でない通信を行うモバイルアプリでは、攻撃者による通信の盗聴等により、ユーザが入力した機密情報が漏えいしたり、通信の内容を改ざんされる恐れがあります。

  6. M6: Inadequate Privacy Controls (不十分なプライバシー管理)
    これは、ユーザがモバイルアプリを利用するうえで入力した個人情報が、十分に保護されていない場合に発生しうるリスクについて記載された項目です。
    モバイルアプリにおいて個人情報が適切に保護されていない場合、攻撃者にユーザの個人情報が漏えいし、ユーザに被害が及ぶことに加え、アプリ提供元企業としての信頼を損なう等の被害が発生する恐れがあります。

  7. M7: Insufficient Binary Protections (不十分なバイナリ保護)
    これは、モバイルデバイス内にインストールされるアプリの実行ファイルに対して、十分な保護措置がとられていない場合に発生しうるリスクについて記載された項目です。
    実行ファイルに対する保護が不十分な場合、攻撃者はリバースエンジニアリングによって、実行ファイル内にハードコードされた重要情報を収集したり、ビジネスロジックを分析することで攻撃の足掛かりとなる情報を得ることができます。また、正規のアプリを改変した偽アプリを配布し、不正に利益を横取りされる恐れがあります。

  8. M8: Security Misconfiguration (セキュリティの誤設定)
    これは、モバイルアプリのセキュリティ上の設定ミス(安全でない通信プロトコルの使用や、不要なパーミッションの付与、コンポーネントのアクセス設定不備など)がある場合に発生しうるリスクについて記載された項目です。
    モバイルアプリにおいて設定ミスがある場合、攻撃者からそのミスにつけこんだ攻撃を受け、被害を受ける恐れがあります。

  9. M9: Insecure Data Storage (安全でないデータストレージ)
    これは、モバイルアプリが扱うデータに対して、十分な保護措置がとられていない場合に発生しうるリスクについて記載された項目です。
    扱うデータに対する保護が十分でない場合、ユーザが入力した重要情報が漏えいし、ユーザに被害が及ぶことに加え、アプリを提供する企業としての信頼を損なう等の被害が発生する恐れがあります。

  10. M10: Insufficient Cryptography (不十分な暗号化)
    これは、モバイルアプリが扱うデータに対して、適切な暗号化処理(暗号化アルゴリズムの選択や鍵管理等)が行われていない場合に発生しうるリスクについて記載された項目です。
    暗号化処理に不備がある場合、攻撃者によってデータを復号され、ユーザが入力した重要情報が漏えいする恐れがあります。

2024年版の要点

前版との比較から、2024年版の要点について考察を進めていきたいと思います。
前版の「OWASP Mobile Top 10」が公開されたのは2016年なので、今回、実に約8年ぶりの更新となりました。年々新しい技術や手法が導入されるITの世界、とりわけ変化が激しいモバイルアプリ界隈において、8年も経てば取り巻く状況も大きく変わります。それに伴って、Top 10 にリストアップされるセキュリティリスクも、以下のように変動しました。


Comparison between 2016 and 2024 (「OWASP Mobile Top 10」より抜粋)

このなかでまず目を引くのは、「New」と表示されている4件の新規追加項目です。特に以下の2件は、昨今のモバイルアプリ開発の状況に伴って、新たにクローズアップされている問題といえるでしょう。

  • M1: Improper Credential Usage (不適切なクレデンシャルの使用)
  • M2: Inadequate Supply Chain Security (不十分なサプライチェーンセキュリティ)

以前に比べて、商用環境におけるクラウドの利用は格段に進み、サービスの垣根を越えて多様なAPIが利用されるケースも増えました。しかし、それに伴ってクレデンシャルの管理の問題が表面化し、脆弱性としての報告も増加の一途をたどっています。クレデンシャルが漏えいした際に生じる被害の大きさもふまえ、今回のTop10では「Improper Credential Usage」が一気に1位に躍り出たものと考えられます。

また近年、サプライチェーンをどのように管理・監視していくかは、モバイルアプリに限らず、システム開発全般で課題とされるテーマの一つといえます。先日公開されたIPAの「情報セキュリティ10大脅威 2024」の"組織向け脅威"でも2位にランクインしており、今後も重要課題として選出が続くのではないかと推測されます。

その他の新規追加項目である以下2件は、今回新しくランクインした項目ではあるものの、内容的には以前から取り上げられていた問題と言えるかと思います。新しく選出された理由はOWASPから明示されていないので分かりませんが、Top10プロジェクトでは脆弱性として報告された件数や影響度を考慮してランキングを作成しているということなので、近年これらの脆弱性をターゲットとした攻撃が増えている、ということなのかもしれません。

  • M4: Insufficient Input/Output Validation (不十分な入力値検証)
  • M6: Inadequate Privacy Controls (不十分なプライバシーコントロール)

その他の既存項目は、モバイルアプリのセキュリティを考える上で、もはやおなじみといえるセキュリティリスクですが、まだランクインが続いている以上、今後も注意が必要でしょう。

本記事では、新規追加項目について、次の章でもう少し詳細に内容を解説していきます。
2016年版からの既存項目については、株式会社ラックの有志の方々がまとめてくださった日本語訳ドキュメントがありますので、そちらをご参照いただければと思います。

https://github.com/LAC-Japan/OWASP-Mobile-Top-10-2016

新規追加された項目のポイント

以下は、新規追加された4項目について、オリジナルの文章からポイントとなる部分を抜粋し、より分かりやすい文章となるよう補足した解説です。

M1: Improper Credential Usage (クレデンシャルの不適切な使用)

これは、APIキーやクラウドサービスのクレデンシャルなどの重要情報に対して、十分な保護措置がとられていない場合に発生しうるリスクについて記載された項目です。

モバイルアプリが、以下のようにクレデンシャル情報を不適切に扱っている場合、そのクレデンシャル情報を攻撃者に窃取され、正規利用者になりすましてサービスを悪用される恐れがあります。

  • モバイルアプリのソースコードまたは設定ファイル内にハードコードされたクレデンシャル情報が含まれている。
  • クレデンシャル情報が暗号化されずに、あるいは安全でないチャネルを通じて送信されている。
  • モバイルアプリがデバイスのストレージにクレデンシャルを保存する際に平文で保存している、あるいは、暗号化しているものの第三者から復号可能な方法で暗号化したうえで保存している。
  • ユーザー認証が脆弱なプロトコルに依存している、あるいは簡単に迂回できる。

攻撃シナリオ

このタイプのセキュリティリスクを悪用する攻撃シナリオとしては、以下のような例が考えられます。

  • ハードコードされたクレデンシャル
    攻撃者はリバースエンジニアリングにより、モバイルアプリのソースコードや設定ファイル内にハードコードされたクレデンシャルを発見する。攻撃者は得られたクレデンシャルを使用して、アプリまたはバックエンドシステム内の機密機能に不正にアクセスする。

  • 安全でないクレデンシャルの送信
    攻撃者はモバイルアプリとそのバックエンドシステム間で安全に送信されていないクレデンシャルを盗聴する。攻撃者は盗聴によって得られたクレデンシャルを使用して、正当なユーザになりすまし、不正アクセスを行う。

  • 安全でないクレデンシャルの保管
    攻撃者がユーザーのデバイスに物理的にアクセスし、モバイルアプリのストレージに保存されているクレデンシャルを抜き取る。攻撃者は抜き取ったクレデンシャルを使用して、ユーザーのアカウントに不正アクセスする。

対策

モバイルアプリが利用するクレデンシャルを、以下のように適切に扱うことが必要です。

  • クレデンシャルをハードコードしない。
  • 送信時にクレデンシャルを暗号化する。
  • クレデンシャルをデバイスに保存しない。代わりに、安全で取り消し可能なアクセストークンの使用を検討する。
  • 強力なユーザー認証プロトコルを実装する。
  • 使用するAPI キーまたはトークンを定期的に更新し、ローテーションする。

オリジナルはこちら

M2: Inadequate Supply Chain Security (不十分なサプライチェーンセキュリティ)

これは、モバイルアプリの開発～リリースに至るまでのサプライチェーンプロセスにおいて、アプリの開発コードや利用するサードパーティ製ライブラリに対して、セキュリティ上の欠陥がないか十分に検証されないままアプリがリリースされた場合に発生しうるリスクについて記載された項目です。

モバイルアプリの開発時に、コードレビューやテスト等によってサプライチェーンプロセスが適切に監視されていない場合、以下のような経緯により不正な機能がアプリ内に注入され、利用者の機密情報が漏えいしたり、アプリやデバイスを不正に制御される等の被害が発生する恐れがあります。

  • 悪意のある内部関係者(アプリの開発エンジニアや開発下請け業者等)によって、意図的に不正な機能が注入される。
  • アプリが利用するサードパーティライブラリに、あらかじめ不正な機能が注入されている。

攻撃シナリオ

このタイプのセキュリティリスクを悪用する攻撃シナリオとしては、以下のような例が考えられます。

  • 不正な機能の注入
    攻撃者(不正な開発者やサプライヤのような悪意のある内部関係者)が、モバイルアプリの開発段階で、不正な機能(ユーザの機密情報を盗み出す機能)を含んだコードを注入する。その後、レビューやテストの段階で不正なコードが取り除かれることなく、アプリストアから公開される。ユーザーがこのアプリをインストールし、ログイン認証情報やその他の機密データを入力すると、攻撃者が注入した不正な機能によって、それらのデータが漏えいする。その後、攻撃者は盗んだデータを使って詐欺やなりすましを行い、被害者に大きな損害を与え、アプリ提供者に風評被害をもたらす。

対策

アプリのリリースに至るまでのサプライチェーンプロセスにおいて、不正な機能が注入されることがないよう、以下のように適切な管理を行うことが必要です。

  • モバイルアプリの開発ライフサイクルを通じて、セキュアなコーディングの実践、コードレビュー、テストを実施し、脆弱性を特定して緩和する。
  • 攻撃者による悪意のあるコードの署名と配布を防ぐために、安全なアプリの署名と配布プロセスを確保する。
  • 脆弱性のリスクを低減するために、信頼され検証されたサードパーティのライブラリまたはコンポーネントのみを使用する。
  • 攻撃者がアプリの脆弱性を悪用することを防止するために、アプリの更新、パッチ、リリースのセキュリティ管理を確立する。
  • サプライチェーンのセキュリティインシデントを、セキュリティテスト、スキャニング、その他の技法を通じて監視・検出し、インシデントをタイムリーに検出・対応する。

オリジナルはこちら

M4: Insufficient Input/Output Validation (不十分な入力/出力値検証)

これは、ユーザから入力された値やサーバから出力される値に対して、十分な検証処理が実施されていない場合に発生しうるリスクについて記載された項目です。

モバイルアプリおよび通信するサーバ側で、以下のように入力/出力値検証とサニタイズが適切に行われていない場合、SQLインジェクションやコマンドインジェクション、クロスサイトスクリプティング(XSS)等の深刻な脆弱性を生み、攻撃を受ける恐れがあります。

  • ユーザから入力された値が適切にチェックされない場合、攻撃者は悪意のあるデータを入力することによって、アプリ側で想定していない挙動を引き起こすことができる。これは、コード実行の脆弱性や不正なシステムアクセスにつながる可能性がある。

  • 出力データが適切に検証され、サニタイズされていない場合、攻撃者は悪意のあるスクリプトを注入し、ユーザーのブラウザやWebView上で実行させることができる。これはXSS攻撃につながり、データの盗難、セッションハイジャック、または表示されたコンテンツの操作を可能にする。

  • 特定のコンテキストや期待されるデータ形式を考慮しないと、SQLインジェクションやフォーマット文字列を悪用する脆弱性が発生する可能性がある。これらは、検証されていないユーザー入力がデータベースクエリに直接組み込まれたり、フォーマット文字列関数で不適切に処理されたりすることで発生し、攻撃者にクエリの操作や任意のコードの実行を許してしまう。

  • データの完全性を検証しないと、アプリはデータの破損や不正な処理の影響を受けやすくなる。攻撃者は、重要なシステム変数を改ざんしたり、アプリの機能を破壊する不正なデータを持ち込むことができる。

攻撃シナリオ

このタイプのセキュリティリスクを悪用する攻撃シナリオとしては、以下のような例が考えられます。

  • 悪意のある入力によるリモートコード実行
    攻撃者は、適切な入力検証とサニタイズが行われていないモバイルアプリを特定し、想定外の文字を含む悪意のある入力を行うことでアプリの動作を悪用する。検証が不十分なため、アプリは入力を誤って処理し、脆弱性につながる。攻撃者は任意のコードの実行に成功し、デバイスのリソースと機密データへの不正アクセスを獲得する。

  • 不十分な出力検証によるインジェクション攻撃
    攻撃者は、出力検証とサニタイズが不十分なモバイルアプリを特定し、コードやスクリプト(HTML、JavaScript、SQLなど)を含む悪意のある入力を作成することで、出力検証の欠如を利用する。細工された入力を送信すると、アプリケーションはその入力を検証またはサニタイズすることに失敗し、注入されたコードや意図しない操作の実行を許してしまう。攻撃者はXSSや SQLインジェクションのようなインジェクション・ベースの攻撃を成功させ、アプリの完全性を損ない、機密情報へのアクセスを獲得する。

  • 不正な出力を介したリモートコード実行
    攻撃者は、ユーザから提供されたデータに基づいて動的な出力を生成するモバイルアプリを特定し、不正なデータをそのアプリから送信する。アプリは生成された出力の適切な検証やサニタイズに失敗し、攻撃者の細工したデータによるコードの実行や意図しないアクションのトリガを許してしまう。この脆弱性を悪用することで、攻撃者はリモートでコードを実行し、モバイルデバイスやそのリソース、あるいは機密データを制御できるようになる。

対策

攻撃者によって操作された入出力値がアプリ側で想定していない挙動を引き起こさないよう、以下のように適切な入出力値検証を行うことが必要です。

  • 厳密な検証技術を使ってユーザから入力された値を検証し、必要に応じてサニタイズする。入力の長さを制限し、予期しないデータや悪意のあるデータを拒否する。

  • XSS攻撃を防ぐために、サーバから出力されたデータを適切にサニタイズする。データを表示または送信する際には、出力エンコーディング技術を使用する。

  • パストラバーサルやインジェクションなどの攻撃を防ぐために、データのコンテキスト（ファイルのアップロード、データベースクエリなど）に基づいた特定の検証を行う。

  • データの破損や不正な改変を検出・防止するために、データの整合性チェックを実施する。

  • SQLインジェクションを防ぐために、パラメータ化されたクエリやプリペアドステートメントを使用するなど、安全なコーディングプラクティスに従う。

  • 侵入テストやコードレビューなどのセキュリティ評価を定期的に実施することで脆弱性を特定し、対処する。

オリジナルはこちら

M6: Inadequate Privacy Controls (不十分なプライバシーコントロール)

これは、ユーザがモバイルアプリを利用するうえで入力した個人情報(氏名や住所、クレジットカード情報、電子メールやIPアドレス、健康、宗教、セクシュアリティ、政治的意見等)が、十分に保護されていない場合に発生しうるリスクについて記載された項目です。

モバイルアプリにおいて個人情報が適切に保護されていない場合、以下のような手法により攻撃者にユーザの個人情報が漏えいし、モバイルアプリ自体だけでなく、アプリの提供元企業の信頼を損なう等、深刻な被害が発生する恐れがあります。

  • ネットワーク通信を盗聴する。
  • トロイの木馬を使ってファイルシステム、クリップボード、ログにアクセスする。
  • モバイルデバイスを入手してバックアップを作成し、得られたデータを分析する。

攻撃シナリオ

このタイプのセキュリティリスクを悪用する攻撃シナリオとしては、以下のような例が考えられます。

  • ログとエラーメッセージのサニタイズが不十分
    ログやエラーメッセージの出力は、生産性の高いアプリの品質保証に不可欠だが、出力される内容には個人情報が含まれる可能性がある。(サードパーティのライブラリから出力されるケースも考えられる) よくある問題の例として、クエリや結果の一部を明らかにするデータベースの例外がある。これは、クラッシュ・レポートの収集と評価に使用されるプラットフォーム・プロバイダに見える可能性が高い。また、エラーが画面に表示された場合、ユーザーや、デバイスのログを読むことができる攻撃者にも見えてしまう恐れがある。開発者は、ログに記録する内容に特に注意し、例外メッセージをユーザーに表示したり、サーバーに報告したりする前に、確実にサニタイズする必要がある。

  • URL クエリパラメータに個人情報を使用する
    URLクエリパラメータは、リクエストの引数をサーバに送信するためによく使われるが、URLクエリパラメータは、少なくともサーバーのログから見えるだけでなく、多くの場合、ウェブサイト分析やローカルブラウザの履歴からも見える可能性がある。そのため、機密情報をクエリパラメータとして送信すべきではない。代わりに、ヘッダーやボディの一部として送信する必要がある。

  • 個人情報をバックアップから取得する
    アプリによって処理されるほとんどの個人情報はデバイスのサンドボックス内に保存される。アプリはどのデータをデバイスのバックアップに含めるかを明示的に設定する必要がある。攻撃者はデバイスを入手し、バックアップを作成するか、別のソースからバックアップを取得し、そこからサンドボックスのコンテンツを抽出する可能性がある。

対策

モバイルアプリからユーザの個人情報が漏えいしないよう、以下のように適切なプライバシーコントロールを行うことが必要です。

  • アプリが必要とするユーザの個人情報をすべて把握したうえで、処理される個人情報の量と種類を必要最小限に抑える。あるいは、個人情報の一部を、より重要度の低い情報に置き換える(例えば、細かい位置情報を粗い位置情報で置き換える)。
    絶対に必要な個人情報は、適切な認証と場合によっては権限付与によって保護されなければならない。また、特に重要なデータについては、深層防御を考慮すべきである。

  • 脅威モデリングを行うことで、アプリからプライバシー侵害が発生する可能性が最も高い経路を特定し、個人情報を保護できるよう対策を集中する。

  • 静的および動的なセキュリティチェックツールを利用し、機密データのロギング、クリップボードやURLクエリパラメータへの漏えいのような一般的な落とし穴を明らかにする。

オリジナルはこちら

まとめ

ここまで、OWASP Mobile Top 10 (2024年版) の要点を解説してみましたが、いかがでしたでしょうか。今回は久々のリリースということもあり、見慣れたセキュリティリスクだけでなく、時勢を汲んで新しくランクインするセキュリティリスクもありました。そういった新しい問題を見落とさず、タイムリーに対処するには、本記事で扱った「OWASP Mobile Top 10」のように各セキュリティ団体や企業、組織がリリースする情報が非常に有用です。モバイルアプリをセキュアに保つために、アンテナを高く張り、必要な情報を得られるよう習慣づけできると良いかと思います。

本記事は、オリジナルの文章をもとに、可能な限り誤解を生まないよう慎重に記載しましたが、もしかしたら情報の抜け漏れや誤った理解が含まれているかもしれません。恐れ入りますが、そのような記載がありましたら、コメント等でお知らせ頂けますと幸いです。

最後に、長文となりましたが、本記事をお読みいただきありがとうございました。

Discussion