Webアプリケーションは、クライアント側のマルウェアによるリスクを防ぐために何かを行うことができますか？
私の知る限り、JavaまたはActiveXなどを介してWebアプリに付与できる、コンピューター上の特権を必要とするアンチウイルスの役割を果たさない限り、あなたは厳しく制限されます。それはむらがあります。
- YubiKeyなどのハードウェアトークンを提供および要求すると、自動化された使い捨てパスワードが提供されるため、キーロガーの問題が軽減されます。
- データがディスクに到達しないようにする（可能な場合）:( Cookieがセッションのみであることを確認し、ページがキャッシュされていないことを確認し、 p ____ hが推奨 のように、オートコンプリートを無効にします）（このアイテムは別の質問に値するかもしれません）
ただし、それを超えて（スクリーンスクレイパー）、問題は残ります、制御できないハードウェアを使用しています。ユーザーは、悪意のあるものかどうかに関係なく、何でもコンピューターにダウンロードできます。
Windows以外のシステムの使用をアドバイス（または要求）することができます。 （ChromeBooksは効果的であると主張しています）選択したOSに応じて、ユーザーが自分のコンピューターを挿入する能力を低下または制限すると同時に、柔軟性をほぼ同じ程度に低下させます。最も制限の厳しいOSはおそらく最も人気のあるものではなく、最もターゲットにされるものでもないからです。
この問題に技術的に対処する実際的な方法はないと思います。自分のシステムを処理することになると、訓練を受けていないユーザーがどれほど愚かであるかを過小評価しないでください。
@George Baileyが述べたように、Webアプリの観点からは、ユーザーシステムは制御不能であり、ユーザーは基本的に何でもダウンロードできます。この問題は、ほとんどのWindowsユーザーが日常業務のために管理者アカウントを実行しているという事実によって増幅されます。
ユーザー教育以外に、クライアント側のマルウェアの脅威を軽減する効果的な手段があるとは思えません。
クライアント側のマルウェアの脅威をある程度軽減したい場合は、VPN実装機能のように、Webアプリへのアクセスを許可する前にユーザーにウイルス対策の利用を要求するのはどうでしょうか。
重要なことは何もできませんが、恐れることはありません。それはあなたの責任ではありません。
せいぜい、ユーザーが厳しく制限されたマシン（たとえば、通常のユーザーには管理者権限がない）、強力なITポリシーが設定されている（たとえば、ブラウザー拡張機能のダウンロードがない）マシンからのみWebアプリにアクセスするように要求できます。マルウェアが存在する可能性が低いセキュリティ（最新のアンチウイルスの実行など）。
これは、社内システムを保護するために有能なITスタッフによって展開されているほとんどの企業のイントラネットに対して行われていることです。ただし、一般に公開されているWebアプリケーションでは不可能です。
2要素認証のようなものは、安全でないシステムを完全に制御している人が実際に回避するのはそれほど難しいことではないことに注意してください。彼らはディスクから最初の要素を正常に通過したことを示すために使用されるCookieを読み取り（HTTPのみで安全であっても）、それをパスワード（キーロガーによって記録された）と組み合わせて、攻撃されたシステムからsocksプロキシサーバーをセットアップできます。トラフィックを誘導します（攻撃者が最初にログインしたときと同じようにWebアプリに表示されるようにします）。
また、パスワードの一部のみを入力するなどのアイデアは、実際にはセキュリティを劇的に低下させることに注意してください。これは、（a）サーバーにパスワードをプレーンテキストで保存するように強制する（または、ログインごとに復号化される可逆暗号化。これは、システム上の悪意のある管理者がパスワードを復号化できるため、機能的には同等です）、または（b）ハッシュするように要求します。パスワードの選択された文字の有限数のk-組み合わせ。ただし、62文字の英数字から選択したログインごとにパスワードから3文字を入力する必要がある場合は、62文字しかありません。3 〜サンプルスペースで238328ハッシュ。非常に遅いbcryptハッシュ（ハッシュごとに0.1秒かかる;約10の強化係数で）でも8 標準のハッシュを介して）、最大で数時間で組み合わせをブルートフォースすることができます。 （繰り返しになりますが、繰り返しが原因で、ログインを監視することで1文字または2文字をすでに知っている可能性があり、問題がさらに簡単になります）。または、アプリケーションがCookieを介して永続的なログイン資格情報を使用する場合は、それを使用して手間を省くことができます。
編集：セキュリティが重要なアプリケーションにアクセスするために制限されたマシンのみを使用することは非常に標準的です。クライアント側のセキュリティとは、クライアントコンピューターとサーバーコンピューター（必ずしも顧客ではない）を意味します。また、ATMを使用してお金を預けたり引き出したりしたことがある場合は、マルウェアを防ぐために積極的に監視される、ロックダウンされた制限付きの適切に管理されたマシンです。 （確かに、人々はシステムを変更することができます。たとえば、カードを読み取るためのハードウェアを配置したり、PIN番号を記録したりできますが、銀行はハードウェアを安全に保ち、マルウェアを排除するために最善を尽くします）。
はい、ログインには2つの別々の情報が必要なため、2要素認証を破るのは困難です。具体的な例として、攻撃者Aが攻撃しているとしましょう googleの2要素実装 マルウェアがインストールされているため、ユーザーUのマシンを完全に制御しています。 Uは記憶されたパスワードでログインし、新しいマシンからログインするたびにテキストメッセージで受信したワンタイムパスワードを入力します（ただし、その後は約2週間記憶されます）。現在、Aには3つの異なる攻撃メカニズムがあり、すべてUのアカウントを完全に制御できます。
通常どおりUログインしましょう。ただし、Uのアクションを変更するだけです。 Uは、銀行のWebサイトでのアクションをシミュレートして、攻撃者が制御するオフショアアカウントに送金するための非表示のフレーム/タブを読み込むブラウザスクリプトをインストールし、銀行のWebサイトが次の6つの定期的なメンテナンスのためにダウンすることをUに示しました。時間。
Aは、通常どおりUにログインさせ、携帯電話の質問に対して正常に認証されたことを示すCookie（およびユーザーがpwを取得するためのキーロガー）を盗むか、携帯電話とパスワードの質問の組み合わせを示すCookieを盗みます。 IPアドレス/ブラウザのユーザーエージェントが変更されたためにAがログインできない場合、AはUのコンピュータにプロキシを設定して、Uのコンピュータからインターネットにアクセスし、Uからすべてのユーザーエージェント/ブラウザのフィンガープリント設定をコピーできます。
標準のMITM攻撃では、攻撃者が制御するページにUをリダイレクトするだけです。次に、UはUのWebサイトのA制御ミラーに移動します。 （Uのコンピューターでは、hostsファイルまたはDNSサーバーがAが制御するものに変更され、攻撃者が制御するIPアドレスを指すように銀行のWebサイトwww.bank.comを置き換えるように変更されています）。 Uがログインすると、Aは実際の銀行に接続し、携帯電話にワンタイムコードをUの電話に送信すると言います。すべてがコーシャだと思ったら、偽のWebサイトにコードを入力します。あなたが彼らのマシンを制御し、彼らのブラウザに新しい証明書を追加し、あなたのシステムを指すように彼らのホストファイルまたはDNSサーバーを変更したので、httpsの問題はありません。次に、彼らが丁寧に提供してくれたすべての情報を偽装してログインします。セキュリティイメージがある場合は、スクリプトが自動的にプルして送信するため、実際のWebサイトから問題なく取得できます。
結論：クライアント側のマルウェアを使用してシステムに安全にログインさせることができるふりをするのは悪い考えです。一般的に、あなたはそれを試すことができず、負けるゲームです。そして、顧客が不満を言うことを心配することに関しては、彼らがインストールしたマルウェアが彼らの貯蓄を失ったので-それはあなたのせいではありません。
銀行が行う必要があるのは、注目すべき活動について顧客に警告し（送金のために電子メールを送信する）、取引が取り消される可能性がある場合に取引が完了する前に適切な猶予期間を設けることです。そして、この問題でライバル銀行に顧客を失うことを心配する心配はありません。あなたのライバル銀行は、あなたと同じようにこの種の脅威から保護されていません。
それは、銀行が2要素認証、セキュリティの質問などを提供するべきではないということではありません。これらの方法はセキュリティを向上させるからです。銀行にログインするコンピューターを完全に制御している誰かがあなたを攻撃するのを防ぐことはできませんが、他のリスクを防ぐことはできます。人々は弱いパスワードを選択したり、同じパスワードを複数の場所で再利用したり、別のサイトで1つのパスワードを入力したりすることで有名です。したがって、何らかの方法で再利用された銀行のパスワードを危険にさらす可能性があります（たとえば、リークされた弱い無塩のリンクされたパスワードと一致した）。 、しかし、攻撃者は最初の段階を通過できないため、銀行では何もできません。
はい。ユーザーを保護するためにできる最も効果的な方法は、帯域外確認を使用することです。たとえば、SMSまたは電話で。
たとえば、トランザクションの詳細を記載したSMSをユーザーに送信し、「OK」とテキストメッセージを返すように依頼するか、SMS =トランザクションの詳細と、承認された場合にWebページに入力するように指示された4桁のワンタイムコードをユーザーに送信します。携帯電話番号を提供したくない、または提供したくないユーザーの場合テキストを受信すると、電話をかけて自動音声応答システムを使用する機会を提供することもできます（ANI、コールバック、または4桁のPINを使用して認証することができます）。
クライアント側のマルウェア（存在する場合）はユーザーのコンピューターで発生するすべてのことを完全に制御できるため、ユーザーのコンピューターだけを使用する他の方法はおそらくそれほど効果的ではありません。
これがわざわざ価値があるかどうかは、あなた自身のリスク分析に基づいてあなたが決定しなければならないものです。
ご存知かもしれませんが、完全に保護する方法はありません。ただし、リスクを減らすことができます。ほぼすべての銀行ソリューションを見てください。
- パスワード全体を入力するようにユーザーに求めないでください。パスワードポリシーで
Nより長いパスワードが必要だとします。次に、M<Nのランダムな位置から文字を入力するようにユーザーに依頼できます。キーロガーが入力されたキーストロークを傍受した場合でも、攻撃者はパスワード全体を入手できません。 - すべての重要な操作（アカウントの削除、パスワードの変更など）には確認が必要です。これは、電子メールまたはSMSで送信できます。パスワードを知っていても、攻撃者はユーザーの侵害されたアカウントに完全にアクセスすることはできません。
- オンスクリーンキーボード。マウスロガーは入力されたクリックされたアクションを簡単にログに記録できますが、キーロガーはそのような保護では管理できません。
- hDに保存されているものはすべて盗まれる可能性があります。それを忘れずに、ユーザー資格情報の処理に使用されるすべてのフォームで
autocompleteをオフにしてください。 - 二要素認証。標準レベルよりも高いレベルでユーザー自身を保護する機会をユーザーに提供します。
- ある種のマルウェアの検出を試みることができます。例： DNSチェンジャー 。
- 最も重要です！。感染したPCを持つユーザーがあなたのビジネスにどのように影響するかを決める必要があります。銀行はあなたの現金を盗もうとするリスクを最小限に抑える必要があります。インターネットを安全にサーフィンしてWebサイトを使用する方法をユーザーに教育する必要があります。