web-dev-qa-db-ja.com

iOSのカスタムキーボードにはどのようなセキュリティメカニズムがありますか?

Appleはちょうど 発表済み iOS8を持っています。新しいバージョンは以前のバージョンよりも拡張性が高いようです。新しい可能性の1つは、開発者がシステムのデフォルトとは異なるカスタムキーボードを開発できるようにすることです。

Androidにはかなり前からこの機能があります。 Androidでは、これらのキーボードはセキュリティ上の脅威の可能性として知られています。特に、 キーロガーとして機能する によって知られています。

IOS 8は、そのような悪意のある動作の発生を防ぎますか?もしそうなら、どのようなセキュリティメカニズムが実施されていますか?

2
DCKing

システム自体に組み込まれている安全機能もあり、サードパーティのキーボードがパスワードフィールドに入力するのを防ぎます。パスワードフィールドに触れると、システムは一時的にデフォルトのキーボードに戻ります。

ちなみに、アプリが悪意のないものであることを確認するためにAppleを信頼することはありません。多くのアプリは分析プロバイダーが提供するライブラリを使用しており、分析自体はスパイウェアですが、一部のアプリはスパイウェアです。機密データ(場所、名前、電子メール)をプレーンHTTP経由で送信するのに十分不注意ですが、AppStoreでは問題なく受け入れられます。

1
user42178

はい、これらのアプリは入力内容を記録したり、代わりに任意の入力イベントを生成したりできます。入力を提供するプロセスが特権を悪用するのを防ぐためにできることはほとんどありません。

そうは言っても、モバイルUIでの入力の処理方法には、(デスクトップではなく)カスタムキーボードのリスクを制限するいくつかの構造的要因があります。

  • キーボード入力はアプリ内入力にのみ使用されます、システムのUIとの対話、アプリの切り替え、アプリの起動には使用されません:これにより一部の攻撃が不可能になりますターミナル/アプリ、カスタムのものを入力し、背後にあるアプリを閉じます
  • キーボード入力アプリはおそらくインターネット接続やステートフルネスを必要としません OSによって課せられたAPIを超えて、悪意を持って行動することをより困難にします。インターネット接続を合法的に使用するアプリ(デバイス間でカスタム単語を同期するなど)やIPC(メールを読んで頻繁に使用する単語を予測する)などのアプリがまだ存在する可能性があります。カスタム入力プロバイダーを処理する方法は、サンドボックスなしで実行するのではなく、入力を処理するための特定のアクセス許可を与えるです。iOSが行うことですどうやら。
  • アンドレによると(私は自分自身をチェックしませんでした:-))、パスワード入力フィールドは常にネイティブキーボードによって管理されますそれが常に良いことかどうかは議論の余地があります-たとえば、モバイルユーザーは、パスワードを入力するときに実行する必要のあるモード変更の数を減らすために、悪名高い弱いパスワードを選択します。または、特殊文字のよりカスタマイズ可能な処理を使用して、追加コストをほとんどかけずにモバイルUIでより強力なパスワードを入力できます。
1

答えはAndroidとは異なり、非常に単純だと思います。Appleには複数のアプリストアがなく、公式アプリストアにはアプリの検証に関して比較的厳格なポリシーがあります

つまり、iOS 8ではカスタムキーボードが許可されていますが、アプリストアに配置する前に検証する必要があります。ただし、これは非公式のアプリストアには当てはまらず、ジェイルブレイクされたデバイスは(いつものように)リスクにさらされています

アプリ/プラグインの検証はさておき、iOSのような比較的閉じたオペレーティングシステムでは、アプリ/プラグインのインターネットアクセスを拒否することはそれほど難しくないため、キーロガーは主に役に立たなくなります。

0