質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.31%
WordPress

WordPressは、PHPで開発されているオープンソースのブログソフトウェアです。データベース管理システムにはMySQLを用いています。フリーのブログソフトウェアの中では最も人気が高く、PHPとHTMLを使って簡単にテンプレートをカスタマイズすることができます。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

CSRF

クロスサイトリクエストフォージェリ (Cross site request forgeries、CSRF)は、 外部Webページから、HTTPリクエストによって、 Webサイトの機能の一部が実行されてしまうWWWにおける攻撃手法です。

Q&A

解決済

2回答

555閲覧

会員登録画面から直接メールアドレスに認証コードを送る場合セキュリティ対策として確認画面を設けるべきでしょうか?

homepage-site

総合スコア70

WordPress

WordPressは、PHPで開発されているオープンソースのブログソフトウェアです。データベース管理システムにはMySQLを用いています。フリーのブログソフトウェアの中では最も人気が高く、PHPとHTMLを使って簡単にテンプレートをカスタマイズすることができます。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

CSRF

クロスサイトリクエストフォージェリ (Cross site request forgeries、CSRF)は、 外部Webページから、HTTPリクエストによって、 Webサイトの機能の一部が実行されてしまうWWWにおける攻撃手法です。

0グッド

2クリップ

投稿2025/04/28 07:23

編集2025/04/28 10:40

実現したいこと

会員登録画面からメールアドレスに認証コードを送りたい。

発生している問題・分からないこと

以前お問い合わせページを作成した際に CSRF対策として入力画面からワンタイムトークンを作成して、確認画面でそのトークンが一致するかどうかをチェックするという仕組みを作成したのですが、会員登録画面(入力画面)からメールアドレスに送るタイミングでワンタイムトークンを作成してチェックするということは可能でしょうか?

該当のソースコード

HTML

1<div class="login-email"> 2 <form method="post" class="register_form"> 3 <div class="form_item"> 4 5 <!-- <div class="login-inputWrapper"></div> --> 6 <!-- hiddenで生成したトークンを埋め込む --> 7 <!-- oninputプロパティは一定時間操作が無かったら処理を実行させる関数 --> 8 <input type="hidden" id="input-email" name="csrf_token" maxlength="15" oninput="value=value.replace(/[^\d]/g, '')" placeholder="メールアドレスを入力してください" value="<?= $csrf_token; ?>"> 9 10 <div id="error-msg-email" class="error-msg" style="display: none;"></div> 11 12 <div class="login-email_vertical-line"></div> 13 <div class="login-email-send clickable disabled"> 14 <font style="vertical-align: inherit;"> 15 <font style="vertical-align: inherit;">認証コードを取得する</font> 16 </font> 17 </div> 18 </div> 19 20 <div class="form_separator-line"></div> 21 <div class="form_item"> 22 <div> 23 <font style="vertical-align: inherit;"> 24 <font style="vertical-align: inherit;">ハンドルネーム</font> 25 </font> 26 </div><input placeholder="ハンドルネームを入力してください" maxlength="6" oninput="value=value.replace(/[^\d]/g, '')"> 27 </div> 28 29 <div class="form_separator-line"></div> 30 <div class="form_item"> 31 <div> 32 <font style="vertical-align: inherit;"> 33 <font style="vertical-align: inherit;">検証コード</font> 34 </font> 35 </div><input placeholder="確認コードを入力してください" maxlength="6" oninput="value=value.replace(/[^\d]/g, '')"> 36 </div> 37 <input type="hidden" name="csrf_token" value="<?php echo $csrf_token; ?>" /> 38 <!-- ↑追加 --> 39 <!-- </div> --> 40 </form> 41 </div>

PHP

