OWASPMobileの実際のケースでのトップ10のリスクを理解する

公開: 2020-01-28

100％ハッキングプルーフアプリケーションを開発した業界記録を保持することには、私たちの名前で開発されたデジタルソリューションのいずれもセキュリティ違反に直面しないという責任とベースライン保証が伴います。

これを実現する方法として、Appinventivの品質保証チームは、アプリが直面する可能性のあるすべてのセキュリティリスクに精通しています。 リスクを知ることで、落とし穴を無視して安全なアプリを簡単に作成できます。

セキュリティを確保することに関して、私たちがゲームのトップに立つのを助けることは、 OWASPの安全なコーディング慣行（Open Web Application Security Project）の完全な知識を持っていることです。 これは、安全なモバイルおよびWebアプリケーションを構築するための無料のドキュメント、学習資料、およびツールを開発したセキュリティスペシャリストのオンラインコミュニティです。

他のものとともに、彼らはモバイルアプリケーションにおけるOWASPモバイルトップ10のセキュリティ脅威のリストもまとめました。

OWASPセキュリティプラクティスドキュメントはかなり明確ですが、企業が実際のケースからそれを接続するのは難しい場合があります。

この記事では、モバイルセキュリティリスクのトップ10の基本的な概要を示し、それぞれについて実際に公開されている脆弱性の例を示します。 それは、私たちがあなたのアプリケーションに取り組むときに、Appinventivで私たちが何を準備するかについての洞察をあなたに与えるでしょう。

リスクを調べる前に、統計を調べてみましょう。

NowSecureはGooglePlayストアのアプリを調査し、App Storeは85％以上のアプリがリスクの1つに違反していることを特定しました。

これらのアプリケーションのうち、50％は安全でないデータストレージを使用しており、同じ数のアプリが安全でない通信リスクで動作していました。 これは、 OWASPモバイルのトップ10リスクの発生率を示すグラフです。

owasp mobile top 10 voilation rates

モバイルアプリケーションに対する10の最も一般的な脅威とそれらを回避するためのベストプラクティスのリスト

M1：不適切なプラットフォームの使用

OWASPセキュリティテストのカテゴリは、デバイス機能の誤用またはプラットフォームのセキュリティ制御を使用する際の障害のインスタンスで構成されます。 これには、プラットフォームの権限、Androidのインテント、TouchIDの誤用、キーチェーンなどが含まれる可能性があります。

実際のケース：

AppleのTouchIDをバイパスするために、「Fitness Balanceアプリ」、「Heart Rate Monitor」、「CaloriesTrackerアプリ」の3つのiOSアプリが登場しました。 彼らは、App Storeからの請求に指紋を使用しているときに、ユーザーに指紋を使用してフィットネス情報を取得するように求めていました。

避けるべきベストプラクティス：

  • 開発者は、サーバールートを介したキーチェーン暗号化を許可せず、キーを1つのデバイスにのみ保持する必要があります。これにより、他のサーバーやデバイスで悪用される可能性がなくなります。
  • 開発者は、専用のアクセス制御リストを持つアプリのシークレットを保存するために、キーチェーンを介してアプリを保護する必要があります。
  • 開発者は、アプリケーションとの通信を許可するアプリを制限する許可を得る必要があります。
  • 開発者は、明示的なインテントを定義し、インテントに存在する情報にアクセスする他のすべてのコンポーネントをブロックすることにより、OWASPモバイルトップ10リストの最初のリストを制御する必要があります。

M2：安全でないデータストレージ

OWASPは、誰かが紛失/盗難にあったモバイルデバイスにアクセスした場合、またはマルウェアや別の再パッケージ化されたアプリが攻撃者に代わって行動を開始し、モバイルデバイスでアクションを実行した場合に脅威と見なします。

安全でないデータストレージの脆弱性は、通常、次のリスクにつながります。

  • 詐欺
  • 個人情報の盗難
  • 材料の損失。
  • レピュテーションリスク
  • 外交政策違反（PCI）

実世界の事例：

