本セクションでは、機密性の高いデータや機能に対して処理・アクセスを行うアプリケーションに対して奨励される多層防御の基準をまとめています。ここにまとめている制御が何も無いことが何かの脆弱性につながる訳ではありません。しかし、これらの制御を講じることで、アプリケーションのリバースエンジニアリングや特定のクライアントサイド攻撃への耐性を増加させることになります。
本セクションの制御策は、アプリケーションに対する不正な改ざんやコードのリバースエンジニアリングによって発生するリスクを評価した上で、必要に応じて講じるべきものです。
ビジネスリスクのリストと関連する技術的脅威を挙げている、OWASPの「リバース エンジニアリングや不正なコード変更の技術的リスク」(『Technical Risks of Reverse Engineering and Unauthorized Code Modification』)、「リバースエンジニアリングとコード変更の防止」(『Reverse Engineering and Code Modification Prevention』)」(下記リンク参照)という文書も参照することをお薦めします。
以下のリストにある各制御は、少なくともMASVS-L1の全てを満たし(つまり、基本的なセキュリティ制御策を実施し)、V8内のその他の若い番号の制御策全てを満たしている場合に有効であるといえます。例えば、”解析の防止”のリストにある難読化に関する制御は、”アプリケーションの隔離”と”動的解析と改ざんの防止”、また”端末の結び付け”のリストにある難読化に関する制御とあわせて用いなければ意味がありません。
留意すべきは、ソフトウェアの保護はセキュリティ制御とは別物であるということです。MASVR-Rに挙げられている制御は、特定の脅威にのみ有効で、補足的なものです。さらに、対象のアプリケーションはMASVSのセキュリティ要件を満たしている必要があります。
以下の考慮が適用されます。
-
脅威モデルは、クライアントサイドの脅威を明確に定義していなければなりません。さらに、その保護手法が体系化している保護のグレードのどこにあたるのかを明確にしなければなりません。例えば、目標を、アプリケーションをインストルメント化しようとするマルウェアの製作者に対して、手動のリバースエンジニアリングでの多大な努力を強いる、というように設定するということです。
-
脅威モデルは合理的でなければなりません。例えば、ホワイトボックス方式の実装で暗号化のための鍵を隠すことは、攻撃者がそのホワイトボックス全体をコードリフトできてしまう場合、的外れな実装になってしまいます。
-
保護の有効性は、特定の改ざん防止策や難読化策を使用したテスト経験のある人間の専門家によって検証されるべきです。(『モバイルセキュリティテスティングガイド』の中の「リバースエンジニアリング(reverse engineering)」と「ソフトウェアの保護に対する評価(assessing software protections)」の章もご参照ください。)
| # | 説明 | R |
|---|---|---|
| 8.1 | アプリケーションは、端末がルート化またはJailbreakされている場合、ユーザーに警告しアプリケーションを終了させることによって検知、及び対応する | ✓ |
| 8.2 | アプリケーションは、デバッグ行為を防止する、およびまたはデバッグソフトの対象となったことを検知してこれに対応する。その際、全ての利用可能なデバッグプロトコルを網羅していなければならない | ✓ |
| 8.3 | アプリケーションは、アプリケーション内のサンドボックスで実行ファイルや重要データが改ざんされたことを検知し、これに対応する | ✓ |
| 8.4 | アプリケーションは、広く使用されているリバースエンジニアリングツール及びフレームワークが端末上に存在することを検知し、これに対応する | ✓ |
| 8.5 | アプリケーションは、エミュレータ上で動作していることを検知し、これに対応する | ✓ |
| 8.6 | アプリケーションは、自身のメモリ空間のコードやデータが改ざんされていることを検知し、これに対応する | ✓ |
| 8.7 | アプリケーションは 8.1～8.6 それぞれの防御策に関して、複数の機構を実装する。その際、それらの機構が独自の特徴を持ち、またその特徴が多様であるほど脅威への耐性が大きくなることに留意すること | ✓ |
| 8.8 | 検知メカニズムは、複数の異なるタイプの対応方法を持っている。その中には、一定時間経過後に動作するもの、秘密裏に動作するものを含んでいる | ✓ |
| 8.9 | 難読化はプログラムの防御に適用されるが、これによって動的解析による難読化の解除が防止される | ✓ |
| # | 説明 | R |
|---|---|---|
| 8.10 | アプリケーションは、複数のユニークな属性から由来するフィンガープリントを使用して端末を特定する機能を実装している | ✓ |
| # | 説明 | R |
|---|---|---|
| 8.11 | アプリケーションに属する全ての実行ファイルとライブラリは、ファイルレベルで暗号化されている、およびまたは実行ファイル内の重要なコードやデータセグメントは暗号化またはパッケージ化されている。簡単な静的解析では重要なコードやデータが明らかにされない | ✓ |
| 8.12 | 現時点で発表されている調査から見るに、難読化の目的が機密度の高い処理を保護するためである場合、難読化の手法は、現在の作業に適していることと、手動または自動化された難読化解除の手法に対して堅牢であるものが使用される。難読化手法の有効性は、手動の検査を通じて検証されなければならない。ハードウェアベースでの隔離策が可能な場合は、その方が難読化よりも好ましいことに留意する。 | ✓ |
OWASPモバイルセキュリティテストガイドには、本セクションに記載されている要件を検証するための詳細な手順が記載されています。
- Android - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05j-Testing-Resiliency-Against-Reverse-Engineering.md
- iOS - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md
詳細は以下を参照してください。
- OWASP Mobile Top 10: M8 - Code Tampering(コード改ざん), M9 - Reverse Engineering(リバースエンジニアリング)
- WASP Reverse Engineering Threats -https://www.owasp.org/index.php/Technical_Risks_of_Reverse_Engineering_and_Unauthorized_Code_Modification
- OWASP Reverse Engineering and Code Modification Prevention - https://www.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project