1<?php 2$_SESSION = array(); //セッション変数の初期化 3session_start(); //セッションの開始 4 5// 変数の宣言 6// $error_message = ''; 7$mail = ''; 8 9// エラーが発生している時の処理 10/* if (!empty($_SESSION['error_message'])) { 11 $error_message = $_SESSION['error_message']; 12 unset($_SESSION['error_message']); 13} */ 14 15// ワンタイムトークン生成 16$toke_byte = openssl_random_pseudo_bytes(16); 17$csrf_token = bin2hex($toke_byte); 18 19// トークンをセッションに保存 20// トークンを保存、次の画面(PHP)に持ち越し 21$_SESSION['csrf_token'] = $csrf_token; 22 23// ワンタイムトークンの一致を確認 24// name属性「csrf_token」の中身が無い、または name属性「csrf_token」とセッション「csrf_token」が一致しない場合 25if (!isset($_POST['csrf_token']) || $_POST['csrf_token'] !== $_SESSION['csrf_token']) { 26 // トークンが一致しなかった場合 27 die('送信に失敗しました'); 28} 29 30// それぞれの変数に値を代入 31// PHPの値が空であれば 32if (!empty($_SESSION['mail'])) { 33 $mail = $_SESSION['mail']; 34 // セッション変数を削除 35 unset($_SESSION['mail']); 36} 37 38// ハンドルネームをメールで送信 39if (!empty($_SESSION['name'])) { 40 $name = $_SESSION['name']; 41 // セッション変数を削除 42 unset($_SESSION['name']); 43} 44 45// 確認コードをメールで送信(6桁) 46if (!empty($_SESSION['code'])) { 47 $_SESSION['code'] = rand(100000, 999999); 48 // セッション変数を削除 49 unset($_SESSION['code']); 50} 51?>

試したこと・調べたこと

  • teratailやGoogle等で検索した
  • ソースコードを自分なりに変更した
  • 知人に聞いた
  • その他
上記の詳細・結果

今後サーバーサイドでセキュリティ対策となるコードを書いていく際に確認画面を設けない場合にメールアドレスに直接送信する方法では攻撃を防ぎきれないのではないかと心配しております。

補足

※ 参考サイト
https://html-coding.co.jp/knowhow/security/csrf/

https://note.com/kohki/n/na9b4bddfa717

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

TakaiY

2025/04/28 12:38

何を心配していているのかがよくわかりませんし、質問で聞きたいことは何ですか? > 会員登録画面からメールアドレスに認証コードを送りたい 以前の質問でもコメントしましたが、会員登録時のメールアドレスの確認シーケンスは、単にメールアドレスの入力間違えなどが無く、登録しようとしている本人のものであることを確認するためのもので、セキュリティとは無関係です。 電話番号を口頭で聞いたときに、その場で掛けてみて確認するようなものです。 > 今後サーバーサイドでセキュリティ対策となるコードを書いていく際に確認画面を設けない場合にメールアドレスに直接送信する方法では攻撃を防ぎきれないのではないかと心配しております。 今後ということは、会員登録後、実際にその人にサービスを提供する時ということだと思いますが、そのとき「メールアドレスに直接送信する方法では攻撃を防ぎきれない」とは、具体的に何を心配しているのでしょう? そのことと、登録時のメールアドレス確認処理にどのような関係があるのでしょう?
homepage-site

2025/04/28 13:09

TakaiY さん回答ありがとうございます。 CSRF 攻撃に対するサーバーサイドでのセキュリティ対策のコードを書いていたのですが、会員登録画面から直接メールアドレスに認証コード送る際にもワンタイムトークンを作成してチェックする必要があり、確認画面を設けずに可能であるのか分からず質問致しました。 今後確認画面を設けずにメールアドレスに直接送信してサーバーサイド(PHP)のみでチェックすることの正否についての質問も混ざってしまいました申し訳ありません。登録時のメールアドレス確認処理とは関係ないです。
utm.

2025/04/28 13:31

他の質問での返信やり取りを見て思いましたが、sqlインジェクションによってメールアドレスが漏洩(公開)するような状況と混ざっているのでしょうか? セキュリティと単に書かずに具体的にどのような問題がどのような状態で起こるとお考えなのかを示したほうが回答がしやすいかと思います。 そもそも今回の例でセキュリティという言葉を再三使うのがちょっとニュアンスの違和感があるのですけども。 あるいは不正ログインの検証と混ざっていたり、なんかそれぞれのやり取りごとにコンテキストが全然違うような返信をなされているようです。 不正ログインの話をセキュリティといっているのであればまだ実態がつかめる感じはします。
TakaiY