Tinder、OKCupid、Bumbleなどの出会い系アプリは、安全でないデータストレージの慣行について何度も精査されてきました。 これらのアプリに存在するセキュリティの失効は、実現可能性、重大度、実現可能性によって異なり、他の個人アカウントアクティビティに加えて、ユーザーの名前、ログインの詳細、メッセージ履歴、さらには場所さえも公開する可能性があります。

避けるべきベストプラクティス：

  • iOSの場合、 OWASPのセキュリティ慣行では、iGoatなどの意図的に作成された脆弱なアプリを使用して、開発フレームワークとアプリを脅威モデル化することを推奨しています。 これは、 iOSアプリの開発者がAPIがアプリのプロセスと情報アセットをどのように処理するかを理解するのに役立ちます。
  • Androidアプリの開発者は、Android Debug Bridgeシェルを使用して、対象のアプリのファイル権限を確認し、DBMSを使用してデータベースの暗号化を確認できます。 また、メモリ分析ツールとAndroidデバイスモニターを使用して、デバイスのメモリに意図しないデータがないことを確認する必要があります。

M3：安全でない通信

モバイルアプリを考案する場合、データはクライアントサーバーモデルで交換されます。 したがって、データが送信されるときは、最初にデバイスのキャリアネットワークとインターネットを通過する必要があります。 脅威エージェントは、脆弱性を悪用し、有線で移動しているときに機密データを傍受する可能性があります。 存在するさまざまな脅威エージェントは次のとおりです。

  • ローカルネットワークを共有する攻撃者–侵害されたWi-Fi
  • ネットワークまたはキャリアデバイス–セルタワー、プロキシ、ルーターなど。
  • モバイルデバイス上のマルウェア。

通信チャネルを介した機密データの傍受は、プライバシー侵害につながり、次の原因となる可能性があります。

  • 個人情報の盗難
  • 詐欺
  • レピュテーションリスク。

実際のケース：

Rapid7のセキュリティ会社は、子供向けのスマートウォッチに付随するいくつかの脆弱性を明らかにしました。 これらの時計は、親が子供を追跡したり、メッセージを送信したり、スマートウォッチで電話をかけたりするために使用する時計として販売されていました。

時計はホワイトリストのモードを介して承認された連絡先番号によって連絡されることになっていたが、会社はフィルターが機能していないことを発見した。 時計は、テキストメッセージを介して構成コマンドも受け入れました。 これは、ハッカーが時計の設定を変更し、子供を危険にさらす可能性があることを意味しました。

Rapid7のIoTリサーチリーダーであるDeralHeilandは、次のように述べています。「電話や子供がどこにいるかを特定したり、音声にアクセスしたり、子供に電話をかけたりすることができます。

避けるべきベストプラクティス：

  • 開発者は、アプリとサーバーの間で通信されるトラフィックを介したリークだけでなく、アプリと他のデバイスまたはローカルネットワークを保持するデバイスも探す必要があります。

  • チャネルの転送にTLS / SSLを適用することも、機密情報やその他の機密データを送信する際に考慮すべきモバイルアプリのセキュリティのベストプラクティスの1つです。

  • 信頼できるSSLチェーン検証によって提供された証明書を使用します。
  • MMS、SMS、プッシュ通知などの代替チャネルを介して機密データを送信しないでください。
  • SSLチャネルに渡す前に、機密データに個別の暗号化レイヤーを適用します。

M4：安全でない認証

認証の脆弱性を悪用する脅威エージェントは、カスタムビルドまたは利用可能なツールを利用する自動攻撃を介して悪用します。

M4のビジネスへの影響は次のとおりです。

  • 情報の盗難
  • レピュテーションリスク
  • データへの不正アクセス。

実世界の事例：

2019年、米国の銀行は、銀行のWebサイトの欠陥を利用して、アカウントを保護するために実装された2要素認証を回避したサイバー攻撃者によってハッキングされました。

