HTTPページのクレジットカードフォームはMITMリスクですか？
先日、募金活動のページに関するウェブ開発者のメーリングリストのスレッドがありました。
ある人は、クレジットカードフォームのあるページはHTTPSではなくHTTPであると指摘しました。
それに応えて、ある人はフォームのターゲットがHTTPSだったので問題ないと言った
いや、フォームはhttps経由で送信され、Stripeによって提供されます。サイト自体はhttpですが...
しかし、誰かがそれで十分ではないと反論しました
フォームが安全であることを確立していません。 MITMは http://example.com/ の応答のHTMLを変更して、フォームの「action」属性を置き換える場合があります。
問題のウェブサイトはその後 http://example.com にアクセスすると https://example.com に移動するように変更されたため、（うまくいけば）安全です今、しかし私は将来の参考のために知りたいです。
クレジットカードフォームはHTTP上にありますが、ターゲットはHTTPSであり、MITM攻撃のセキュリティリスクですか？
はい、最後の誰かが正しいことに加えて、暗号化に加えて（機密性）HTTPSは、フォームがあなたが思っているところから来ていることを保証します（ authentication）、および転送中に干渉されていないこと（integrity）。 HTTPSがなければ、フォームは説明されているようにMITMによって変更できます。
それはこれにHTTPSを使用しないことは単に悪い習慣です（userが最も弱いリンクであることが多いため）、重要なデータを入力するとき、ユーザーはHTTPSを期待するだけです（南京錠/緑色のバー/何でも）すべてのステップで、例外はありません。
POST HTTPSページから非HTTP URLにアクセスした場合、ほとんどのブラウザーはデフォルトで警告を表示しますが、データが安全に送信されていることを反対の場合にすべて明確に示しているわけではありません。不足HTTPSの場合、サイトは「安全な」Cookieを使用しません。
この問題を適切に解決するには HTTP STS （ RFC6797 ）が必要ですが、ほとんどの場合、最初のHTTPリクエストではブートストラップの問題が残ります。
同様の問題は、HTTPページ内のHTTPSサイトにiframeを使用する慣行です。サードパーティのクレジットカードサービス。この場合、フォームと投稿はHTTPSですが、iframeを含む非HTTPSコンテンツの整合性は保証されません。ブラウザはフォームがHTTPSであることを表示しないため（少なくとも、通常の方法ではないとしても）、これもセキュリティを意識したユーザーの期待に違反します。
真ん中の男は投稿ターゲットを簡単に操作できるため、安全なHTTPS URLを指し示すことはもうありません。ユーザーは、ターゲットが安全であるかどうか（HTMLコードを確認しないと）を確認できないため、POSTターゲットが安全であると信じる必要があります。
安全なHTTPS URLを呼び出す安全でないHTTPフォームのこのスキームは、常に SSL-strip に対して脆弱です。
回答のいくつかは確かに役立ちますが、非常に重要な側面である悪意のあるコードインジェクションへの言及はすべて無視されています。
MITMはHTTP経由で提供されるページを変更できるため、たとえば送信ボタンにカーソルを合わせてAjax POST toフォーム情報を送信する攻撃者のサーバーこれは基本的に チュニジア政府がFacebookの反対者の資格情報を取得するために行ったもの です。
したがって、私の知る限り、HTTP経由でフォームを提供するための2つのセキュリティ問題があります（まあ、実際には1つですが、2つの異なる方法で悪用される可能性があります）。
- 攻撃者が提出対象を変更する（
actionフィールド） - フォームデータをサードパーティに送信するJavaScriptコードを注入する攻撃者。
わかりやすく言うと、サイト開発者としてこれを行うべきではありませんが、このように動作するサイトで作業する必要がある場合、私の答えは何が安全にできるかを示すように設計されています。基本的に、ページ自体を信頼することはできません。信頼できるのは、SSL証明書が解決された場合、投稿は正当なサーバーと通信して、そのURLを要求しているということです。そのURLに送信されていること、および適切なURLであることを手動で検証する必要があります。これは、そのトップレベルドメインに接続しようとしていることがわかっているため、応答がページを提供したのと同じトップレベルURLに送信される場合にのみ実行できます。
ユーザーが投稿ターゲットが目的のサーバーであり、その投稿接続がHTTPSであること、およびページのコンテンツを変更する可能性のあるスクリプトがなく、ブラウザがHTTPSリンク経由で送信しないことを確認している限り送信先のURLの有効な証明書があれば、フォームは完全に安全になります。ページがホストされているのと同じTLDにポストしている場合にのみ、目的のサーバーを知ることができることに注意してください。たとえば、www.bobspayments.comにフォームを送信するように指示するwww.bob.comが有効であったかどうかはわかりません。 2つの異なるサービスに送信された同じ情報が異なることを行う場合、悪意のあるユーザーがそれを利用できる可能性もあります。問題は、ユーザーがそれを行わないことです。パッシブスニッフィングから保護しますが、サイトが合法であることをユーザーに確認しません（ユーザーが懸念を抱くべきです（ただし、多くの場合はそうではありません））。
アクティブなMITM攻撃者は、単にページを変更して情報を返すことができますが、ページ自体がHTTPSであっても、実際にはHTTPページが返されたかどうかに気付かないため、これは可能です。どちらの場合でも、アクティブなMITMから非常に大きな脅威が本当にあるかどうかはわかりません。
実際の問題は、ユーザーエクスペリエンスと、保護されていないページとしてユーザーに表示されるという事実です。そのため、その理由から、ページ全体に対してHTTPSが依然として望ましいです。明確にするために、ページのコンテンツが本物ではない場合に失敗する可能性のある多くのものがあるため、本物であることを証明することが望ましいですが、情報が実際にSSL経由で送信される限り、保護されます。問題は、手動でページコードを確認せずに済むことを保証しています。