2025/04/28 13:44

utm.さんど同じ印象です。 > 確認画面を設けずに可能であるのか分からず質問致しました。 「登録時のメールアドレス確認処理とは関係ない」ということは、登録済みユーザへのサービスの提供時のことで、CSRFと関連しているようですが、この、再三登場する「確認画面」とは、どのようなタイミングで何を確認するための画面のことですか? utm.さんの回答にもありますが、シチュエーションがはっきりしないとアドバイスが難しいです。
homepage-site

2025/04/28 14:52

utm. さん回答ありがとうございます。 1度の質問で複数の問題についてお聞きしてしまったのが原因だと思います申し訳ありません。 設計の段階で2パターンで悩んでおり CSRF攻撃を含めてどちらを選択すべきか決めかねておりました。 パターン1 入力→確認→メール送信 パターン2 入力→メール送信
homepage-site

2025/04/28 14:56

TakaiY さん回答ありがとうございます。 入力画面(会員登録画面)から送られてきた画面からは直接見えないワンタイムトークンを検証するために入力画面の次に表示させる画面になります。
utm.

2025/04/28 14:59

homepage-siteさん。 非常にわかりやすいご返信ありがとうございます。 申し訳ないのですが、どちらに関してもCSRF攻撃に関係がないかと思います。 CSRF攻撃の対策としてtokenの確認自体は必要なので、パターン1の確認がCSRFの文脈であれば、パターン1でよいと思います。 ただ、そもそもとしてCSRF関係ありません。 セキュリティとかCSRFとか意味を分かっていない言葉を乱用しているのが、原因だと思います。 が、今回のご返信は非常に明快でイメージの伝わりやすいものでした。 成長を感じられ協力の甲斐がありました。
homepage-site

2025/04/28 15:26

utm. さんアドバイスありがとうございます。 Javascript で動的にコンテンツを作成するうちに PHP よりも優先して使いたいという欲が出てしまいました。 もう一度安全なウェブサイトの作り方を読み直して脆弱性や攻撃について勉強しなおします。
guest

回答2

0

BAついていますが、乗り掛ったので、自分ならどうするかをちょっと書いてみます。

ただし、コメントでの説明に矛盾がありますがパターンの方を信じておくことにします。

パターン1 入力→確認→メール送信
パターン2 入力→メール送信

入力画面(会員登録画面)から送られてきた画面からは直接見えないワンタイムトークンを検証するために入力画面の次に表示させる画面になります。

(ワンタイムトークンを検証するなら、メール送信の後でないとできませんよね)


前提として、話は新規ユーザ登録の場面とします。メールアドレスを入力させてそのメールアドレス確認のためそこにワンタイムトークンオを送るのは、新規登録の時だけだからです。

クライアント(ユーザのブラウザ)上のJavaScript(JS)側でできることはできるだけやる方針とします。

サーバ: ユーザ登録画面をユーザに送る。

ユーザ: 必要な情報を入力する。 (メールアドレスを含む) OKボタンなどを押す。

クライアント(JS):

  • 入力内容のチェックを行なう。
    項目によりいろいろチェックできるが、メールアドレスであれば、サニタイズ程度でいいでしょう。また、2回入力させて入力ミスを減らす手法もよくあります(個人的にはきらい)。
  • 入力内容の確認画面/ダイアログを表示。
    登録時には確認画面があることが多い。 ユーザーがOKなどを押す。
  • 入力された情報をサーバのAPIにPOSTで送信
  • ワンタイムトークン入力画面を表示する。

サーバ:

  • 送られてきた情報をチェックする。
  • ワンタイムトークンを生成する。
  • DBに登録する。メールチェックを必須とするなら、仮登録)
  • メールアドレス確認のためのメールを作成して送信する。
    メール本文にワンタイムトークンを記載する。

ユーザ: メールに送られてきたトークンを画面に入力してOKを押す

クライアント:

  • 入力されたトークンをPOSTでサーバに送り次の画面に遷移する。