攻撃者は、盗まれた被害者の資格情報を介してシステムにログインし、PINまたはセキュリティの回答を入力する必要があるページに到達すると、コンピュータを認識されたものとして設定したWebURLの操作された文字列を使用しました。 これにより、彼はステージを越えて電信送金を開始することができました。

避けるべきベストプラクティス：

  • アプリのセキュリティチームは、アプリの認証を調査し、オフラインモードでバイナリ攻撃を介してテストし、悪用される可能性があるかどうかを判断する必要があります。
  • OWASP Webアプリケーションテストのセキュリティプロトコルは、モバイルアプリのプロトコルと一致する必要があります。
  • Webブラウザの場合と同様に、可能な限りオンライン認証方式を使用してください。
  • サーバーがユーザーセッションを認証するまで、アプリデータの読み込みを有効にしないでください。
  • ローカルデータが最終的に使用される場所では、ユーザーのログイン資格情報から派生した暗号化されたキーを使用して暗号化されていることを確認してください。
  • 永続的な認証要求もサーバーに保存する必要があります。
  • デバイスが盗まれた場合、アプリが脆弱になる可能性があるため、セキュリティチームはアプリ内のデバイス中心の認証トークンに注意する必要があります。
  • デバイスへの不正な物理アクセスは一般的であるため、セキュリティチームは、サーバー側から定期的なユーザー資格認証を実施する必要があります。

M5：暗号化のリスクが不十分

この場合の脅威エージェントは、誤って暗号化されたデータに物理的にアクセスできるエージェントです。 または、マルウェアが攻撃者に代わって行動している場合。

暗号化が壊れていると、一般的に次のような場合になります。

  • 情報の盗難
  • 知的財産の盗難
  • コードの盗難
  • プライバシー違反
  • レピュテーションリスク。

実世界の事例：

時々、DHS Industrial ControlSystemsのCyber​​Emergency Response TeamとPhilipsアドバイザリからのアラートが、 Philips HealthSuite HealthAndroidアプリの脆弱性の可能性についてユーザーに警告しました。

不十分な暗号化強度にまでさかのぼって追跡された問題は、ユーザーの心拍数活動、血圧、睡眠状態、体重および体組成分析などにアクセスできるハッカーにアプリを開放しました。

避けるべきベストプラクティス：

  • これを最も一般的に発生するOWASPトップ10モバイルリスクの1つを解決するには、開発者はアプリを暗号化するための最新の暗号化アルゴリズムを選択する必要があります。 アルゴリズムの選択により、脆弱性が大幅に処理されます。
  • 開発者がセキュリティの専門家でない場合は、独自の暗号化コードを作成しないようにする必要があります。

M6：安全でない承認リスク

この場合、脅威エージェントは通常、カスタムビルドまたは利用可能なツールを使用する自動攻撃を介して他の誰かのアプリケーションにアクセスできます。

次の問題が発生する可能性があります。

  • 情報の盗難
  • レピュテーションリスク
  • 詐欺

実世界の事例：

Pen Test Partnersの情報セキュリティスペシャリストは、スマートカーアラームシステムであるPandoraをハッキングしました。 理論的には、このアプリケーションは車を追跡し、盗まれた場合はエンジンを停止し、警察が到着するまでロックするために使用されます。

コインの反対側では、ハッカーがアカウントを乗っ取って、すべてのデータとスマートアラーム機能にアクセスできます。 さらに、次のことができます。

  • 車両の動きを追跡する
  • 警報システムの有効化と無効化
  • 車のドアをロックおよびロック解除する
  • エンジンを切る
  • Pandoraの場合、ハッカーは盗難防止システムのマイクを介して車内で話されているすべてのものにアクセスできました。

避けるべきベストプラクティス：

  • QAチームは、機密性の高いコマンドに対して低特権のセッショントークンを実行して、ユーザー特権を定期的にテストする必要があります。
  • 開発者は、オフラインモードでユーザー認証スキームがうまくいかないことに注意する必要があります。
  • このリスクを防ぐ最善の方法は、モバイルデバイスではなく、サーバーで認証されたユーザーのアクセス許可とロールの承認チェックを実行することです。

