OWASP Mobile TOP10のリスクからアプリを保護しよう

こちらは、2019年5月29日に公開された以下のドキュメントを翻訳したものとなります。

Protect applications against OWASP TOP 10 Mobile Application Risks

モバイルおよびWebアプリケーションにおけるセキュリティ脅威のTOP10リストがOWASP（Open Web Application Security Project）からときおり発表されます。2001年にオンラインコミュニティとして発足したOWASPは、悪意のあるセキュリティ脅威に対して開発者に注意喚起することを目的としています。
発足後すぐに名前が知れ渡り、OWASPのリソースマテリアルと脅威のリストは業界のスタンダートとなり、開発者が参考にしています。コミュニティ駆動型イニシアティブであり、商業的な利益にしばられていないため、脅威のリストは包括的かつ信頼がおけるもので、エキスパートも支持しています。

最新版OWASP Mobile TOP10リストが2016年に公表されました。（2017年度の公表候補版がWebアプリ用に利用可能になっています。Webアプリとモバイルアプリの間で統合が進んだため、提言の多くはモバイルアプリにも当てはまります。）このリストでは危険性の高い安全でない環境において、優先してアプリを保護するべき主なリスクと重要な領域の要点を説明しています。世界中の開発者が、リスト上のリスクからモバイルアプリを保護するにあたりOWASPのTOP10リストの信頼性を保証しています。

BetaNewsのニュースによれば、セキュリティの脆弱性は、最もダウンロードされたアプリTOP30に入るような信頼性の高いモバイルアプリでさえも頻繁にあり、なんと94％に3つ以上の危険性の高いセキュリティホールが見られます。状況はとても深刻で、有名なAndroidのウイルス対策ソフトウエアですらモバイルアプリを保護しきれていません。独立検査機関であるAV-Comparativesが行った最新のテストでは、Androidのウイルス対策アプリの2/3は脅威の30％も防げていないことがわかりました。

モバイルとアプリの構成が変わってきているように、モバイルの脅威の見識も急速に変わってきていることに気づかなければいけません。2017年度のOWASPのRCリストには、開発者がユーザーに最高の使い心地を提供しようとする傾向が意味するのは、アプリのソースがBootstrap、Electron、Angular、Reactなどの近代のWebフレームワークの人気により、安全な場所ではなく、信頼されていないブラウザに移行したことだと記載されています。OWASPはコミュニティ駆動型の企業向けリスク評価方法論を発展させてきました。この方法論で、脅威が生産サイクルに入り込むよりも前にアプリを保護します。概してセキュリティのリスクは、組織に与える影響から発生の可能性として認識されます。影響は専門用語やビジネス用語でさらに評価されます。

リスクTOP10

では、OWASPがどのようにアプリの脅威を定義しているか、またそれらに対抗しているか、細かく見ていきましょう。

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

ルーティングされたデバイスでは、AppSealingが起動を制御しアプリを保護します。Androidのエミュレータ検出もまた、安全でない環境でアプリが起動するのを制御します。アプリのコンポーネントは全て、最高の暗号化基準でハッシュ検証されています。こちらのブログ記事：ルーティングされたAndroidデバイスのセキュリティの抜け穴を、AppSealingでカバーしようもご覧ください。

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

OWASPは、アプリに保管するデータをAES-256もしくはSHA-256アルゴリズムで暗号化し、すべてのデータ（アプリによってデバイスに保管されたデータだけでなくアプリのデータも）を安全にレンダリングして、セキュリティ侵害が発生した場合に誤用される可能性を取り除くように提案しています。　

M3:安全でない通信

ハッカーがよく行う手口として、ネットワークをコソコソと嗅ぎまわりデバイス-サーバー間で行われた通信を見つけ、APIを通じて行われた通信を悪用します。中間者攻撃（MITM）を防ぐためデータを隠すこととSSL証明書の採用に当たって開発者によるベストプラクティスの導入が必要です。信頼できるセキュリティサービスには、適切なセッション処理を確実にし、ネットワークをスキャンして「パケットのスニッフィング行為」を見つけアプリの起動を抑えるセキュリティレイヤがあるべきです。

M4:安全でない認証と M5:安全でない許可

この2つのカテゴリは認証プロセスとセッション処理の両方における弱点を含んでいます。処理が正しく行われないと、ハッカーが直接サーバーに接続しマルウェアをデプロイしてデータが「感染」してしまいます。モバイルアプリの中には認証をオフラインで行うものもありますが、そうするとハッカーに悪用されやすくなります。脅威に対抗するには、適切なユーザーのプロファイリングと管理、ユーザーのアクセス制限、サーバーサイドの認証が有効です。

M6:不十分な暗号化

モバイルのアセットはエンドツーエンドで暗号化し、攻撃が起きた際に保護してハッカーに機密データや利益に関わる知的財産を盗ませないようにしなければいけません。アンチデバッギングやアンチデコンパイルによりソースコードの完全な暗号化とバイナリ保護が可能になります。鍵は安全な方法で管理されます。こうするとデータが盗まれてしまったとしても、解読と誤用がかなりの確率で不可能となります。コードの難読化技術を使用するとアプリ全体のコードベースとライブラリがバラバラになります。

M7:インテグリティ保護、コード暗号化とM8:コードの改ざん

アプリのインテグリティは定期的にインテグリティスキャンを実行してエンドツーエンドで確実に守られなければいけません。それにより余計な機能からの保護も確実になります。サードパーティのライブラリと互換性があると、起こり得る悪用に対するオールラウンドのコード保護となります。メモリーダンプとメモリーリソースのリーク対策はAppSealingなどのセキュリティサービスを用いて適切に行われる必要があります。開発者は、たとえオフラインモードであっても確実にアプリを安全にしておく必要があります。常にリッスンするセキュリティシールドを用意して、コード改ざんを試みようとする攻撃を全て無効にしなければいけません。権限の必要なセクションへ不注意でアクセスがあっても、このようにチェックされ適切に処理されます。

M9:リバースエンジニアリング

AppSealingのアンチデバッギングとアンチデコンパイルによって、リバースエンジニアリングを確実に防ぎます。AppSealingはコードの難読化で侵入者がアプリの最終的なバイナリに触れることのないようにします。こちらのブログ：モバイルアプリをリバースエンジニアリングから守ろうをご参照ください。

M10:余計な機能

開発者は、本番環境には公開する予定でない秘密のバックドア機能やその他の内部開発セキュリティ制御を有します。例えば、ハイブリッドアプリで開発者が偶然にもパスワードをコメントとしていれてしまうケース。またテストの最中に2要素認証を無効にしてしまうなどがこのケースです。

AppSealingのセキュリティレイヤ

AppSealingのセキュリティサービスは包括的かつ効果的で、コーディングの手間いらずのアプローチを提供し、AndroidとiOS両方のモバイルアプリをOWASPのTOP10リスト上のリスクから保護します。AppSealingはセキュリティレイヤを直接アプリのバイナリに適用してパフォーマンスやバッテリー使用量に影響することなく保護しています。

スマートレポーティングや見やすいダッシュボードでリアルタイムでビジネスに関わる有用な情報の確認ができます。OWASPのモバイルリスクTOP10リスト上の多くの脆弱性からモバイルアプリを保護します。

詳細は、無料トライアルでモバイル保護に関するAppSealingの力を直接感じ取ってください。