Chrome は HTTPS ページ上の HTTP リソースのブロックとパスワードの強度のチェックを開始します

グーグル 警告した HTTPS 経由で開かれたページ上の混合コンテンツを処理するアプローチの変更について。 以前は、HTTPS 経由で開かれたページに、暗号化なし (http:// プロトコル経由) で読み込まれたコンポーネントがある場合、特別なインジケーターが表示されていました。 将来的には、そのようなリソースの読み込みをデフォルトでブロックすることが決定されました。 したがって、「https://」経由で開かれたページには、安全な通信チャネル経由でダウンロードされたリソースのみが含まれることが保証されます。

現在、サイトの 90% 以上が Chrome ユーザーによって HTTPS を使用して開かれていることに注意してください。 通信チャネルが制御されている場合 (たとえば、オープン Wi-Fi 経由で接続している場合)、暗号化せずにロードされた挿入が存在すると、保護されていないコンテンツが変更されるため、セキュリティ上の脅威が生じます。 混合コンテンツ インジケーターは、ページのセキュリティを明確に評価できないため、効果がなく、ユーザーに誤解を招くことが判明しました。

現在、スクリプトや iframe などの最も危険な種類の混合コンテンツはデフォルトですでにブロックされていますが、画像、音声ファイル、ビデオは引き続き http:// 経由でダウンロードできます。 画像のなりすましを通じて、攻撃者はユーザー追跡 Cookie を置き換えたり、画像プロセッサの脆弱性を悪用したり、画像内で提供された情報を置き換えることによって偽造を行ったりすることができます。

ブロッキングの導入はいくつかの段階に分かれています。 79 月 10 日にリリースされる予定の Chrome XNUMX には、特定のサイトのブロックを無効にできる新しい設定が追加されます。 この設定は、スクリプトや iframe など、すでにブロックされている混合コンテンツに適用され、鍵マークをクリックするとドロップダウン メニューから呼び出され、ブロックを無効にするために以前に提案されたインジケーターが置き換えられます。

Chrome は HTTPS ページ上の HTTP リソースのブロックとパスワードの強度のチェックを開始します

80 月 4 日にリリースされる予定の Chrome 81 では、オーディオ ファイルとビデオ ファイルにソフト ブロッキング スキームが使用され、http:// リンクが https:// に自動的に置き換えられ、問題のあるリソースが HTTPS 経由でもアクセスできる場合には機能が維持されます。 。 画像は変更せずに読み込まれ続けますが、http:// 経由でダウンロードした場合、https:// ページではページ全体に安全でない接続インジケーターが表示されます。 https に自動的に変更するか画像をブロックするには、サイト開発者は CSP プロパティの upgrade-insecure-requests と block-all-mixed-content を使用できるようになります。 17 月 XNUMX 日に予定されている Chrome XNUMX では、混合画像アップロード時に http:// が https:// に自動修正されます。

Chrome は HTTPS ページ上の HTTP リソースのブロックとパスワードの強度のチェックを開始します

さらに、Google 発表した 新しいパスワード チェックアップ コンポーネントの Chome ブラウザの次期リリースの XNUMX つへの統合については、以前に説明しました。 現像 の形で 外部加算。 統合により、ユーザーが使用するパスワードの信頼性を分析するツールが通常の Chrome パスワード マネージャーに表示されることになります。 サイトにログインしようとすると、ログイン名とパスワードが侵害されたアカウントのデータベースと照合され、問題が検出された場合は警告が表示されます。 このチェックは、漏洩したユーザー データベースに含まれる 4 億を超える侵害されたアカウントを対象とするデータベースに対して実行されます。 「abc123」などの簡単なパスワードを使用しようとすると、警告が表示されます (by 統計 Google 米国人の 23% が同様のパスワードを使用している)、または複数のサイトで同じパスワードを使用している場合。

機密性を維持するために、外部 API にアクセスするときは、ログインとパスワードのハッシュの最初の XNUMX バイトのみが送信されます (ハッシュ アルゴリズムが使用されます)。 アルゴン2)。 完全なハッシュは、ユーザー側で生成されたキーを使用して暗号化されます。 Google データベース内の元のハッシュもさらに暗号化され、ハッシュの最初の XNUMX バイトのみがインデックス作成用に残されます。 送信されたXNUMXバイトのプレフィックスに該当するハッシュの最終検証は、暗号化技術を使用してユーザー側で実行されます。失明「」では、どちらの当事者もチェックされるデータの内容を知りません。 侵害されたアカウントのデータベースの内容が、任意のプレフィックスの要求によるブルートフォースによって特定されるのを防ぐために、送信データは、検証されたログインとパスワードの組み合わせに基づいて生成されたキーに関連して暗号化されます。

出所: オープンネット.ru

コメントを追加します