アカウント名:
パスワード:
何の問題もないのでは。フォームのページをクライアントが受け取る時点では何の問題もないでしょう。
送信内容に問題があってフォームが再表示される場合でもPOST 後ですから、https でしょう?
フォームのページの段階から https にするのは、ユーザにフォームの画面でも鍵のアイコンがブラウザに表示されることで安心感を漂わせるという気休め以外、何のメリットもありません。
その場合、そもそもフォーム画面に遷移する時点で疑ってない時点でアウトなのですが。
そこまで気にしているならサイト全体が https でなければダメでしょう。
Q1 は参考になりますかねぇ。
ぜなら、リンクを辿っている途中のページに https:/// [https] ではない http:/// [http] のページが1つでもあったなら、そのページが通信路上で改竄されていた可能性を否定できません。いつのまにか違うサイトへジャンプさせられている可能性があります。
と危険性を指摘しつつ
ページを移動するたびに見ている画面が https:/// [https] であることを確認するというのは、利用者にとって煩雑すぎる作業です。入力欄のあるページで利用者が重要な情報を入力をしようとしたそのときに、アドレスのドメイン名を確認し、https:// であることを確認するという手順が、シンプルかつ合理的です。
と、コストと合理性の面から言っていますね。
しかし、その入力フォーム画面が本当に目的に合致したフォームであるのかは、フォームへのリンクがある画面が https でなければ不安が残るように思いますが、どうでしょうか。
また、フォーム画面へのリンクは http であってもいいというのは、そのリンクが改竄されてスクリプトが埋め込まれていたりしている可能性も否定できないかと。
で、そのリンクがある画面へのリンクの改竄がないか……と辿っていくと、結局サイト全体が https になる必要がある、とかになってしまいませんか。そういう話です。
その入力フォーム画面が本当に目的に合致したフォームであるのかは、フォームへのリンクがある画面が https でなければ不安が残るように思いますが、どうでしょうか。
不安は無いですね。なにしろ https で取得した画面なのですから、そのサーバに実在する画面であることが保証されますからね。
前のページでスクリプトが埋め込まれていて、何か問題でも？
なりませんね。
リンクの書き換えが可能となってしまっては、Web アプリが XSS 脆弱性を持っている場合に利用される可能性がありますね。
脆弱性が万が一見つかった場合にでも被害を抑える方向での考慮の話ですよ。
SSL を利用したらその分負荷は上がる訳ですし、結局どのラインでトレードオフするかという話に過ぎないだけでしょう。
RCIS の記述だけを盲目的に信じてるだけというのもどうかと思いますが。
そもそも DNS ポイゾニングはどうだとかいうところまで Q5 は押さえている話だと解釈していますが、単に SSL をかけるのはフォームからで十分というのは、リーズナブルな解として出しているだけの話でしょう。
同一サーバ上にあっても目的が異なるフォームへの誘導などは全く防げない、といった点などが欠落していますよ。
嘘はいけないな。君がここでやっていることは、君の最初の失言 #1132884 [srad.jp]
何の問題もないのでは。フォームのページをクライアントが受け取る時点では何の問題もないでしょう。フォームのページの段階から https にするのは、ユーザにフォームの画面でも鍵のアイコンがブラウザに表示されることで安心感を漂わせるという気休め以外、何のメリットもありません。
が間違いだと指摘されたことに対する釈明なはずで、「脆弱性が万が一見つかった場合にでも被害を抑える方向での考慮の話ですよ」なんて支離滅裂もいいとこ。
たとえばアマゾンのようなオンラインショップにおいて、購入しようとした商品とは別の商品しか購入できないとか、購入ステップに入ろうとしても飛べない、知らない間に第三者のアフィリエイトプログラム経由で購入しようとしている事になっている、といった点が一切クリアできません。
アマゾンの場合は退会処理のためのフォームがないのでアマゾンではできませんが、購入しようとしたら退会フォームに飛ばされて購入できない、ということも考えられます。
ですから、何の問題もないと考えるのはお気楽過ぎとしか思えません。ユーザが求めているのはデータの安全性ではなく、そのフォームが含まれている一連のアプリケーションで達成される目的です。
安全が大事ではないというつもりはありませんが、安全でも目的が達成できないのであれば何の意味もありません。
確かに最初のは失言ですね。その事について書いていないのは私の落ち度です。
#1132927 [srad.jp] 以降は #1132923 [srad.jp] へのリンク先を読んだ上で、その内容に対しての納得できない部分について書いています。
なぜなら、リンクを辿っている途中のページに https:/// [https] ではない http:/// [http] のページが1つでもあったなら、そのページが通信路上で改竄されていた可能性を否定できません。いつのまにか違うサイトへジャンプさせられている可能性があります。
と、通信経路上での改竄まで視野に入れて話しているのであれば、送受信内容全てを疑っていなければ視点としては足りていません。
フォーム画面へのリンクが信頼できないにも関わらずフォーム画面が https であることだけを見て信じていいというのはそのフォームの安全性のみの議論でしかなく、#1132933 [srad.jp] で書いたように、求めていることが正しく行えている整合性を考慮した場合には不足していと思います。
#1132927 以降をその流れで読み直していただけたら、と思います。
この一連のコメント自体オフトピですからフィッシング対策に限った話だけする必要もないかと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
SSLの証明書 (スコア:0, すばらしい洞察)
>SSLのクライアント認証方式が挙げられるが、「この方式では、フィッシングに
>よるパスワード詐取の対策は可能だが、事前にユーザーに電子証明書を配布する
>必要があり導入コストが高いなどの問題があった」
SSLの証明書買うのに躊躇するような企業のサイトに、ログインして
個人情報を預けるほうが不安なんだがなあ。
# とりあえず、個人情報は500円換算で債権化しときますね
SSLはSSLで (スコア:0)
現状多くのユーザーにとってはただのお飾りにも近いものがあるからなぁ・・・
肝腎のパスワード入力画面に鍵マークが無いサイトとか。
オフトピ: https → http (スコア:1)
IE7.1ぐらいで使えなくすれば一発だと思うのだが。
Re:オフトピ: https → http (スコア:1, 興味深い)
それはモロ脆弱性だから、IPAに届け出まくればよいのでは？
Re:オフトピ: https → http (スコア:0)
Re:オフトピ: https → http (スコア:1)
何の問題もないのでは。フォームのページをクライアントが受け取る時点では何の問題もないでしょう。
送信内容に問題があってフォームが再表示される場合でもPOST 後ですから、https でしょう?
フォームのページの段階から https にするのは、ユーザにフォームの画面でも鍵のアイコンがブラウザに表示されることで安心感を漂わせるという気休め以外、何のメリットもありません。
Re:オフトピ: https → http (スコア:1)
>何の問題もないのでは。フォームのページをクライアントが受け取る時点では何の問題もないでしょう。
ダウト [aist.go.jp]．see Q2
Re:オフトピ: https → http (スコア:1)
その場合、そもそもフォーム画面に遷移する時点で疑ってない時点でアウトなのですが。
そこまで気にしているならサイト全体が https でなければダメでしょう。
Re:オフトピ: https → http (スコア:0)
具体的には KDDI の契約内容閲覧・変更とかのページだけどね。
勉強になった。
Re:オフトピ: https → http (スコア:0)
> そこまで気にしているならサイト全体が https でなければダメでしょう。
ダウト [aist.go.jp]. see Q1
Re:オフトピ: https → http (スコア:1)
Q1 は参考になりますかねぇ。
と危険性を指摘しつつ
と、コストと合理性の面から言っていますね。
しかし、その入力フォーム画面が本当に目的に合致したフォームであるのかは、フォームへのリンクがある画面が https でなければ不安が残るように思いますが、どうでしょうか。
また、フォーム画面へのリンクは http であってもいいというのは、そのリンクが改竄されてスクリプトが埋め込まれていたりしている可能性も否定できないかと。
で、そのリンクがある画面へのリンクの改竄がないか……と辿っていくと、結局サイト全体が https になる必要がある、とかになってしまいませんか。そういう話です。
Re:オフトピ: https → http (スコア:0)
不安は無いですね。なにしろ https で取得した画面なのですから、そのサーバに実在する画面であることが保証されますからね。
前のページでスクリプトが埋め込まれていて、何か問題でも？
なりませんね。
Re:オフトピ: https → http (スコア:1)
リンクの書き換えが可能となってしまっては、Web アプリが XSS 脆弱性を持っている場合に利用される可能性がありますね。
Re:オフトピ: https → http (スコア:0)
はいはいダウトダウト [aist.go.jp]。See Q5.
# /.のコメントだけに脊髄反射しないで、せめてリンク先全部見てから反論しましょうよ。はっきり言って見苦しいだけですよ。
Re:オフトピ: https → http (スコア:0)
Re:オフトピ: https → http (スコア:1)
脆弱性が万が一見つかった場合にでも被害を抑える方向での考慮の話ですよ。
SSL を利用したらその分負荷は上がる訳ですし、結局どのラインでトレードオフするかという話に過ぎないだけでしょう。
Re:オフトピ: https → http (スコア:1)
RCIS の記述だけを盲目的に信じてるだけというのもどうかと思いますが。
そもそも DNS ポイゾニングはどうだとかいうところまで Q5 は押さえている話だと解釈していますが、単に SSL をかけるのはフォームからで十分というのは、リーズナブルな解として出しているだけの話でしょう。
同一サーバ上にあっても目的が異なるフォームへの誘導などは全く防げない、といった点などが欠落していますよ。
Re:オフトピ: https → http (スコア:0)
Re:オフトピ: https → http (スコア:0)
嘘はいけないな。君がここでやっていることは、君の最初の失言 #1132884 [srad.jp]
が間違いだと指摘されたことに対する釈明なはずで、「脆弱性が万が一見つかった場合にでも被害を抑える方向での考慮の話ですよ」なんて支離滅裂もいいとこ。
Re:オフトピ: https → http (スコア:1)
たとえばアマゾンのようなオンラインショップにおいて、購入しようとした商品とは別の商品しか購入できないとか、購入ステップに入ろうとしても飛べない、知らない間に第三者のアフィリエイトプログラム経由で購入しようとしている事になっている、といった点が一切クリアできません。
アマゾンの場合は退会処理のためのフォームがないのでアマゾンではできませんが、購入しようとしたら退会フォームに飛ばされて購入できない、ということも考えられます。
ですから、何の問題もないと考えるのはお気楽過ぎとしか思えません。ユーザが求めているのはデータの安全性ではなく、そのフォームが含まれている一連のアプリケーションで達成される目的です。
安全が大事ではないというつもりはありませんが、安全でも目的が達成できないのであれば何の意味もありません。
Re:オフトピ: https → http (スコア:1)
確かに最初のは失言ですね。その事について書いていないのは私の落ち度です。
#1132927 [srad.jp] 以降は #1132923 [srad.jp] へのリンク先を読んだ上で、その内容に対しての納得できない部分について書いています。
と、通信経路上での改竄まで視野に入れて話しているのであれば、送受信内容全てを疑っていなければ視点としては足りていません。
フォーム画面へのリンクが信頼できないにも関わらずフォーム画面が https であることだけを見て信じていいというのはそのフォームの安全性のみの議論でしかなく、#1132933 [srad.jp] で書いたように、求めていることが正しく行えている整合性を考慮した場合には不足していと思います。
#1132927 以降をその流れで読み直していただけたら、と思います。
Re:オフトピ: https → http (スコア:0)
Re:オフトピ: https → http (スコア:1)
この一連のコメント自体オフトピですからフィッシング対策に限った話だけする必要もないかと。
Re:オフトピ: https → http (スコア:0)
終了。
文脈コロコロ変える馬鹿に相手してしてらんね。