Q&A
「確認画面がないと脆弱性が生まれる」というのはCSRFのことを懸念してらっしゃいますか?
名前、フリガナ、メールアドレスのみのシンプルなフォームです。
当初、入力画面→確認ページ→サンクスページで作成したのですが、クライアントから「コンバージョンが落ちるので確認画面は無しにして欲しい」というリクエストがありました。
エンジニアの立場では、確認画面がないと脆弱性が生まれるので、営業にはそこは確認を取って欲しいと伝えました。
完了と勘違いして確認ページで離脱するのを防ぐには、確認ページで「まだ送信完了していません。内容を確認して問題なければ送信をクリックしてください」といった注意喚起をする（デザイン的にも目立たせるなど）という対策があるかと思いますが、どうするのがベストだと思いますか？
正解は無いような気もしますが、ご意見を伺いたいです。
もしくは「こういう手段がある！」というのがあれば教えていただきたいです。
はい、そのつもりで書きました。
CSRF対策のセキュリティートークンを、どの時点でフォーム送信データに持たせるものだと解釈していますか？
確認ページで発行して送信するものだと思ってますが…
CSRFってなんですか？質問者さんの説明を聞いてみたいです。
それを聞く意図をまず仰ってください。
> m6u 様
すみません、ワンタイムトークンを照合するのであれば、発行して送信するのは確認ページである必要はないですね。入力画面で発行して、送信処理の際に照合チェックする、という認識で間違っていないでしょうか？
赤の他人に質問しておきながら回答者側の質問に答えないとは、大丈夫ですか？
じゃあ質問者さんの思うCSRFのリスクあると思うので思った通り脆弱性の無い画面遷移にしたら良いんじゃないですかね。
別にあなたの質問に答えないとは言っておりません。いきなり「CSRFってなんですか？」と、こちらが理解していない前提であるような聞き方もマナー的にどうかと思いますけど。
それは大変失礼致しました。
質問文にはCSRFに関する記載が一切無く、本コメント欄の善意の有識者様のコメントによって質問者がセキュリティの観点からCSRFを気にしている事が初めて発覚しました。
その後も質問文は「どのようにCSRFを懸念した結果確認画面を挟もうとしているのか」の追記もされていないため確認の質問をさせて頂きました。
誠に恐れ入りますが、つきましては現時点で質問者様の思うCSRFをよそのサイトを見たりグーグル等で検索する事なくご自身の言葉でご説明頂けますか？
> m6u 様
すみません、下記の認識は合ってますでしょうか？
-----
すみません、ワンタイムトークンを照合するのであれば、発行して送信するのは確認ページである必要はないですね。入力画面で発行して、送信処理の際に照合チェックする、という認識で間違っていないでしょうか？
回答3件
0
「エンジニアの立場では、確認画面がないと脆弱性が生まれる」
確認画面がないことと脆弱性って無関係だと思いますが…
具体的にどんな脆弱性があるのでしょうか？
投稿2021/01/25 07:11
総合スコア3923
その理屈だとSPAにしたら脆弱性の山になるからやめましょうになりますね
Laravel なんて Route::resorce() でかいたら、confirm ありませんしね。
人並みの技術力を持つ人がチームに一人も居なかったらresource使用禁止になりますねえ・・・
自分の場合、いかに確認画面を省くか発注者を説得することが多いので、「確認画面」いらないって言われたら、ラッキー！！としか思わないです。
CSRF対策を勘違いしており、確認画面が必須だと思い込んでいました。たしかにその理屈だと、SPAは危ないということになりますね。ありがとうございました。
LGTM
> CSRF対策を勘違いしており、
では実際にはどういう懸念をしていたのか？が明確しないまま「関係無いから確認画面除去しよう」だと質問者のセキュリティの懸念は解決しないのでは？
正直言うと質問者がまるで理解していないとは思っており、その上で質問者の思うCSRFの説明を聞く事で問題視している内容と正しい対策の方向性が分かると思っての質問でしたが。
正しい理解を出来ていないようなので敢えて訊きますが、みたいな前置きのある言い方のが嫌ですよね？
なりすましによるフォーム送信を防ぐために、セッションに格納したワンタイムトークンとフォームで送信したトークンを照合し、一致した場合にのみ処理する、というのがCSRF対策だと理解しています。
ただ、過去に何らかの本かサイトで「本当に確認画面から来たのかどうかをチェックする」みたいな記述を読んだ記憶があり（たぶん初心者向けの本だったと思います）、ワンタイムトークンは確認ページで発行し、送信処理時に照合チェックを行うものと思い込んでいました。
まるで理解していないのかどうかは知りませんが、そのように思われるのであれば、詳細にご説明してもらえると有難いです。
最初に返答もせず逆質問をして尚且つマナーだどうだと失礼な態度取っておきながらなぜ教えて貰えると思うのか謎です。
自分の返答は
> じゃあ質問者さんの思うCSRFのリスクあると思うので思った通り脆弱性の無い画面遷移にしたら良いんじゃないですかね。
で終わってます。
ただ、「CSRF対策を勘違いしており、」と書くだけで終わっていたので本当の懸念点を明確にしなくて良いのか？という点だけ改めてオマケでコメントしただけです。
質問者の立場としては、結果的に内容に不足であったとしても丁寧に質問を書くように心がけています。初心者が質問することも多いでしょうし、不足があったり「コイツなに言ってんだ？」という内容も中にはあるでしょう。
回答者として、質問内容に何が不足しているのか、ここはどういう意図で書いているのか、この点に関する理解はあるのかを確かめるのに、横柄な聞き方をしていい理由がなにかありますか？
少なくとも、あなたの最初のコメントは質問者への配慮が見られません。あとから質問の意図を丁寧に書いてくださりましたが、（そこまで丁寧じゃなくても）なぜ最初から書かなかったのでしょう。
私の指摘が「失礼な態度」とおっしゃいますが、配慮のないコメントに対しては相応な態度になりますよ。あなたのその「教えてあげてんだから」という態度こそが、こういうナレッジサイトにはそぐわないと思います。
> 「コイツなに言ってんだ？」
んな事は思ってません。何とも思ってません。ただまあ知識の無い側からすると被害妄想的なものか知りませんが、「コイツなに言ってんだ？」と攻撃的に受け取る事は分かりました。
> 横柄な聞き方をしていい理由がなにかありますか？
知識が無い側にとっては「CSRFってなんですか？質問者さんの説明を聞いてみたいです。」の一文が横柄だと感じる事は理解しました。
> （そこまで丁寧じゃなくても）
こういう無駄な事書かないと気が済まない根性が根にあるなら有識者が無償で善意で回答してくれるこういうサイト使わないで全部自力でやればいいでしょ。
それか配慮して欲しけりゃ金払って先生になってくれそうな人探せばいいだけ。
> ナレッジサイト
ナレッジをご存知でないかもと思うので今回は最初から言いますが、配慮ではなく正しい情報の蓄積です。
ちなみにあなたに特別配慮する気には一切なりませんでしたが、ただの文章を横柄と感じたのはあなたの勝手です。
また、丁寧な質問文を書く人には特別配慮したコメントをする事もあります。
人の回答欄で通知ばかり迷惑だと思うので自分からは以上とします。
いえ、結局は人としてもマナーの問題に過ぎませんので。
>知識の無い側からすると被害妄想的なものか知りませんが
こういう表現をみれば分かります。
罵詈雑言のたびに通知来るので勘弁してください
本当にすみません。
0
投稿2021/01/25 08:22
退会済みユーザー
総合スコア0
ありがとうございます。
CSRF の対策もブラウザの進化とともに変化してきています。
https://qiita.com/mpyw/items/0595f07736cfa5b1f50c
まー個人的にはフレームワークの実装をそのまま使うのが適当な気がしてますが、参考まで。
0
ベストアンサー
手順が多くなるほど不具合も多くなり脆弱性も入り込みやすくなるので、むしろ確認画面は不要だと思ってます。
「送信していいかどうか」はモーダルなどで確認すべきでしょうけど、この有無も脆弱性やコンバージョンとは関係がない。
あとは結局要件次第。
むしろコンバージョン率に大きく関係するのはコンテンツの内容では。
いずれにせよ、どんな脆弱性が想定されるか具体化し、その対策をするだけです。
投稿2021/01/25 07:18
総合スコア80875
たしかに、手順が多くなるほど脆弱性が入る可能性も高まりますね。ありがとうございます。
確認画面通すとCSRF対策が2回必要になりますよね。
確認画面でCSRF対策が必要なのはなぜなのでしょうか？
確認画面では送信やDB登録の処理はないので、必要ないという認識だったのですが。
送信された情報の確からしさを確認する必要はありますよ。実装次第では、入力→確認と確認→完了の送信内容改ざんが可能です。
「入力画面からきた内容が間違いなく完了画面に来ているか」確認のためにはそれぞれきちんと経由されているかをチェックする必要があります。
CSRFの脅威がDB登録のみであるという根拠は何でしょうか？他のインジェクションと混同してませんか？
DB登録のみが脅威だという意味ではなく、トークンの照合を行うのが、フォームで一般的に処理されるメール送信やDB登録の時に行うもの、という意味で書きました。そういう認識にいますので、確認画面でなぜ入力画面で発行したトークンの照合が必要なのかが理解できていません。
メール送信もDB登録も「正しい情報が意図した場所から送られてきている前提」ですよね。
「正しい情報が意図した場所から送られてきている」確認は何でするつもりですか？
言葉足らずですみません。おっしゃる確認はトークンの照合で行うものと理解していますが、確認画面において「意図した場所から送られていることを確認するためにトークンの照合を行う」ことの必要性が分からないのです…
意図した場所以外から送り込まれる脅威がCSRFです。
意図した場所から送られない以上、何されてもおかしくはないです（我々が考えつかないようなことを平気でやってくるのがクラッカー）。
「問題ない実装」を担保したければトークン照合するしかないです。
現に、既存のフレームワークにはトークンがないリクエストをNGとする仕組みも実装されています。
なるほど。確認画面といえど、送られてくる内容によって思いもよらない処理が勝手に行われる可能性をなくす、ということですね。理解しました。たしかに、フレームワークでは至る所でトークンが埋め込まれていますね。ありがとうございます。
あなたの回答
tips
プレビュー
