アカウント名:
パスワード:
セキュリティの知識のある人:なぜ当該サイトが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の色が変わるだけ」とチェックし
知識のある人は詳細を確認するから戸惑わないと思うが?
たとえばここでログインするのにこれまでも警告マークでない。それも問題?
詳細を調べればわかるのはあたりまえ。それ以前の、情報の伝達方法を言っている。
①知識がある人警告マークが出た場合: 証明書に問題があると気づいて確認する鍵マークが消えた場合: 非常にびっくりする。いったい何があった? 間違えてフィッシングサイトを見ているのか? SSLを使うのをやめたのか?
②知識がない人:HTTPSの意味をよく理解していないし、おそらくURLバーの表示をきちんと見ない。その場合、ただ鍵マークが消えるより、警告マークが表示された方が、「何か異常が起きている」ことに気づく可能性が高い。ある日三菱東京銀行のサイトの鍵マークが消えたとして、一般ユーザーがはたして気づくだろうか?
いずれのケースでも、情報伝達方法としてどちらが優れているかは明らかだと思う。
うっかりの可能性があるから、つまり悪意があると決まったわけではない、ってことはHTTPに比べて危険性が有意に高いわけじゃないからね。銀行にとってみても、「金を出してるのに何で評価されないのか」ってのは当然監査の対象になってくると思うので、そっちの方が話が早い気がする。
別のケースがあるのを忘れてる。「慎重に設計してhttpとhttpsを使い分けてあるサイトなので、深刻な問題はない」というケースで、いかにもエラー表示っぽいのが出るのは、そのサイトの設計者が可哀想。
例えば、今時見かけないけど、画像だけはhttpで送る設定のブログなり掲示板なりで、通信路上で通信が乗っ取られて攻撃者に変な画像に差し替えられる危険性は残るけど、それ以上に深刻なトラブルには繋がらないから、サーバの負荷低減とのトレードオフで、まあいいか、と言うような。
その他、トラッキング被害(?)に逢うとか問題が起こる可能性はちらほらあれど、アカウントが乗っ取られるような絶対避けなきゃならない事態には陥らないしー、みたいな。
深刻な被害が出る設計かどうかはブラウザには判断しようがないので、せめて、エラーっぽくない見た目にしたげましょう、と。
# まあ、そんなマニアックな設計すな、という話ではある
必要最小限にSSL使って「問題はない」と設計したつもりなのにhttp扱いされるのは可哀想じゃないの?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
警告マークも出ないの? (スコア: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の色が変わるだけ」とチェックし
Re: (スコア:0)
セキュリティの知識のある人:
なぜ当該サイトがSSLじゃないのか理解できずに戸惑う
知識のある人は詳細を確認するから戸惑わないと思うが?
知識のない人:
問題があることに気づかない
たとえばここでログインするのにこれまでも警告マークでない。それも問題?
Re: (スコア:0)
詳細を調べればわかるのはあたりまえ。それ以前の、情報の伝達方法を言っている。
①知識がある人
警告マークが出た場合: 証明書に問題があると気づいて確認する
鍵マークが消えた場合: 非常にびっくりする。いったい何があった? 間違えてフィッシングサイトを見ているのか? SSLを使うのをやめたのか?
②知識がない人:
HTTPSの意味をよく理解していないし、おそらくURLバーの表示をきちんと見ない。
その場合、ただ鍵マークが消えるより、警告マークが表示された方が、「何か異常が起きている」ことに気づく可能性が高い。
ある日三菱東京銀行のサイトの鍵マークが消えたとして、一般ユーザーがはたして気づくだろうか?
いずれのケースでも、情報伝達方法としてどちらが優れているかは明らかだと思う。
Re: (スコア:0)
うっかりの可能性があるから、つまり悪意があると決まったわけではない、ってことはHTTPに比べて危険性が有意に高いわけじゃないからね。銀行にとってみても、「金を出してるのに何で評価されないのか」ってのは当然監査の対象になってくると思うので、そっちの方が話が早い気がする。
Re: (スコア:0)
別のケースがあるのを忘れてる。
「慎重に設計してhttpとhttpsを使い分けてあるサイトなので、深刻な問題はない」というケースで、
いかにもエラー表示っぽいのが出るのは、そのサイトの設計者が可哀想。
例えば、今時見かけないけど、画像だけはhttpで送る設定のブログなり掲示板なりで、
通信路上で通信が乗っ取られて攻撃者に変な画像に差し替えられる危険性は残るけど、
それ以上に深刻なトラブルには繋がらないから、サーバの負荷低減とのトレードオフで、まあいいか、と言うような。
その他、トラッキング被害(?)に逢うとか問題が起こる可能性はちらほらあれど、
アカウントが乗っ取られるような絶対避けなきゃならない事態には陥らないしー、みたいな。
深刻な被害が出る設計かどうかはブラウザには判断しようがないので、せめて、エラーっぽくない見た目にしたげましょう、と。
# まあ、そんなマニアックな設計すな、という話ではある
Re: (スコア:0)
必要最小限にSSL使って「問題はない」と設計したつもりなのにhttp扱いされるのは可哀想じゃないの?