HTTPフォームからHTTPSに送信するのは安全ですか？
Httpsを介してhttpフォームから送信することは可能ですか？安全であるように見えますが、中間攻撃者を許可します（ ここで良い議論があります ）。 mint.com のようなサイトがあり、httpページからサインインできますが、httpsの投稿はできます。私のサイトでは、リクエストはhttpのランディングページを持つが、安全にログインできるようにすることです。起こりうるセキュリティ上のリスクに見合うだけの価値はありません。すべてのユーザーに安全なページにアクセスしてログインさせる（または、ランディングページを安全にする）必要がありますか？
トランザクション全体にHTTPSを使用する理由は何ですかnotがありますか？非常に良いものが見つからない場合は、それを使用してください！
プロトコルの切り替えよりも間違いなく簡単です。
MITMのリスクは現実のものです。
リンクに従って、ユーザー「Helios」は、100％HTTPSを使用することでユーザーの混乱がはるかに少なくなるという優れた点を示しています。
Httpページからhttpsページにフォームを投稿すると、最も単純な条件で送信されるときにフォーム内のデータが暗号化されます。中間者攻撃がある場合、ブラウザは警告を表示します。
ただし、元のhttpフォームが中間者の対象となり、httpsポストバックアドレスが攻撃者によって変更された場合、警告は表示されません。データは実際には暗号化されますが、中間者攻撃者は（最初にキーを送信したため）解読し、データを読み取ることができます。
また、フォームが他の手段（スクリプト接続）を介して物を送り返す場合、フォームが投稿される前に暗号化されていないデータがネットワーク上に送信される可能性があります（ただし、優れたWebサイトは、 。
この種のことは、特にログインがオプションであるサイトでは、ネット中に現れています。しかし、それは非常に微妙な理由で本質的に安全ではなく、ユーザーに誤った安心感を与えます。 codinghorror.com でこれについての記事があったと思います。
危険なのは、 " https：// xxx "の投稿ターゲットでページを送信している間、その参照が発生するページは安全ではないため、攻撃者が送信中に変更できることです。攻撃者が望むURLを指すようにします。そのため、サイトにアクセスする場合は、ソースを表示して資格情報が安全なアドレスに投稿されていることを確認する必要があり、その検証はそのためにのみ関連性がありますonly特定の送信。明日戻ったら、ページの特定の配信が攻撃され、投稿ターゲットが破壊された可能性があるため、ソースを再度表示する必要があります-毎回確認しないと、投稿ターゲットが破壊されたことがわかっている時までに遅すぎる-既に攻撃者のURLに資格情報を送信しています。
ログインページへのリンクはonlyで提供する必要があります。ログインページとそれ以降はすべて、ログインしている限りHTTPSである必要があります。実際、そうしない理由はありません。 SSLの負担は最初のネゴシエーションにあります。後続の接続ではSSLセッションキャッシングが使用され、リンクデータに使用される対称暗号は実際には非常に低いオーバーヘッドです。
IEブログ 説明：重大な間違い＃1：非HTTPSログインページ（HTTPSページに送信する場合でも）
- ユーザーは、フォームがHTTPS経由で送信されていることをどのように知るのですか？ほとんどのブラウザには、このようなUIキューはありません。
- ユーザーは、正しいHTTPSページに移動していることをどのようにして知ることができますか？ログインフォームがHTTP経由で配信された場合、サーバーとクライアント間で変更されていないという保証はありません。
JayとKiwiはMITM攻撃について正しいです。ただし、攻撃者はフォームを壊してエラーメッセージを表示する必要がないことに注意することが重要です。代わりに、攻撃者はJavaScriptを挿入して、フォームデータを2回送信します（1回はあなたに、もう1回はあなたに）。
しかし、正直なところ、攻撃者がログインページを傍受し、飛行中に変更する可能性はどれくらいあるのかを尋ねる必要がありますか？ （a）SSLセッションでMITM攻撃を行い、ユーザーが「OK」を押して続行することを期待するリスクと比較してどうですか。 （b）SSLへの最初のリダイレクトでMITMを実行し（例： http://example.com から https://example.com ）、-にリダイレクト https://doma1n.com 代わりに、攻撃者の制御下にあります。 （c）サイトのどこかにXSS、XSRF、またはSQLインジェクションの欠陥がある。
はい、SSLでログインフォームを実行することをお勧めします。そうする理由はありません。しかし、もしそうでなくても、私はあまり心配しません。おそらく、ずっと下にぶら下がっている果物があります。
更新
上記の回答は2008年のものです。それ以降、多くの追加の脅威が明らかになりました。たとえば、WiFiホットスポット（anyone近くのランダムな信頼されていないネットワークからのアクセスサイトは、その攻撃を阻止できる可能性があります）。はい、そうです、ログインページを暗号化して、サイト全体をさらに進める必要があります。さらに、最初のリダイレクト問題（HTTP Strict Transport Security）に対する解決策もあります。 Open Web Application Security Project は、いくつかのベストプラクティスガイドを利用可能にします。
私（エンドユーザー）にとって、HTTPSセッションの価値は、データが暗号化されているだけでなく、スーパーシークレットを入力しているページが目的の場所から来ていることを確認できることですに。
非HTTPSセッションでフォームを使用すると、その保証が無効になります。
（私は知っています-これはフォームがMITM攻撃を受けやすいことを示す別の方法です）。
この投稿 が重要です。はい、ユーザーのデータがあなたに送信された場合、安全にどこかに到着しているでしょう。しかし、どこかがあなたのサイトになると信じる理由はありません。攻撃者は、この時点で各方向に移動するデータを聞くだけではありません。彼はユーザーのセッションの反対側になります。あなたのサイトは、ユーザーがフォームを送信することを決して気にしないと考えています。
ログインページへのリンクのみを提供することを提案する誰もが、リンクがMITM攻撃を使用して簡単に変更できることを忘れているようです。
上記のすべてで見落とされた最大のことの1つは、ホームページにログインを配置する一般的な傾向があることです（ユーザーエクスペリエンストレンドの大きなトレンド）。
ここでの大きな問題は、Googleが正当な理由で安全なページを検索することを好まないということです。そのため、なぜすべてを安全にしないのか疑問に思っている開発者はすべて、Googleにページを見えないようにしたい場合は、すべてを保護します。それ以外の場合、httpからhttpsに投稿する2番目に良いオプションは、この時点で2つの悪の少ない方ですか？
いいえ、HTTPからHTTPSに移行することは安全ではありません。セキュアチャネルを確立して使用するには、リクエストの発信ポイントと結果ポイントがHTTPSである必要があります。