サーバ:

  • トークンを照合して、正しければ正常に登録完了。
  • 次画面として、登録衆力の画面を生成。

こんな感じでしょうか。

このシーケンスではメールアドレスの確認にワンタイムトークンを使っていますが、トークンを使うのではなく、メールに確認用のリンクを記載しそこからサイトにアクセスしてもらうことで登録完了となる方式も多いですね。


ログイン時のワンタイムトークンのやりとりは目的が異なり、ログインしてきたのが本人であるかどうかの検証のためです。 2要素認証ということになります。

クライアント: ログイン画面を表示。

ユーザ: IDとパスワードを入力。

クライアント:

  • IDとパスワードをPOSTでサーバに送信。
  • ワンタイムトークン入力画面を表示。

サーバ:

  • IDとパスワードを照合。
  • 問題なければ、登録されているメールアドレスにワンタイムトークンを送信。

ユーザ: メールで送られてきたトークンを入力してOKを押す。

クライアント:

  • 入力されたトークンをPOSTでサーバに送信
  • 次の画面に遷移

サーバ:

  • 送られてきたトークンを照合。
  • 問題なければログイン成功。 正常時の画面を用意。

こんな感じでしょうか。


コメントを受けて追記

コメントで以下の質問がありました。 意味が取れない部分があります。

入力画面(会員登録画面)から送られてきた画面からは直接見えないワンタイムトークンをセッションで送信後、メールに送られてきたトークンを画面に入力してOKを押す、トークンを照合して、正しければ正常に本登録完了という流れになるのでしょうか?

まず、元の質問では「ワンタイムトークンをセッションで送信」とありますが、意味が通じません。 単に用語の使いかたが間違えているだけだとは思いますが、セッションというのはWebでの一連の通信そのもののことなので、メールを送ることはできません。なので、勝手に以下のように推測します。太字とのところが修正部分です。

入力画面(会員登録画面)から送られてきた、(読点挿入)画面からは直接見えないワンタイムトークンをサーバからメールで送信後、メールに送られてきたトークンを画面に入力してOKを押す、トークンを照合して、正しければ正常に本登録完了という流れになるのでしょうか?

この内容だとすると、1つ違います。
ワンタイムトークンが「入力画面から送られて」来るように読めますが、回答に書いたシーケンスではワンタイムトークンはクライアント側で作るのでなく、サーバ側で作っています。なので、「入力画面(会員登録画面)から送られてきた画面からは直接見えない」の部分は不要です。
どうしても、クアイアント側で作りたいのであれば質問のとおりの動作になりますが、心配しているセキュリティの観点からすると、ワンタイムトークンがクライアントからサーバにそのまま送られることになり、無駄なデータのやりとりはすべきでないということになります。

投稿2025/04/29 02:17

編集2025/04/29 04:44
TakaiY

総合スコア14286

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

homepage-site

2025/04/29 03:32 編集

TakaiY さん解説ありがとうございます。メール送信自体が危険なことで送信前に対策が必要ではないかと思い込んでいたようです…攻撃について再度見返してみます。 サーバー側とクライアント側でそれぞれ考えをまとめたほうが分かりやすいですね勉強になりました。 Javascript では入力内容のチェックを行う目的でのみ使用する予定だったのですが増長してしまいました申し訳ありません。 ダイアログを表示させることは頭になかったのですがユーザー視点に立ってみるとよさそうですね。 サーバー側の.DBに登録する。メールチェックを必須とするなら、仮登録)という項目について気になったのですが、以前頂いたアドバイスを元に考えると、入力画面(会員登録画面)から送られてきた画面からは直接見えないワンタイムトークンをセッションで送信後、メールに送られてきたトークンを画面に入力してOKを押す、トークンを照合して、正しければ正常に本登録完了という流れになるのでしょうか? 新規登録の時にワンタイムトークンを送る目的はメールアドレスが正しいか確認するため、ログインの度にワンタイムトークンを送る目的は乗っ取り対策というのは前回の質問でアドバイス頂いていてまとめていたのですが、間違った知識の CSRF攻撃に対するセキュリティ対策のことばかり質問しておりました申し訳ありません。 もう一度安全なウェブサイトの作り方を読みながら進めてみます。
TakaiY

