アカウント名:
パスワード:
何の問題もないのでは。フォームのページをクライアントが受け取る時点では何の問題もないでしょう。
送信内容に問題があってフォームが再表示される場合でもPOST 後ですから、https でしょう?
フォームのページの段階から https にするのは、ユーザにフォームの画面でも鍵のアイコンがブラウザに表示されることで安心感を漂わせるという気休め以外、何のメリットもありません。
その場合、そもそもフォーム画面に遷移する時点で疑ってない時点でアウトなのですが。
そこまで気にしているならサイト全体が https でなければダメでしょう。
Q1 は参考になりますかねぇ。
ぜなら、リンクを辿っている途中のページに https:/// [https] ではない http:/// [http] のページが1つでもあったなら、そのページが通信路上で改竄されていた可能性を否定できません。いつのまにか違うサイトへジャンプさせられている可能性があります。
と危険性を指摘しつつ
ページを移動するたびに見ている画面が https:/// [https] であることを確認するというのは、利用者にとって煩雑すぎる作業です。入力欄のあるページで利用者が重要な情報を入力をしようとしたそのときに、アドレスのドメイン名を確認し、https:// であることを確認するという手順が、シンプルかつ合理的です。
その入力フォーム画面が本当に目的に合致したフォームであるのかは、フォームへのリンクがある画面が https でなければ不安が残るように思いますが、どうでしょうか。
不安は無いですね。なにしろ https で取得した画面なのですから、そのサーバに実在する画面であることが保証されますからね。
また、フォーム画面へのリンクは http であってもいいというのは、そのリンクが改竄されてスクリプトが埋め込まれていたりしている可能性も否定できないかと。
前のページでスクリプトが埋め込まれていて、何か問題でも？
で、そのリンクがある画面へのリンクの改竄がないか……と辿っていくと、結局サイト全体が https になる必要がある、とかになってしまいませんか。そういう話です。
なりませんね。
リンクの書き換えが可能となってしまっては、Web アプリが XSS 脆弱性を持っている場合に利用される可能性がありますね。
RCIS の記述だけを盲目的に信じてるだけというのもどうかと思いますが。
そもそも DNS ポイゾニングはどうだとかいうところまで Q5 は押さえている話だと解釈していますが、単に SSL をかけるのはフォームからで十分というのは、リーズナブルな解として出しているだけの話でしょう。
同一サーバ上にあっても目的が異なるフォームへの誘導などは全く防げない、といった点などが欠落していますよ。
たとえばアマゾンのようなオンラインショップにおいて、購入しようとした商品とは別の商品しか購入できないとか、購入ステップに入ろうとしても飛べない、知らない間に第三者のアフィリエイトプログラム経由で購入しようとしている事になっている、といった点が一切クリアできません。
アマゾンの場合は退会処理のためのフォームがないのでアマゾンではできませんが、購入しようとしたら退会フォームに飛ばされて購入できない、ということも考えられます。
ですから、何の問題もないと考えるのはお気楽過ぎとしか思えません。ユーザが求めているのはデータの安全性ではなく、そのフォームが含まれている一連のアプリケーションで達成される目的です。
安全が大事ではないというつもりはありませんが、安全でも目的が達成できないのであれば何の意味もありません。
この一連のコメント自体オフトピですからフィッシング対策に限った話だけする必要もないかと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
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)
> そこまで気にしているならサイト全体が https でなければダメでしょう。
ダウト [aist.go.jp]. see Q1
Re:オフトピ: https → http (スコア:1)
Q1 は参考になりますかねぇ。
と危険性を指摘しつつ
Re:オフトピ: https → http (スコア:0)
不安は無いですね。なにしろ https で取得した画面なのですから、そのサーバに実在する画面であることが保証されますからね。
前のページでスクリプトが埋め込まれていて、何か問題でも？
なりませんね。
Re:オフトピ: https → http (スコア:1)
リンクの書き換えが可能となってしまっては、Web アプリが XSS 脆弱性を持っている場合に利用される可能性がありますね。
Re:オフトピ: https → http (スコア:0)
はいはいダウトダウト [aist.go.jp]。See Q5.
# /.のコメントだけに脊髄反射しないで、せめてリンク先全部見てから反論しましょうよ。はっきり言って見苦しいだけですよ。
Re:オフトピ: https → http (スコア:1)
RCIS の記述だけを盲目的に信じてるだけというのもどうかと思いますが。
そもそも DNS ポイゾニングはどうだとかいうところまで Q5 は押さえている話だと解釈していますが、単に SSL をかけるのはフォームからで十分というのは、リーズナブルな解として出しているだけの話でしょう。
同一サーバ上にあっても目的が異なるフォームへの誘導などは全く防げない、といった点などが欠落していますよ。
Re:オフトピ: https → http (スコア:0)
Re:オフトピ: https → http (スコア:1)
たとえばアマゾンのようなオンラインショップにおいて、購入しようとした商品とは別の商品しか購入できないとか、購入ステップに入ろうとしても飛べない、知らない間に第三者のアフィリエイトプログラム経由で購入しようとしている事になっている、といった点が一切クリアできません。
アマゾンの場合は退会処理のためのフォームがないのでアマゾンではできませんが、購入しようとしたら退会フォームに飛ばされて購入できない、ということも考えられます。
ですから、何の問題もないと考えるのはお気楽過ぎとしか思えません。ユーザが求めているのはデータの安全性ではなく、そのフォームが含まれている一連のアプリケーションで達成される目的です。
安全が大事ではないというつもりはありませんが、安全でも目的が達成できないのであれば何の意味もありません。
Re:オフトピ: https → http (スコア:0)
Re:オフトピ: https → http (スコア:1)
この一連のコメント自体オフトピですからフィッシング対策に限った話だけする必要もないかと。
Re:オフトピ: https → http (スコア:0)
終了。
文脈コロコロ変える馬鹿に相手してしてらんね。