自社製品のセキュリティ確保に取り組んでいます。製品のモバイルバージョンがあります。この質問はAndroidバージョン用です
背景-私たちの製品はSaaSベースの製品であり、このアプリはテナント組織のさまざまな営業担当者が使用することを目的としています。アプリの安全な(またはより安全な)環境を確保するために、さまざまな制御レイヤーを実装しました-
そしてリストは続く。つまり、デバイスから通信層、サーバー層に至るまで、隅々までカバーしています。
問題は、セキュリティ研究者の1人から報告された問題の1つです。私たちのアプリはAndroid Play Storeからダウンロードできるため、エミュレーターおよびエミュレーターで実行できるため、ルート検出をバイパスすることは可能ですので、それは大きな脅威を追加し、すぐに修正する必要があります。
検索しましたが、エミュレータにアプリをインストールできる場合に考えられるセキュリティ上の影響を見つけることができません。また、私はそれを修正する必要があるかどうかを確認しました、可能な解決策は何ですか?実行環境がSDKであるかどうかを確認するようなチェックがあります。カメラやセンサーなどの機能が機能しているかどうかをチェックしますが、これらのチェックはすべてエミュレータでもバイパスできます。
私がこの問題を受け入れた場合、クライアントはレポートでそれを確認し、修正を要求するため、それは私にとって一種の重要です。マネジメントと開発者に説明し(受け入れる場合)、修正しなければならない(後で必要になる可能性がある)ことを暗示する
更新-
全体の考えは、特定の事柄を制御できない場合、少なくとも悪意のあるパーティーを困難にすることができます。私たちの主な焦点は、ユーザーのデータを保護することであり、制御が実施され、進行中です。
また、ペンテスターからの更新-彼と話し合った後、彼はアプリケーションのセキュリティ要件を理解していないと述べました。彼によると、すべてのアプリにルート検出が必要です。これらのことは私たちにとって二次的なものであることを彼に説明しましたが、クライアント固有のデータが見えないところにあるか、アプリの設定ミスやアプリの脆弱性(ハードコードされたシークレットなど)のために危険にさらされる可能性がある場合、それはプライマリであることを説明しました。
皆さんから提供された情報に基づいて、この区別を明確にし、問題の解決を支援することができました。以前は、この問題のためにすべてノイズでした。ありがとうございます
そもそも、どのようなセキュリティ要件があるのかは不明であり、セキュリティ対策が十分かどうかは不明です。
ユーザーのデバイスを完全に制御できない限り、アプリケーションを使用して悪意のあるユーザーから完全に保護することはできません。このリスクには、エミュレーターでのアプリケーションの実行が含まれますが、ルート化されたデバイスまたは改ざんされたデバイスでの実行も含まれます。これらすべてが、使用するルート検出方法によって検出されるわけではありません。
代わりに、悪意のあるユーザーが自分や他のユーザーに害を及ぼすことはできず、自分だけに害を及ぼさないようにアプリケーションを設計する必要があります。これは、たとえば、アプリケーションにユーザー固有のシークレットを設定し、グローバルシークレットを使用しないことを意味します。これはまた、アプリケーションが報告するものを信頼するべきではなく、これが理にかなっているかどうかを検証する必要があることを意味します(つまり、ゲームなどで自己報告されたハイスコアを信頼しないでください)。
ここで心配しているセキュリティは誰ですか。また、何を保護しようとしていますか?他の人が自分のデータにアクセスできないようにユーザーを保護しようとしていますか?または、APIが安全でないためにアプリがどのように機能するかを見ようとするリバースエンジニアから会社を保護しようとしていますか?
純粋にユーザーのセキュリティを保護しようとしている場合は、ユーザーが安全性の低いアプリを実行すると思わない限り、VMでアプリを実行しても問題はありませんVMそして、それらのデータが盗まれる。これは非常に可能性が低く、問題であり、あなたのものではありません。
ユーザーがアプリをリバースエンジニアリングできないようにしようとしている場合は、ルートチェッカーが簡単にバイパスされるため、難しい戦いが繰り広げられています。アプリが安全に設計されていれば、アプリは攻撃者にとって何の役にも立たないので、これはほとんど無意味な作業です。
また、空白のレポートでは費やしたお金を正当化することが難しいため、セキュリティテストを実施する人が実際の問題を見つけられない場合は、問題以外の問題を補うこともあります。可能であれば、この声明に挑戦し、これが実際にどのように問題であるかの実例を挙げてもらいます。
クライアントへの古典的で正しい答えは[〜#〜] notanissue [〜#〜]です。
クライアント側のソフトウェアはありません* * everは、あなたの質問が尋ねる意味で、安全であると設計されていると見なされるべきです。彼らはできません。クライアント側のソフトウェアは、それがWebであろうとアプリであろうと、完全にクライアントの制御下にあり、その環境も同様です。ソフトウェアを書き直したり変更したり、検出できないほど安全ではない環境や変更された環境で実行したりする能力も同様です。それはバグではありません。それはモデルに固有 * *です。
さまざまなチェックの目的は、多くの場合セキュリティと同様に、リスクを減らして基準を引き上げることです。これはnotがクライアントを安全にするか、クライアント側のセキュリティを確保するために行われたものであり、その目的をクライアントが想定しているのは正しくありません。
私はここの行の間をよく読んでいますが、研究者がどこから来たのかがわかります。
アプリには、他の顧客のデータを公開する可能性のある秘密情報を保存(または使用)するビジネスはありません。
フロントエンドに与えられた秘密がバックエンドサービスへの区画化されたアクセスのみを与えるようにバックエンドを設計します。ユーザーがデバイスをルート化した場合、ハッキングできるのは自分のアカウントのみです。
ここでは、貧しい悪質なペンテスターを擁護する必要性を感じています。
このテスターは何をするために雇われたのですか?
アプリ開発者が、ルート検出がセキュリティ戦略の一部であると主張するホワイトペーパーまたはセキュリティ戦略などを提供した場合、ルート検出が公に利用可能なAPKのフィクションであることを指摘することは絶対に適切です。アーキテクチャ全体がクライアント側で実際に脆弱であり、制御されたデバイスでのみ実行する必要があるかどうか、または管理者が「セキュリティ機能」の可能な限り最大のリストを望んでいるかどうかを判断することは、一般にテスターの問題ではありません。彼または彼女は、提供された要求に対して失敗したと報告しているだけです(そのルート検出によりセキュリティが向上しています)。
「修正」とは、クライアント側の環境チェックがセキュリティのために何でも行うため、「セキュリティ機能」のより大きなリストを持つことができるという主張をやめることです。
この人が「プレイストアにいることは脆弱性である」と言っていることを暗示する表現は、OPのものではありません。 (私が言ったことを自分のキャリアで十分に間違った方法で間違って言い直した...!)
私は、クライアント側またはWebアプリケーションのいずれも、スタンドアロンで十分に安全であるとは見なしません。
クライアント側アプリケーション内に実装されているすべてのセキュリティレイヤー、検証、およびチェックは、アプリケーションサーバー側コンポーネント内の対応する、またはより強力な検証で少なくとも繰り返す必要があります。
さらに、エミュレーターを使用してアプリケーションを実行すると、エミュレーター自体の脆弱性がユーザーのセキュリティを損なう可能性があります。たとえば、一部の脆弱性により、攻撃者はリモートでコードを実行したり、情報開示したり、バックアップやデータを盗んだり、エミュレーターの内部にアクセスしたりできます。プロセス通信機能*。
ハードウェアデバイスまたはエミュレーターで実行されているJVMの違いはほとんどありません。もちろん、OSビルド文字列が「汎用」(エミュレータのみが持つ)であるかどうかを確認してから、それがリリースビルドの場合にアプリケーションを終了することができます。逆コンパイル-そして、コード署名のみがある程度機能の変更を防ぎます)。また、リリースビルドはdebuggable
として構成されていません。
重要なのは、ルート化されたデバイスで実行できない場合、(ルート化された)エミュレーターでは実行されないということです。
明らかな論理ペンテストホールがあるため、信頼できるルート検出は不可能です。
ユーザーがapkにアクセスできる場合、ユーザーはapkを分析して、サーバーのAPIを直接呼び出すこともできます。 アプリケーションを完全にバイパスする または、アプリケーションを別のシステムに移植します。ルート化されたデバイスで実行されているかどうかを検出するためにシステムを保護する戦略の一部である場合、セキュリティに対する全体的なアプローチを再考する必要があります。 何が実行されているかを確実に知ることさえできません。
ユーザーは、アプリケーションを逆コンパイルしたい場合、最初にすべての検出部分をアプリケーションから取り除くだけで済みます。プロセスは、ソフトウェアの「クラッキング」とまったく同じです。
ルート検出でできることは、ユーザーへのセキュリティ警告として、自分の電話がルート化されているとユーザーに通知することです。おそらく、ユーザーが知らないうちに電話がルート化されている可能性があります。しかし、そのような場合でもそれを信頼することはできません。それが実際のハードウェアであるかどうか、実行しているのかどうかはわかりません。サムスンを支払うことでシステムの基本的なルート権限を獲得できるknoxなどのシステムで実行されているかどうかはわかりません(エンタープライズ機能を介して-そしてはい、基本的には他のアプリケーションや他のアプリケーションコンポーネントを混乱させるためのルートのような権限を与えることができます) -電話はそれでもknoxセキュアとして表示され、ルート化されません)。
ルート検出などは通常、ハッキングを阻止するためのアプリケーションになりますが、問題を解決するための100%間違ったアプローチです。申し訳ありませんが、必要なのは、セキュリティに関する組織の文化的な考え方の変更です。他の場所で実行されているソフトウェアを信頼できないため、それに対して不満を募らせても意味がありません。
編集:上司に説明する方法が必要な場合は、次のことを試してみてください。「これを行うことができれば、コード全体は会社全体の価値よりも価値がある」-そしてその引用はあなたがグーグルで働いていたとしてもあなたの会社にまだ適用されます。
アプリの重要なセキュリティ機能として「ルート検出」を挙げました。
私自身はセキュリティの専門家なので、ルート検出は簡単に回避できると指摘します。仮想マシンだけでなく、物理デバイスにも。ルート検出を行うと主張する多くのフレームワークは、多くのルート化されたデバイスを検出せず、いくつかの通常のデバイスをルート化されたものとして検出します。たとえそうであっても、アプリケーションのクライアント側は簡単にリバースエンジニアリングできます。やる気のある攻撃者は、クライアント側アプリを完全にバイパスしてバックエンドインターフェースにアクセスできます。これは、クライアント側のチェックをバイパスし、計算をいじることができることを意味します。クライアント側のチェックや計算は信頼できません。
信頼できるクライアントを作成することは可能ですが、専用のハードウェア、専用のオペレーティングシステム、およびソフトウェアが必要です。ゲームコンソールとケーブルネットワークはそれを行いますが、デバイスの改ざん防止がいかに難しいかを示す好例として数えられるべき著作権侵害で依然として多くの問題を抱えています。この戦略は理論的には可能ですが、コストがかかりすぎて、競争の前で弱く時代遅れになる製品機能への投資を盗み、防ぐため、実際には失敗します。
安全で安全なアプリというものはありません。セキュリティとは、リスク、リスクの可能性と損失の大きさを理解し、不測の事態と緩和戦略を特定して、健全な利益率を維持することです。あなたが尋ねるべき質問は次のとおりです。
攻撃者が仮想環境にアプリをインストールできる可能性に悩まされているようです。セキュリティチェックと重要な計算の多くはクライアント側にあると思います。その場合は、すべてのコントロールをサーバー側に移動するようにアプリを再設計する必要があります。
ユーザーネットワークに公開されるバックエンドインターフェイスAPIは、ユーザーの認証を要求する必要があります。
バックエンドインターフェイスAPIは、ユーザーが表示および実行できる内容を制限する必要があります。アクセス制限は、クライアント側ではなく、サーバー側で設定する必要があります。もちろん、例外的な情報やコマンドを含まないサービスは例外です。
バックエンドインターフェイスAPIは、ブルートフォース攻撃の可能性を考慮する必要があります。攻撃者はデータベースの大部分をダウンロードし、それらすべてを試行することで弱いパスワードと確認コードを推測できます。
内部API(バックエンドで使用され、ユーザーネットワークに公開されていないもの)は、認証にサービスユーザーまたはクライアント証明書を使用する必要がある内部サービスレイヤーを構成します。 実際のユーザーの情報は、ロギング目的でこれらのサービスに伝達する必要があります。
これは非常に残念なことだと思います。これらの制限があるため、バックエンドインターフェイスAPIはアプリワークフローに固有であるため、再利用性が低くなります。残念ながら、再利用できるのは内部APIだけです。これは、バックエンド開発者がユーザーエクスペリエンス、設計されたワークフローをよく理解し、フロントエンドチームと密接に連携する必要があることも意味します。
アプリが上記のガイドラインに従っている場合、クライアント側のアプリが攻撃者のデバイスで改ざんされているかどうかは問題ではありません。彼または彼女は、彼らが持っているユーザー資格情報が公式のクライアント側アプリを介して実行できること以外は何もできません。
しかし、実際のユーザーデバイスがルート化されている場合、マルウェアは次のことが可能になります。
これらの攻撃はあまり一般的ではありません。通常、ユーザーは複雑な手順を実行する必要があるため、これらは困難です。しかし、製品が高価であるか、情報の機密性が高すぎる場合は、これらの攻撃を真剣に受け止める必要があります。
「販売員」が損失が大きく、簡単に回復できない高価な製品を扱っているために懸念がある場合は、次のような二次的な障壁を考慮する必要があります。
それでも不十分な場合は、外部アプリのインストールを防止するためにロックされた会社所有のデバイスを提供し、USBを充電するためだけにロックすることを選択できます。私はいつも、異なる会社の3つの会社の電話を持って歩き回っている数人を知っています。それはまだ事です。
監視は、多くの損失を回避するための優れた戦略でもあります。ログで損失を追跡することにより、それらがどのように発生し、何が失敗したかをよりよく理解し、製品への変更を提案するか、少なくともその状況を監視して、将来の同様の状況の早期警告を得ることができます。
ログが十分に詳細である場合、実装が簡単で、損失を防ぐのに十分なほど多くの種類の侵入とある種の操作ミスを早期に検出できる行動バイオメトリの手法があります。
「製品のモバイルバージョンがあります」とおっしゃったとき、別の製品のように聞こえました。デスクトップ版はありますか?デスクトップオペレーティングシステムはデフォルトでルート化されており、アプリの分離はありません。デスクトップバージョンを使用できる場合は、そもそもルート検出は必要ないでしょう。
セキュリティを継続的に改善することは良いことです。そうすべきですが、新しい開発で恐ろしい間違いをしない限り、モバイル版はデスクトップ版よりも安全であると期待できます。