当社のAIエンジンNeutronが、UCバークレーのCyberGymベンチマークで96.75%のスコアを記録しました。 詳細を見る

セキュリティ

セキュリティ

モバイルアプリケーションの重要なアタックサーフェス

モバイルアプリケーションのアタックサーフェス。

LiveOverflowが、モバイルアプリケーションセキュリティに関する 興味深い動画を公開しました。その中で、モバイルアプリケーションのアタックサーフェスと、 自身の成果を過大に喧伝するセキュリティ「研究者」のケースを取り上げています。

モバイルアプリケーションは、サンドボックス化、明示的な権限モデル、自動アップデート、そしてデフォルトで安全であろうとするAPIの提供を通じて、 アタックサーフェスの削減を念頭に置いた環境の上に構築されています。

しかし、一部のモバイルアプリケーションは、その基盤となる技術スタック、アプリケーションが提供する利用形態、あるいは アプリケーションが他のコンポーネントと行う対話のいずれかによって、特別な注意を要する重要なアタックサーフェスを露出しています。 考慮すべきもう一つの重要な要因は、これらの環境がより多くの機能や特徴を追加する必要があることです。 こうした機能は、開発者が私たちの携帯電話を使う新しい方法を見つけるうえで創造性を発揮する余地を与えますが、同時に アタックサーフェスを増大させます。例えばiOS App Extensionを考えてみてください。この、Androidのインテントに似た機能は、 のちにiOSエコシステムに追加されました。

以下は、これまでにセキュリティ上重要な脆弱性として見てきた、しかしモバイル環境に非常に特有ないくつかの例です。

JavaScriptベースのアプリケーションにおける、リモートから悪用可能なJavaScriptインジェクション

Cordovaやionicのような、JavaScriptフレームワークを使って開発されたアプリケーションは、JavaScriptまたはHTMLの インジェクションに対して脆弱である可能性があります。これらの脆弱性は、これらのフレームワークを通じて露出するAPIの 性質上、リモートコードインジェクションへと発展し得ます。

このような脆弱性が重要とみなされるためには、攻撃者が特別な操作なしに悪意ある入力を他のユーザーへ送れる能力を 持っている必要があります。

例えば、ユーザーが個人のウォールを通じて進捗を共有できるスポーツアプリがあるとします。そのウォールがJavaScript インジェクション(XSS)に対して脆弱であれば、攻撃者のウォールを閲覧したすべてのユーザーが侵害されます。

HTMLインジェクションの脆弱性でさえ、JavaScript Gadget攻撃を介してJavaScriptインジェクションに変えられる可能性があります。

信頼できない入力を介したネイティブコードでのメモリ破壊

いくつかのアプリケーションは、音声、動画、画像のようなバイナリフォーマットの解析をネイティブライブラリを使って行います。 信頼できない入力を使ったこれらのライブラリにおけるメモリ破壊の脆弱性は、リモートコード実行につながります。

例えば、MP4形式の音声録音を送信できるチャットアプリケーションがメモリ破壊の脆弱性を抱えている場合、これはそのアプリケーションの 文脈でのリモートコード実行につながります。

Java、Kotlin、Objective C、Swiftはいずれも、安全でないAPIを使わない限りメモリ安全な言語ですが、CやC++のライブラリに リンクすることは、この種の脆弱性への扉を開きます。

Chromeでのドライブバイ攻撃を用いて悪用される、ブラウズ可能なActivityでのインテントインジェクション

Chromeは、Browsableカテゴリを持つアクティビティに対して、追加パラメーター付きのインテントを送信できます。インテントの 追加パラメーターを通じたインジェクションに脆弱なアプリケーションは、ドライブバイでの悪用に対して脆弱です。

攻撃者は、被害者を悪意あるページへ誘い込むか、あるいは例えば広告を使って攻撃を仕掛けることができます。Firefox ブラウザーはインテント送信を発動させるために追加のユーザー操作を必要としますが、モバイル端末上の他のほとんどの ブラウザーはこの機能をサポートしていません。

平文トラフィックでの通信、あるいは安全でないTLS/SSLサーバー証明書検証の使用

この脆弱性の影響は、やり取りされるデータの性質によります。例えば、認証フェーズやセッションを伴うアクションが安全でない チャネル上で行われる場合、これはユーザーのセッションの侵害につながります。

アプリケーションがJavaScriptフレームワークで開発されている場合、リモートのJavaScriptやHTMLの取得はリモートコード実行に つながります。アプリケーションが安全でないチャネル上で共有ライブラリ(.so、.dex、.jar)をダウンロードする場合も、 やはりリモートコード実行につながります。

この脆弱性の一例は、ALLOW_ALL_HOSTNAME_VERIFIERの使用です。

代替テキスト
allow_all_hostname_verifier

ALLOW_ALL_HOSTNAME_VERIFIERの実装は、いかなる検証も行いません。

代替テキスト
allow_all_hostname_verifier_impl

モバイルアプリケーションとWebアプリケーションの間で共有されるセッション管理と、モバイルバックエンドにおけるWeb関連の保護の欠如

Webアプリケーションは他のWebアプリケーションと同じブラウザーを共有しており、これがCSRF、あらゆる種類のXSSを通じたセッション ハイジャック、さらにはクリックジャッキングのような、モバイルアプリケーションには当てはまらない一連の攻撃の機会を生み出します。

一般に、これらの攻撃ベクトルはモバイルアプリケーションには存在しないため、開発者はこれらの攻撃に対するセキュリティ保護を 実装する必要がありません。

しかし、一部のモバイルアプリケーションのバックエンドは、Webとモバイルのバックエンドの間でセッション管理システムを共有して おり、これが攻撃者にブラウザーからモバイルバックエンドにリンクしてこれらの脆弱性を悪用する機会を生み出します。

タグ:

android, ios