ホームページでsslを使用せず、他の場所ではsslを使用している場合、会社のWebサイトはsslstripに対して安全ですか？
ほとんどのeコマースWebサイトは、ログを記録するときにSSL/TLSを使用します。しかし、ほとんどはhttpのみを使用するホームページを持っています。 sslstripを防ぐために、ログインページとログページにSSL/TLSがあれば十分ですか？
HTTPSの正しい使用法の確認は、最終的にはユーザーの責任です。ユーザーは、Webページにアクセスするときに少なくとも3つのポイントを確認する必要があります。
- 彼らはHTTPSが使用されることを期待していますか（少なくともサイトのこの部分では）？
- その場合、証明書は有効ですか（ロック/緑/青のバー、警告なし）？
- もしそうなら、アドレスバーのホスト名は彼らが訪問するつもりのサイトのものですか？
HTTPSを正しく使用するには、これら3つの質問に「はい」と答える必要があります。
最初のページでHTTPSを有効にしなくても、必ずしも終わりではありません。このページはSSLStrip攻撃に対して脆弱である可能性がありますが、そのページの内容を安全に転送する必要がない場合があります。
- 「安全なセクション」へのリンクがある場合、ユーザーは、それが期待するサイトに送信されることを確認する必要があります（上記の3つのポイントを参照）。それはユーザーの責任です。
- Webサイトの安全なセクションでは、安全なセクションに入る前に行われたこと（バスケットへのアイテムの追加など）が安全に行われたと想定しないでください（ユーザーは常に確認する必要があります）。ログインランディングページ自体（存在する場合）もHTTPS経由で提供する必要があります（ユーザーがログインフォームもHTTPSに送信されることを期待できるように、 このOWASPルール を参照してください）。さらに、セッションの盗難を許可しないように、異なるセッション管理を使用し、非セキュアセッションを破棄する必要があります。それはウェブ開発者の責任です。
ほとんどのWebサイトには、HTTPSへのリダイレクトを実行する場合、または最初の HSTSヘッダー を送信する場合のみ、プレーンなHTTPウェルカムページがある場合があります。これは確かにこの段階ではSSLStripに対して脆弱である可能性がありますが、ユーザーが何を期待するのかわからない場合は、開始点が必要です（ほとんどの場合、最初にプレーンhttp:// URLを使用します）。 自動リダイレクトでリスクを軽減できます（のみ） 。これを回避する唯一の方法は、ユーザーがhttps:// URIのみが機能することを知るか、サイトを プリロードされたHSTSリスト の一部にすることです。
（ユーザーまたはブラウザーがHTTPSの使用を予期していない場合、WebサイトはSSLStripに対して安全ではありません。この期待は、攻撃が行われていないネットワークからの最初の訪問によって、HSTSを介してブラウザーで自動的にアクティブ化できます。 、または事前に読み込まれたリストを使用します。）
ユーザーが最初に（ローカルファイルまたはローカルサーバーのページではなく）Webのhttp:ページにアクセスするたびに、悪意のあるHTTPプロキシがhttps:へのリンクを変更するリスクがあります。 ：
- プレーン
http:リンク https:は、類似した名前の別のWebサイトにリンクしています（example.comではなくexample-login.com）。
http:ログインページにリンクするhttps:メインページを持つ銀行セキュリティを理解していない、完全停止。
説明：
銀行は、「安全な」サーバー（HTTPSサーバー）を提供するだけでは不十分であることを理解する必要があります。責任のある合理的なユーザーは、すべてのケースで最終的にこのサーバーに接続する必要があります。 （電子メールのリンクをたどるユーザーは当然のことながら不合理です。）
ユーザーは、自分の銀行のメインドメイン名（oneドメイン名）を覚えている（または書き留めている）、自分の銀行が他のすべてのドメインを知らないことを期待できます。任意の目的に使用します。多くのユーザーがDNSの階層的な性質を理解していないため、secure-login.mybank.comがmybank.comのサブドメインであるがmybank.secure-login.com、mybank-secure-loginであることを認識できないという事実を追加します。 comとsecure-login-mybank.comはそうではありません。彼らは愚かではなく、ただDNSの基本原則を知らないだけで、これらの技術を学ぼうとはしません。 ユーザーは、この完全修飾ドメイン名を正確に知らない限り、ドメイン名が正当であることを認識することは期待できません。
ユーザーは、単純な簡単なルールのみを前提として、適切な場所に到着することを保証する必要があります。 「確認し、問題を検出したら停止する」などの「否定的な」ルールを一貫して適用することは困難です。
- 攻撃が進行していない限り、ユーザーは問題を検出しません
- ユーザーは常に同じ（正しい）結果を与えるチェックに飽き飽きします（冗長に見える）
- 否定的なルールを忘れて続行するのは非常に簡単です
もう1つの問題は、現実の世界では、実際の物を模倣する傾向が低いために偽のオブジェクトを認識することができ、多くの機能がセキュリティ上重要な物理的オブジェクト（銀行券、クレジットカード）であり、模倣するのが非常に難しいように設計されていることです。私たちの直感は、模倣を検出するためにオブジェクトのプロパティを調べるように訓練されています。 Webサイトを扱うとき、この直感はすべて間違っています。Webページの模倣は、元のと同じように見えます-実際、それはオリジナルです、少しずつ（そして、法律さえ違法コピーを作ることは偽物を作ることと同じものであるという混乱を運びます）。
偽の銀行（eコマース、ISP、ソーシャルなど）のWebサイトを扱う場合、URL（アドレス）のみが異なります。ログインページはまったく同じように見えます（詐欺師が無能な場合を除き、これも起こります）。
また、偽の銀行ではなく、偽の銀行券が存在する可能性があるという考えに訓練されました。
OTOH、「このURLを入力してください」などの「ポジティブ」ルールは、忘れることはできません。これを忘れると、ブラウザは（通常）どこにも行かないためです。したがって、ある日、ブラウザが銀行（eコマース、ISP、ソーシャルなど）のWebサイトのように見えるWebサイトにアクセスし、正しいURLを入力していない場合、何かが間違っていることがわかります（少なくとも非常に疑わしい）。 。
したがって、実際にはユーザーはロボットではありませんであるため、安全な推奨手順は、理想的には肯定的なルールのみで構成する必要があります。ブラウザはロボットなので、すべてのネガティブルールを実装する必要があります（SSL/TLSには多数のネガティブルールがあります）。
いいえ。ホームページにHTTPSがない場合でも、SSLStripは実行できます。接続のいずれかがプレーンテキスト（つまりHTTP）で送信された場合、それを傍受でき、セッションがハイジャックされる可能性があります。セキュリティで保護する必要のあるすべてのページにHTTPSを使用し、 HSTSヘッダー を使用する必要があります。