ブラウザーが画像の混合コンテンツについて警告するのはなぜですか？
私は、サイト全体にSSLを設定してユーザーの資格情報とWebサイトの「プライベート」な部分を保護したいphpBBフォーラムユーザーを扱っています。
ただし、ユーザーが生成したimgタグの従来のフォーラムのユーザーエクスペリエンスをオフサイトコンテンツに保持したいと考えているため、ブラウザーの混合コンテンツ警告がトリガーされます。私たちが思いついた唯一のソリューションは SSL許可プロキシ です。この問題についてしばらく考えた後、ブラウザが画像について特に警告するのはなぜですか？私はjavascriptのケースを理解していますが、画像ですか？
「ページを作成している人がその画像の一部を安全に送信しないことを選択した場合、ブラウザはこの決定が理由で行われたことを尊重し、警告なしにそれを許可する必要があります。ページは同じくらい安全です。それを提供するエンティティはそれがなりたかったのです。」
対照的に、ブラウザ開発者の推論は次のようなものです。「ユーザーに表示されるように、ページにセキュリティで保護されたアイコンを配置します。ユーザーは、ページ全体が安全であることをユーザーが想定できるはずです。ユーザーはそれを知っておくに値します。」
どちらの引数も有効です。これらは、Webページがセキュリティで保護されているという意味の異なる解釈にすぎません。
画像にも特定のリスクがあります。画像は、HTTPプロトコルを使用して平文でリクエストされます。これにより、URLまたはヘッダー内の情報が開示されます。最も深刻な脅威は、ユーザーが選択したサイトから安全に発信されたとユーザーが想定する説明や情報が画像に含まれる可能性があることです。これはフィッシング攻撃に使用される可能性があります。
ブラウザは、画像やその他のリソースが伝えるべき情報の種類を認識していません。おそらくそれは単にロゴであるか、おそらくそれはUIの一部であるか、あるいは画像はアクセスしているページの全体のポイントです。ブラウザがリソースが重要であるかどうかをユーザーに知らせる方法はありません。
プライマリ（ページ）URLがHTTPSで読み込まれると、ブラウザは表示されているページが安全であることをユーザーに通知します。通常はlockアイコン、または緑色のURLバーなどが表示されます。 「このページはそこにある1つの画像を除いて安全です」とは言っていません-どの部分が安全でない部分であるかを閲覧者に示すメカニズムがありません。したがって、代わりに解決策は、ブラウザがページが安全であると言った場合、ページ上のすべての要素が安全でなければならない、またはユーザーに例外を通知する必要があるということです。
安全な要素がいくつかある安全でないURLを表示しても、通知や警告は生成されませんが、同時に、ページにセキュリティ対策が施されていることをユーザーに通知することはありません。セキュリティの期待がないため、混合コンテンツの存在は注目に値しません。
短い答え：意味情報の欠如
長い答え
フォーラムでは、ユーザーは当然、Webマスター（および承認された作成者）だけでなく、「未承認」のサードパーティ（登録ユーザー、実際には誰でもかまいません）からのものを受け取ることを期待しています。
メッセージはウェブマスターの意見を表すものではないことをユーザーは完全に理解しています、およびドメインの所有者によるいかなる方法でも「承認」されていません。合理的なユーザーにとって、Webページに表示されるメッセージの内容、またはそのようなメッセージに含まれる画像に関しては、特に期待はされていません（スカムが適時に削除される前に、削除されるという弱い期待があります）誰でも見ることができます）。
しかしウェブブラウザはフォーラムが何であるかを理解していません。 https://example.com/ページは、example.comから送信され、安全に（トランスポートセキュリティのように）example.com Webマスターの意見、および十分に安全でない画像（特にIMG明示的なサイズなし）を使用して、
あなたのアカウントが停止されました。確認するには、
http://fakesite-example.com/にアクセスする必要があります。そうしないと、アカウントが完全に削除される可能性があります。
画像としてレンダリングされます。
もちろん、フォーラムメッセージでは、ユーザーによる投稿者の意見を表すものと見なされますが、Webブラウザーはそれを知ることができません。
実際、tylerl、ブラウザは、リソースが伝えようとしている情報のtypeを知っています。
明らかなリスクは、リクエストで情報が公開されることです（JavaScriptがページに挿入されたら、機能を変更せずにデータをURLに挿入するのは簡単です。例：img.src = img.src + '？session = 1234';）およびしたがって、交換を危険にさらすために使用できます。
別のリスクは、画像に価値がある可能性があることです-著作権、機密性の観点から、またはおそらく認証プロセスの一部として。
混合コンテンツに関する警告が良い考えであるもう1つの理由は、MITMが「安全でない」画像を、ユーザーのブラウザーのRCE（リモートコード実行）の脆弱性を悪用する画像に置き換えることができるためです。
このような脆弱性の例を次に示します。 https://nvd.nist.gov/vuln/detail/CVE-2017-2416 -基本的に、実行可能コードを含む細工されたイメージを提供し、そのコードを実行することができます古いバージョンのmacOSおよびiOS。
したがって、パッシブコンテンツは一般にアクティブコンテンツよりも安全であると信じていますが（残念ながら、私はこの「信念」を裏付ける文書を知りません）、任意にMITMで置き換えることができるコンテンツは、潜在的なセキュリティ上の脅威です。