2025/04/29 04:07

> メール送信自体が危険なことで送信前に対策が必要ではないか 質問の本質はそこだったのですか? であれば、そのとおり書いていただくとよかったかもしれません。 > サーバー側とクライアント側でそれぞれ考えをまとめたほうが分かりやすい そうですね。 そういう考えは必須です。 > ダイアログを表示させることは頭になかった 質問に出てくる「確認画面」に相当すると思うのですが、違うとすると「確認画面」とはどのようなものを想定していたのでしょうか? メインの質問は、長くなりそうなので、回答本文に追記します。
homepage-site

2025/04/29 05:35

TakaiY さん回答ありがとうございます。 メール送信の際に必要な対策をお聞きした方が適切でした。 確認画面というのは入力画面から POST したものを PHP で表示するものになります。 セッションで送信ではなくセッションにトークンを保存しメールで送信するというのが正しい表現でした申し訳ありません。 ワンタイムトークンをクライアント経由でサーバに送信するよりワンタイムトークンをサーバ側で作る方が無駄なデータのやりとりをせずに済むという事なんですね勉強になりました。
TakaiY

2025/04/29 12:03

> 確認画面というのは入力画面から POST したものを PHP で表示するもの やはりよくわかりません。PHPでどこに表示するのでしょう? いずれにしても、メールで送信すべきトークンをどこかユーザの見えるところに表示する必要はありません。 > セッションにトークンを保存 だとすれば、セッションではなく、クッキーもしくはPOSTするデータ本体でしょうか。
homepage-site

2025/05/01 05:49

TakaiY さん回答ありがとうございます。 入力画面から確認画面遷移ボタンを押して確認画面に遷移して表示させるものになります。
guest

0

ベストアンサー

よく質問されているのであなたの力になりたいです。
まずログイン画面を作成していて、ユーザーにはメールアドレスを入力して欲しいのですよね。
それをサーバー側で検証するために確認画面を表示し、メールに送信するトークンを入力してもらいサーバーで検証する、ということであっていますか?

入力画面)からメールアドレスに送るタイミングでワンタイムトークンを作成してチェックするということは可能でしょうか?

可能です。どのタイミングでも可能ですよ。

質問内容がイエスノークエスチョンなので質問内容を工夫して見てはいかがでしょうか

会員登録画面から直接メールアドレスに認証コードを送る場合セキュリティ対策として確認画面を設けるべきでしょうか?

設けるべきでしょうか?ではなく、
設ける理由はなんでしょうか、
設けない方が良いでしょうか?
などと、理由を伺う形で質問してみましょう。

全体的に見てそもそも、通信プロトコルや攻撃に対する基礎的な知識が足りてない気もしますが、将来的に必要と感じるのであれば勉強してみても良いかもしれません。

CSRF攻撃は
一般のユーザーに対して、意図していないリクエスト情報を含むリンクを踏ませるなどをして、ログインユーザーの認証をすり抜け、意図したリクエストかのように偽装する行為です。

例えばteratailの投稿ボタンはHttpヘッダーを使いサーバーにこういう書き込みをしています!と送ります。
この時、あなたが私が送ったように偽装出来ないのはあなたが私のアカウントにログインできないからです。
ただ、私がログインしており、
あなたが作成したサイトで「サーバーにこういう書き込みをしています!」という情報をteratailに送るとしたら、CSRF対策をしていなければ、
ログインもしているし、書き込みをしようともしているということで正常に処理してしまうという攻撃です。
例えばHTMLのフォーム要素を他のサイトからコピペして、入力内容を書き換え、クライアントに送信ボタンを押させることでクッキー(セッション)やグローバルIPは正しい端末なんだけれども、ユーザーが意図した通信では無いのに実際に処理されてしまうという事態が発生するわけです。

メールアドレスにトークンを送るとか、
ユーザーが意図的にトークンをあなたの確認画面で入力するとかはこの攻撃に一切関係がないのです。

Teratailの質問時の推奨事項にもありますが、自分が何を分からないかを明確にしてみるのは難しいことでしょうか。

