web-dev-qa-db-ja.com

私の銀行のホームページはhttpにあります。 SSLなし。リンクをMITM +に変更してログイン認証情報を取得するのは簡単ではありませんか？

いくつかの銀行のホームページはhttpで利用できます。いくつかはhttpにリンクされた検索エンジンを持っています。

これは、私には思えますが、たとえば、ユーザーが銀行にアクセスした場合、ユーザーはMITM攻撃に対して無防備に脆弱になります。パブリックwifi。

これは、私にはさらに思えます。つまり、銀行口座のセキュリティは、「私は希望安全なホームネットワークからのみ銀行口座にアクセスする」<指を交差>。

私には、（1）wifipineappleまたは他のEvil APデバイスの支出、および（2）3つか4つの特定の銀行サイトの偽バージョンでSSLStripをカスタマイズするために誰かに支払うための$ fewhundred

  • パイナップルと一緒に数日間ショッピングモールに座ります
  • トラフィックユーザー全体を収集<->銀行
  • セッションを引き継ぎ、支払いを開始します

つまり、mit-to-mitm-public-wifi + easy-to-spoof-http-homepage =>簡単にハッキングできます。

私は何を見逃しましたか？銀行口座をハッキングするのはそれほど簡単で安価なことではありませんか？

————————————————————————————————————————

PS私は銀行に苦情を提起しました、そして彼らはコールバックがログインページが私にインストールするように頼むと指摘するように呼び戻しました https://www.trusteer.com/ProtectYourMoney （明らかにこれに対処するIBM製品）ブラウザを閉じることによる一種の攻撃。

また、私は彼らのウェブサイトを見つけるために検索エンジンを使用すべきではありません。しかし、あなたがパブリックAPを盗んだら、DNSポイズニングも簡単だと思います

tlsbanksfinancial
1
Chris F Carroll

大量のトラフィックが発生するWebサイト（例：銀行などのコンシューマーサイト）では、プレーンテキストのHTTPとHTTPSの混合実装を使用することにしました。通常、HTTPは公開情報に使用され、HTTPSへの切り替えは、ログイン画面などのプライベートリソースにアクセスするときに発生します。

この手法は、主にSSL（現在のTLS）暗号化/復号化がCPUの観点からコストがかかった時代（1990年代から2000年代初頭）に由来し、ページの読み込み時間を大幅に遅くする可能性がありました。

SHA256のようなハッシュアルゴリズムやAESのような暗号化暗号の使用に長けている高速のCPUでは、この問題はそれほど明白ではありません。ただし、1分間に数千のヒットを受信する大規模なWebサーバーを実行している場合、管理者は、CPU使用率の観点から、TLSトラフィックと非TLSトラフィックに確実に気づくでしょう。プレーンテキストサイトでは、CPUとITのメンテナンスオーバーヘッドが少なくて済むため、ホスティング費用の点で組織の節約になります。さらに、@ mgjkのコメントで指摘されているように、銀行のIT部門間の証明書管理のコスト（ビジネスと個人、商取引と他の商取引、SSL復号化を実行できる必要があるWAFとDDoS軽減レイヤーなど）も重要です。大規模な組織では扱いにくく、TLSのみのサイトを展開することを管理の側に躊躇させる可能性があります。

したがって、多くの銀行はHTTPとHTTPSの混合Webサイトを引き続き活用しています。このセットアップに存在する問題と攻撃ベクトル、特に「SSLStrip」スタイルのMiTM攻撃を制御するための新しいベストプラクティスが開発されています。制御手段には、HSTSヘッダーの使用が含まれ、銀行への道が開かれていますが、これらの大規模な、一般にリスクと変化を嫌うエンティティから、大規模な商業的実装をまだ達成していません。

WiFiパイナップルを悪のAPとして説明する特定の状況に関しては、「SSLStrip」攻撃または別の中間者攻撃をステージングすると、これが可能になります。

ただし、多くの銀行は、セッションハイジャック攻撃から保護するための対策を講じています。デバイスが以前にサイトにアクセスしたことがあり、HSTSヘッダーを送信した場合、エラー（おそらく、平均的なユーザーを怖がらせるのに十分なもの）が確実に発生します。したがって、あなたが説明する攻撃シナリオは少し単純化されており、現代の銀行のWebサイト実装に対して実行可能になる前に、もう少し高度な知識が必要になります。

ただし、はい、銀行がHSTSでのTLSの使用を強制せず、証明書のピン留めを行わない場合、説明したのと同じように大きな攻撃ベクトルが開かれます。この手法は段階的に廃止する必要があります。

6
Herringbone Cat

ヘリンボーンキャットの答えの大部分は非常に誤解を招くものだと私は考えていますが、彼/彼女はあなたが述べる状況は理想からほど遠いと言って正しいです。しかし、サイトプロバイダーが他の方法で攻撃を軽減するために実行できる手順があります。

SSLStrippingはよく知られた攻撃方法でした 2009年以降 。これまでの最も効果的な解決策は [〜＃〜] hsts [〜＃〜] であり、HTTPSのみを使用しているサイトを対応ブラウザが記憶（または通知）します。しかしながら：

  • これはドメイン名に関連付けられています-同じドメイン名でHTTPとHTTPSを混在させることはできません
  • mSIE（Edge 11）がHSTSサポートを実装したのはごく最近のことです（Chrome、Firefox、Operaから久しぶり）

サーバー提供のロジックを使用して実行時にブラウザーで 接続タイプの検出 に基づく他のソリューションがありますが、明らかな制限は、このロジックが改ざんされやすいことです。

また、サーバー側で実装でき、他のタイプの攻撃に適用可能な、詐欺を検出するためのその他のより巧妙な方法もあります。セッションの分割、異常なナビゲーションパターン、ボットの検出、トランザクションのパターン...このような方法の秘密性は、その有効性にとってかなり重要です。したがって、銀行はこれらのコントロールについての情報を公開しません。

しかし、問題のサイトがそのような保護を使用しているかどうかはわかりません。

留意すべきもう1つの点は、攻撃は銀行のWebサイト自体で開始する必要はなく（攻撃は銀行のWebサイトに限定されません）、削除するサイトへのリンクがあるすべてのWebページで開始することです。 Microsoftのbing.comサイトは、デフォルトで引き続きHTTP経由で提供されます。私見これは、顧客に対する世話の義務の怠慢です。

ただし、保護がない場合でも、攻撃を成功させるには、ユーザーがたまたま銀行にログインするのと同時に、デバイスをMITMにする必要があります。ショッピングモールは特に良い歩留まりをもたらさないと思います。

だから、はい、それはmay簡単です。

2
symcbean