アカウント名:
パスワード:
セキュリティの知識のある人：なぜ当該サイトがSSLじゃないのか理解できずに戸惑う
知識のない人：問題があることに気づかない
警告マークが出ればどちらのユーザも適切な情報を受け取れるんだから、そのほうがいいのでは。
従来「警告マーク付きの錠アイコン」（マイナーエラー）が表示されていたWebページの安全性は、
[←安全] (普通の錠アイコン) ≧ (警告マーク付きの錠アイコン) ≧ (平文のHTTP接続) [危険→]
※ただし、如何なる場合も (普通の錠アイコン) ＞ (平文のHTTP接続) となる。
といった感じでした。
例えば、暗号化されたページに非暗号の外部ドメインのトラッキング用Webビーコン画像（1x1 px）が置かれていることよって生じたマイナーエラーは事実上の危険はなく「普通の錠アイコン」の場合と同等の安全性ですが（同一ドメインなら不正なCookieの操作が可能だけど外部ドメインならトラッキングシステムの運用サーバのCookieをセット・読み取ることしかできないし、1pxなら目に見えないので見た目を改変して悪用することもできない）、暗号化されたページに非暗号のJavaScriptコードが含まれている場合にはなんでもできてしまうので（Cookieを他のサーバに送信することも、フォームの送信先を書き換えることも可能）平文のHTTP接続と同じだけの危険があります。
つまり、安全性が
(普通の錠アイコン)≒(警告マーク付きの錠アイコン)
のケースも、
(警告マーク付きの錠アイコン)≒(平文のHTTP接続)
のケースの両方があって、HTMLのソースを読める人じゃないとどっちのケースだか判別できないという状況でした。
つまり、(警告マーク付きの錠アイコン) が表示されたとしても、自分でHTMLのソースを読める人じゃないと何の役にも立たなかったので、それを廃止して平文のHTTPと同じ扱いにしたのは最善の方法だったと思います。
知識のない人： 問題があることに気づかない
については、 「錠マークが表示されない」＝「安全な通信ではない」 と解釈するので問題ないと思います。
従来のように、ブラウザに「警告マーク」が表示されるUIは、平文の http 通信より危険な状況だと誤認させるので好ましくありません。また、ユーザーを警告表示に慣れさせるのも好ましくないと思います。
HTTPSを使っているってことはセキュリティが必要なタイプのサイトであることが多いはずで、そんなサイトで安全性の不備が見つかったのなら警告してくれた方がいい気がするけど
> 暗号化されたページに非暗号の外部ドメインのトラッキング用Webビーコン画像（1x1 px）が置かれていることよって生じたマイナーエラーは事実上の危険はなく
この時点で，間違ってますよ
確かに、ブラウザに脆弱性があるならば、悪意のある画像によってスクリプトが実行されてしまうといった問題が生じるかもしれません。
しかし、img要素はクロスドメインで使うことが前提となっているので、ブラウザに脆弱性が無い限り、表示画像を差し替えること（大きな画像なら偽情報を表示させユーザーを騙すことが可能だけど1px*1pxなら不可）と、画像の配信元ドメインの権限でCookieを読み書きすることぐらいしかできなかったと思うんですが、ひょっとして他に攻撃方法はありますか？
img要素のsrc属性で指定されたファイルの Content-Type を text/javascript などにしたところで、スクリプトは実行されません。
なぜimg要素限定なのでしょうか。script要素だってクロスドメインが前提だと思いますが。でなければ、JSONPが流行るわけもないし。
実際、地図業界ではJSONPが流行り過ぎて、セキュリティの整合性を取るのに苦労すると思います。
というか、フィッシングサイトのことを考えるとimg要素だけでもわりと危険ですよ。人間は字と画像しか見てないので。
いや、多分、あってる。
その段落は、「危険はない」と主張してるんではない。そこでの主張は、「ユーザがソースを全部精査すれば、そのページがクリティカルな部分にhttp接続相当の危険性を孕んでいるのか、事実上、https接続相当の安全性が保てているのかは、ある程度は(*)判断可能」とかそういうこと。
* 決定不能問題を持ち出して判断不可能な実例を作る事は可能だけど、「大丈夫だと確信できる」/「もしかしたらヤバいかも」より詳細な厳密な分類が絶対必要というわけでもない。
頑張ってソースを精査して、「平文部分が攻撃を受けても、1x1 pxの色が変わるだけ」とチェックし
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
警告マークも出ないの？ (スコア:1)
セキュリティの知識のある人：
なぜ当該サイトがSSLじゃないのか理解できずに戸惑う
知識のない人：
問題があることに気づかない
警告マークが出ればどちらのユーザも適切な情報を受け取れるんだから、そのほうがいいのでは。
シンプルになって良かったと思う (スコア:3)
従来「警告マーク付きの錠アイコン」（マイナーエラー）が表示されていたWebページの安全性は、
[←安全] (普通の錠アイコン) ≧ (警告マーク付きの錠アイコン) ≧ (平文のHTTP接続) [危険→]
※ただし、如何なる場合も (普通の錠アイコン) ＞ (平文のHTTP接続) となる。
といった感じでした。
例えば、暗号化されたページに非暗号の外部ドメインのトラッキング用Webビーコン画像（1x1 px）が置かれていることよって生じたマイナーエラーは事実上の危険はなく「普通の錠アイコン」の場合と同等の安全性ですが（同一ドメインなら不正なCookieの操作が可能だけど外部ドメインならトラッキングシステムの運用サーバのCookieをセット・読み取ることしかできないし、1pxなら目に見えないので見た目を改変して悪用することもできない）、暗号化されたページに非暗号のJavaScriptコードが含まれている場合にはなんでもできてしまうので（Cookieを他のサーバに送信することも、フォームの送信先を書き換えることも可能）平文のHTTP接続と同じだけの危険があります。
つまり、安全性が
(普通の錠アイコン)≒(警告マーク付きの錠アイコン)
のケースも、
(警告マーク付きの錠アイコン)≒(平文のHTTP接続)
のケースの両方があって、HTMLのソースを読める人じゃないとどっちのケースだか判別できないという状況でした。
つまり、(警告マーク付きの錠アイコン) が表示されたとしても、自分でHTMLのソースを読める人じゃないと何の役にも立たなかったので、それを廃止して平文のHTTPと同じ扱いにしたのは最善の方法だったと思います。
については、 「錠マークが表示されない」＝「安全な通信ではない」 と解釈するので問題ないと思います。
従来のように、ブラウザに「警告マーク」が表示されるUIは、平文の http 通信より危険な状況だと誤認させるので好ましくありません。また、ユーザーを警告表示に慣れさせるのも好ましくないと思います。
Re: (スコア:0)
HTTPSを使っているってことはセキュリティが必要なタイプのサイトであることが多いはずで、
そんなサイトで安全性の不備が見つかったのなら警告してくれた方がいい気がするけど
Re: (スコア:0)
> 暗号化されたページに非暗号の外部ドメインのトラッキング用Webビーコン画像（1x1 px）が置かれていることよって生じたマイナーエラーは事実上の危険はなく
この時点で，間違ってますよ
Re:シンプルになって良かったと思う (スコア:2)
確かに、ブラウザに脆弱性があるならば、悪意のある画像によってスクリプトが実行されてしまうといった問題が生じるかもしれません。
しかし、img要素はクロスドメインで使うことが前提となっているので、ブラウザに脆弱性が無い限り、表示画像を差し替えること（大きな画像なら偽情報を表示させユーザーを騙すことが可能だけど1px*1pxなら不可）と、画像の配信元ドメインの権限でCookieを読み書きすることぐらいしかできなかったと思うんですが、ひょっとして他に攻撃方法はありますか？
img要素のsrc属性で指定されたファイルの Content-Type を text/javascript などにしたところで、スクリプトは実行されません。
Re: (スコア:0)
なぜimg要素限定なのでしょうか。script要素だってクロスドメインが前提だと思いますが。でなければ、JSONPが流行るわけもないし。
実際、地図業界ではJSONPが流行り過ぎて、セキュリティの整合性を取るのに苦労すると思います。
というか、フィッシングサイトのことを考えるとimg要素だけでもわりと危険ですよ。人間は字と画像しか見てないので。
Re: (スコア:0)
いや、多分、あってる。
その段落は、「危険はない」と主張してるんではない。
そこでの主張は、「ユーザがソースを全部精査すれば、そのページがクリティカルな部分にhttp接続相当の危険性を孕んでいるのか、
事実上、https接続相当の安全性が保てているのかは、ある程度は(*)判断可能」とかそういうこと。
* 決定不能問題を持ち出して判断不可能な実例を作る事は可能だけど、
「大丈夫だと確信できる」/「もしかしたらヤバいかも」より詳細な厳密な分類が絶対必要というわけでもない。
頑張ってソースを精査して、「平文部分が攻撃を受けても、1x1 pxの色が変わるだけ」とチェックし