実際に、イエスノークエスチョンにはYESかNOで答えることをお望みですか?
あなたを手助けしたいと思っています。

投稿2025/04/28 11:53

編集2025/04/28 12:00
utm.

総合スコア784

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

homepage-site

2025/04/28 12:48

アドバイスありがとうございます。説明不足で申し訳ありません。 現在は確認画面を設けずに会員登録画面からメールに送信するトークンを入力してもらいサーバーで検証するというデザインで作成中ですが、確認画面を設けない場合にメールアドレスに送るタイミングでワンタイムトークンを作成してチェックするということは可能でしょうか?という趣旨の質問になります。 様々な会員登録サイトのログイン画面を確認したところログイン画面に確認画面を設けていないタイプもあったので疑問に思っていたのですが、どのタイミングでも可能なんですね勉強になります。 utm. さんがおっしゃるように理由を伺う形で質問したほうが適切ですね。 CSRF攻撃についての解説ありがとうございます。 ユーザーがログインしている場合に発生する攻撃であり CSRF対策をしていなければ、ユーザーが意図しない操作が実行される可能性があるという認識で合ってますでしょうか? 理由をお聞きしたかったのですがタイトルで伝えきれておりませんでした、以後自分が何を作成していて何が分からないか明確にして質問をするように気を付けてみます。
utm.

2025/04/28 13:25

おそれいりますが、画面遷移および処理のイメージを記載いただくことは可能でしょうか? > 会員登録画面からメールに送信するトークンを入力してもらいサーバーで検証するというデザインで作成中 システム->メールを送信、 ユーザー->会員登録画面でメールに記載のトークンを入力し送信、 システム->サーバーでトークンを検証 という話であっていますか? > 確認画面を設けない場合にメールアドレスに送るタイミングでワンタイムトークンを作成してチェックするということは可能でしょうか 今の話の中のどこから確認画面というのは出てきたのでしょうか? メールアドレスに送るタイミングとはどういう意味でしょうか? メールアドレスにトークンを付与するタイミング?ワンタイムパスワードを受け取ってないユーザーがどうやって検証を意図して行うのか、 ちょっと何を言いたいのか分かりません。。。 質問内容を修正いただきたいです。 > 様々な会員登録サイトのログイン画面を確認したところログイン画面に確認画面を設けていないタイプもあったので疑問に思っていたのですが、どのタイミングでも可能なんですね勉強になります。 ん?処理の流れをお伺いしたいです。 最大限読解試みますが、 ユーザー->ログイン画面でメールアドレスを入力する システム->トークンを発行し、メールアドレスに付与し、ユーザーに送る ユーザー->メールを確認し、トークンをサイト上で入力しログインを完了させる という流れで、最後の処理がないタイプがあるということですか? ログインとして成立していないでしょう。そのサイトの機能は。 > どのタイミングでも可能なんですね勉強になります。 入力画面からメールアドレスに(ワンタイムトークンを)送るタイミングでワンタイムトークンを作成してチェックするということは可能でしょうか? という意味ですよね? ワンタイムトークンを送るタイミングで当然、ワンタイムトークンを作成できますし、何とチェックするのかわかりませんが、トークンを作成のチェックはそりゃできますよね。チェックがなんのことでもいいなら、例えば今の時間をチェックするとか、まあなんでもできます。 別に入力画面からのタイミングであろうとなかろうといつでもできます。 勉強になったようで幸いです。 > CSRF攻撃についての解説ありがとうございます。 > ユーザーがログインしている場合に発生する攻撃であり CSRF対策をしていなければ、ユーザーが意図しない操作が実行される可能性があるという認識で合ってますでしょうか? ユーザーがログインしている場合に発生する攻撃というと前後関係が逆転していて気持ち悪いですね。 ユーザーがログインしていて、任意の操作を騙る攻撃です。認識があっている以前に 「私はこういう読解をしました。こういう認識であっていますか?」というような確認方法をしていただかないと、答えずらいというかおそらく何らかの意図あっての質問だと思うのですが、意図がつかみずらいです。 CSFRというのはあなたが今私に確認をしている攻撃の名称のことであって、可能性がどうとかそういう話じゃないのでは?と思います。おおむね解釈としてはあっているんじゃないかぐらいにしか言えないのですが。 https://www.ipa.go.jp/security/vuln/websecurity/csrf.html https://www.ipa.go.jp/archive/security/vuln/programming/web/chapter4/4-1.html 質問は以上でしょうか。 質問者ご自身で考えた情報とかが会話の中で解決のきっかけになるので積極的にコミュニケーションをはかろうとした方がよい気がします。 伝えなくてもわかるだろうぐらいのノリなのかもしれませんけども、会話が結構きついです。 (自分で名乗り出ていて恐縮ですが、友好的に言ったつもりだったのですが、もうご返信反応しないかもしれません。) おそらく質問者さんは開発全体の流れ等を理解していないかと思うのですが、勉強してみることは厳しい状態なのでしょうか。 https://www.ipa.go.jp/security/vuln/websecurity/index.html 今はGPTなどのAIも活用し疑問を解決できるようにも思えます。 今回のリアクションをみていて、私は本気であなたの悩みを解決したいからこそ、私と会話しながら解決を試みようとする方法がストレートに解決に向かわないのではないかと思えました。ご自身は前に進んでいる感覚ありますか? CSRFについてもメールアドレスの認証についてもそこまで理解が難解なものではないはずなので、何か理解の進め方が誤っているのだとは思うので直接話すことでほぐせるかなと思ったのですがこの方法ではだめみたいですね。
utm.