M7：不十分なコード品質リスク

このような場合、信頼できない入力は、エンティティによってモバイルコードで行われたメソッド呼び出しに渡されます。 この影響は、パフォーマンスの低下、メモリ使用量の多さ、フロントエンドアーキテクチャの動作不良につながる可能性のある技術的な問題になる可能性があります。

実世界の事例：

WhatsAppは昨年、ハッカーがスマートフォンにPegasusSpywareと呼ばれる監視マルウェアをインストールするために利用していた脆弱性にパッチを適用しました。 彼らがしなければならなかったのは、対象の電話番号にWhatsAppオーディオコールをかけることだけでした。

簡単な数ステップで、ハッカーはユーザーのデバイスに侵入し、リモートでアクセスすることができました。

避けるべきベストプラクティス：

  • OWASPの安全なコーディング慣行に従って、コードはサーバー側で修正するのではなく、モバイルデバイスで書き直す必要があります。 開発者は、サーバー側での不適切なコーディングは、クライアントレベルでの不適切なコーディングとは大きく異なることに注意する必要があります。 つまり、弱いサーバー側の制御とクライアント側の制御の両方に個別の注意を払う必要があります。
  • 開発者は、静的分析にサードパーティのツールを使用して、バッファオーバーフローとメモリリークを特定する必要があります。
  • チームはサードパーティのライブラリリストを作成し、定期的に新しいバージョンをチェックする必要があります。
  • 開発者は、すべてのクライアント入力を信頼できないものと見なし、ユーザーからのものかアプリからのものかに関係なく、それらを検証する必要があります。

M8：コード改ざんのリスク

通常、この場合、攻撃者はサードパーティのアプリストアでホストされている悪意のある形式のアプリを介してコードの変更を悪用します。 また、フィッシング攻撃を通じてユーザーをだましてアプリケーションをインストールさせる可能性もあります。

避けるべきベストプラクティス：

  • 開発者は、アプリが実行時にコードの変更を検出できることを確認する必要があります。
  • build.propファイルは、Androidに非公式ROMが存在するかどうかを確認し、デバイスがルート化されているかどうかを確認する必要があります。
  • 開発者は、チェックサムを使用してデジタル署名を評価し、ファイルの改ざんが行われたかどうかを確認する必要があります。
  • コーダーは、改ざんが見つかったら、アプリのキー、コード、データが削除されていることを確認できます。

M9：リバースエンジニアリングリスク

攻撃者は通常、対象のアプリをアプリストアからダウンロードし、さまざまなツールのスイートを使用してローカル環境内で分析します。 その後、コードを変更してアプリの機能を変えることができます。

実世界の事例：

ポケモンゴーは最近、ユーザーがアプリをリバースエンジニアリングしてポケモンの近くを知り、数分で捕まえることがわかったときに、セキュリティ違反の目線に直面しました。

避けるべきベストプラクティス：

  • OWASPモバイルセキュリティによると、リスクからアプリを保護するための最良の方法は、ハッカーがリバースエンジニアリングに使用するのと同じツールを使用することです。
  • また、開発者はソースコードを難読化して、読みにくくしてからリバースエンジニアリングを行う必要があります。

M10：外部機能リスク

通常、ハッカーは、バックエンドシステムに隠された機能を発見するために、モバイルアプリ内の無関係な機能を調べます。 攻撃者は、エンドユーザーの関与なしに、自身のシステムの無関係な機能を悪用します。

実世界の事例：

Wifiファイル転送アプリのアイデアは、Androidのポートを開き、コンピューターからの接続を許可することでした。 問題は？ パスワードなどの認証がないため、誰でもデバイスに接続してフルアクセスを取得できます。

避けるべきベストプラクティス：

  • 最終ビルドにテストコードがないことを確認します
  • 構成設定に隠しスイッチがないことを確認します
  • ログには、バックエンドサーバーのプロセスの説明を含めることはできません
  • 完全なシステムログがOEMによってアプリに公開されていないことを確認します
  • APIエンドポイントは十分に文書化されている必要があります。