2025/04/28 13:41

頑張って譲歩してあなたの頭の中を解読しています。 あなたはもしかしてトークンと呼ばれるセッションをサーバーで常に保持しているからメールアドレスの送信をするだけで、ユーザーからの応答は関係ない的なことをおっしゃっているのでしょうか。
homepage-site

2025/04/28 14:21

回答ありがとうございます。デザインを考えた際にユーザーからは見えないトークンとは別に認証コードを Javascript で生成して、トークンは CSRF対策として認証コードは会員登録用として作成しようと考えていたのですが、utm. さんから教えていただいた通りトークンを検証した方が効率的ですね。 デザインにこだわりすぎて余計に整理できていなかったようです。 システム(会員登録画面から画面からは直接見えないトークン、認証コード送信)->メールを送信 システム->サーバーから送ったトークンと一致しているかどうかをチェック ユーザー->会員登録画面でメールに記載の認証コードを入力し送信、 システム->サーバーで認証コードを検証 会員登録画面から画面からは直接見えないトークンをメールアドレスに送信後に検証することで CSRF対策にならないかと考えておりました。 メールアドレス送信後に検証しても意味がないのではないかと思い、確認画面を設けるべきか悩んでおりました。 Javascript はセキュリティ対策の一環ではないということが分かっていながら、ワンタイムパスワードではなく認証コードで会員登録画面を作成しようとしていたのが問題だったようです…申し訳ありません。 確認画面というのを誤解していたようです。 必ずしも入力画面(会員登録画面)→確認画面→メール送信という形でないと CSRF対策は行えないものだと思っておりました。 参考サイトを見ると入力画面でワンタイムトークンを生成して確認画面でワンタイムトークンの一致を確認するものであり、理想とする確認画面を飛ばしてメール送信する形とは異なっていたので悩んでおりました。 読解した内容を先にお伝えしたほうが良いということで覚えておきます。第三者目線から考えていたのですが、第一者目線から考えるようにしてみます。 以前お問い合わせページを作成する際に安全なウェブサイトの作り方について読んでみたのですが理解できていなかったようで、見返してみます。 utm. さんからアドバイス頂いたように PHP を軸に進めた方が感じましたセキュリティ優先で進めてみます。 ※ 画面からは直接見えないワンタイムトークンを送信 https://note.com/kohki/n/na9b4bddfa717
utm.

2025/04/28 14:55

文章の書き方とかを整理してくれないとかなり読みずらいです。。。 整理すると javascriptで認証コードを生成する PHPでトークンを生成する 認証コードとはクライアントPCとサーバーサイドをつなぐためのコードである。 トークンとはメールアドレスとサーバーサイドをつなぐためのコードである。 という整理で大丈夫ですか? > システム(会員登録画面から画面からは直接見えないトークン、認証コード送信)->メールを送信 こんな会員登録画面からとか、認証コード送信とか書かれても、どのタイミングの話をしているのか一切わかりません。 サーバーサイドでトークン生成 -> クライアントサイドで認証コード生成 ですよね。認証コードの送信は何のタイミング?メール送信は何のタイミング?と読み手は混乱します。 > 会員登録画面から画面からは直接見えないトークンをメールアドレスに送信後に検証することで CSRF対策にならないかと考えておりました。 > メールアドレス送信後に検証しても意味がないのではないかと思い、確認画面を設けるべきか悩んでおりました。 メールアドレスとCSRFの関連性を記載していただけませんか?あなたの考えは間違っています。どこが間違っているのかを指摘したほうが早いと思います。 もう一度書きますが、メールアドレスとCSRFは全く無関係です。 あなたは何をどう解釈してそれらを紐づけているのですか? > Javascript はセキュリティ対策の一環ではないということが分かっていながら、ワンタイムパスワードではなく認証コードで会員登録画面を作成しようとしていたのが問題だったようです…申し訳ありません。 全く何を言いたいのか意味が分かりません。 > 確認画面というのを誤解していたようです。 > 必ずしも入力画面(会員登録画面)→確認画面→メール送信という形でないと CSRF対策は行えないものだと思っておりました。 > 参考サイトを見ると入力画面でワンタイムトークンを生成して確認画面でワンタイムトークンの一致を確認するものであり、理想とする確認画面を飛ばしてメール送信する形とは異なっていたので悩んでおりました。 CSRF全く関係ありません。 セッションハイジャックの話してる?マジで全く関係ないし、関係ないといってるのに話し続けるし、支離滅裂です。 > utm. さんからアドバイス頂いたように PHP を軸に進めた方が感じましたセキュリティ優先で進めてみます。 私、何もアドバイスした覚えがないんですけど、 jsで生成した認証コードとやらをサーバーに送って検証?は何のためかわかりませんが、 これは普通のセッションの方法であり、あなたはセッションの管理をサーバーがやってくれるのに一々自分で作ろうとしているのですか? また、通信の仕組みわかっていますか? システム システム と分割して二つのサーバーをまたいでいるかの様な描写がある意味がよく分かりません。 TLS/SSLハンドシェイクの話、httpsのプロトコルとごちゃまぜにしているのでしょうか? マジで会話が成立していないと思います。 せっかくコミュニケーションが取れるのに自分の考えや意見を十分に相手に伝えられないというのは非常にもったいなくないでしょうか。 多分解決しましたといって、似たようなことを何度も聞くんですよね。。。 デザインがあるなら画面遷移のイメージを質問文に記載することもできたはずですし、これってマジでどういった意図で投稿しているんでしょうか。 CSRFの理解はどうでもいいが、CSRFは対策したいみたいな感じを受け馬鹿にされている気分です。 理解がどうでもいいなら、結果的にどうなってもいいんですから、適当にやっても結果は変わらないじゃないですか。じゃあなんで質問するんですかって話ですよ。
homepage-site

2025/04/28 15:27 編集

回答ありがとうございます。トークンは CSRF対策のために後付けした機能になります。 javascriptで認証コードを生成してメールアドレスとサーバーサイドを繋ぐように考えておりました。 サーバーサイドとクライアントサイドの動きは別々にお伝えすべきでした以後気を付けます。 お問い合わせページについてのサイトを呼んでいたのでメールアドレスを送信する場合は CSRF攻撃への対策が必須だと勘違いしておりました、攻撃方法について読み返します申し訳ありません。 Javascript を多用することばかり考えておりました… お問い合わせページを作成した際は安全なウェブサイトの作り方をしっかり読んで対策を練ってから進めていたのですが、今回は外観ばかり考えて脆弱性や攻撃は二の次になっておりました。 しっかりと読んで調べてから作成してどうしても分からない場合に質問させていただきます…
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.31%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問