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

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

新規登録して質問してみよう
ただいま回答率
85.50%
セキュリティー

このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。

PHP

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

メール

メールは、コンピュータネットワークを利用し、 情報等を交換する手段のことです。

Q&A

解決済

5回答

789閲覧

予約システムのセキュリティについて(予約完了メールにエスケープ無しで入力値を入れることについての是非)

ringoman

総合スコア17

セキュリティー

このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。

PHP

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

メール

メールは、コンピュータネットワークを利用し、 情報等を交換する手段のことです。

0グッド

4クリップ

投稿2019/09/19 04:01

編集2019/09/19 07:00

現在予約サイトのセキュリティ見直しをしています。
社内に自分以外システム担当がおらず、自分もまだまだ勉強不足経験不足なため、幼稚な質問でしたら申し訳ございません。

~~<機能>
1.一般のユーザが予約フォームに氏名、住所、電話番号等の個人情報と、予約希望日時を入れる
2.確定ボタンを押すと、一般ユーザ、予約された店舗、弊社の管理者アドレスの3カ所に予約された旨を告げるメールが送られる
3.2と同時に、システム内で予約を行なったユーザの入力内容を弊社のDBに登録する
~~

<言語、関数>
PHP7
mb_send_mail()

<質問>
2.で送信先アドレスや、メール本文に1.でユーザが入力した内容を用いますが、エスケープされていません。
POSTで受け取った内容をそのままメールの宛先アドレスや、メール本文に使っています。
途中エンコードしているところはありますが、エスケープはされていません。
これはセキュリティ的には問題ないのでしょうか?
(第三者のアドレスが勝手に挿入されて勝手にメールを受信されたり、メール本文に勝手に不正なスクリプトなどを入れられたりしないのでしょうか?)

ちなみに、3.でユーザ情報をDBに登録する際にはエスケープしてからINSERTしています。

追記1:
<機能>
1.ユーザが個人情報、希望日時を入力すし、「確認画面へ」ボタンを押す
2.バリデーションチェックを行い、不正なら入力画面へ戻る。
正常なら入力内容確認画面を表示する
3.入力内容確認画面で確定ボタンを押すと、一般ユーザ、予約された店舗、弊社の管理者アドレスの3カ所に予約された旨を告げるメールが送られる
4.4と同時に、システム内で予約を行なったユーザの入力内容を弊社のDBに登録する

追記2:
送信するメールはテキストメール

追記3:
確認画面に遷移するタイミングでバリデーションチェックしてれば、Toに第三者の予期しないアドレスが入れられてしまうことはないですか?

よろしくお願いいたします。

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

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

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

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

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

m.ts10806

2019/09/19 04:07

htmlメールなのでしょうか?
ockeghem

2019/09/19 04:19

エスケープとはどのようなエスケープ処理を想定していますか?
ringoman

2019/09/19 05:47

>m.ts10806さん メール本文にはhtmlタグ使われておらず、テキストメールかと思うのですが、それだけでテキストメールであると判断してよろしいのでしょうか? 調べてみたのですが、htmlメールかテキストメールかの判別基準がよくわかりません。。。 初歩的な疑問ですみません、、
ringoman

2019/09/19 05:50

>ockeghemさん メール本文に不正なスクリプトを埋め込まれることを防ぐエスケープや、To、From(BccとCcは本システムでは使用していません)に不正なアドレスを入れられることを防ぐエスケープです。
m.ts10806

2019/09/19 05:58

エスケープとバリデーションを混同されてるように思います。そのあたり整理されては? htmlメールはきちんとそういうヘッダをつけて送信する必要があるのでなにもしてなければテキストメールです。
ringoman

2019/09/19 07:04

>m.ts10806さん 追記したのですが、確認画面に遷移するタイミングでバリデーションチェックしてれば、Toに第三者の予期しないアドレスが入れられてしまうことはないですか? Fromはコード内で直打ちしており、CcとBccは不使用なため、この3つは問題ないかと思っています。 他の方からの回答で、テキストメールであればスクリプト埋め込まれる心配もないかと思っています。
m.ts10806

2019/09/19 07:19

「メールアドレスとして正しい形式か」はチェックできても「その人のメールアドレスとして正しいか」はチェックできませんよ。入力者の自己責任です。 「不正なアドレスを防ぐエスケープ」と表現されていたので「それエスケープちゃう、バリデーションや」と突っ込みたかったのです。
ringoman

2019/09/20 04:56

>m.ts1086さん 不正なアドレスの表現が悪かったです。 おかげでバリデーションとエスケープの違いを改めて勉強できました。 突っ込みありがとうございます。
guest

回答5

0

ベストアンサー

確認画面に遷移するタイミングでバリデーションチェックしてれば、Toに第三者の予期しないアドレスが入れられてしまうことはないですか?

2つの観点があります。
まず、確認画面でバリデーションしても、その値をhiddenで引き回している場合は、送信画面へのリクエストを操作して不正なメールアドレスを指定される可能性があります。同じバリデーションを送信画面でも行うことで対策になります。
もう一つは、こちらの方が問題ですが、例えば悪い人が私のメールアドレスを知っていたとして、悪人がそのフォームで私のメールアドレスを入力することはできてしまいます。これは防ぐことが難しい問題ですが、「第三者の予期しないアドレス」をどう定義するのかという問題でもあります。一般的には、第三者のメールアドレスが指定できる事自体は許容してしまい、悪用されても大事に至らないようにメール本文側を工夫する(悪用の余地が少ないようにする)ことが多いです。


コメントに対する回答を追記します。

1つ目の観点に関しては、hiddenは使っていないのですが、それでも送信画面で再度バリデーションした方がよろしいでしょうか?

バリデーションするという考え方もありますが、通常はしないと思います。バリデーションしないことによる直接の問題はありません。

確認画面でバリデーションしてても送信画面を表示、確認ボタン(メール送信)押下の段階で攻撃者に不正なアドレス入れられたりするのだろうか?と。。

おそらくメールアドレス等をセッション変数に格納しているのだと思いますので、以下その前提で回答します。
ウェブアプリケーションに脆弱性があれば起こりえます。主にクロスサイトスクリプティング(XSS)脆弱性がある場合にそのような(あるいは類似の)現象が起きる可能性があります。

2つ目の観点に関しては、自分的には「第三者の予期しないアドレス」は、正規の手順で正規の目的のため(店舗に予約する)弊社サイトで予約を行なったユーザの予約確認メール(個人情報記載)が実は予期せず攻撃者のアドレスにも送られてしまうのではないかと考えていました。

これはクロスサイトスクリプティング(XSS)脆弱性がある場合は起こりえます。ただし、アプリケーションの作りにもよりますが、メールアドレスだけ差し替えることは通常難しく、問い合わせ内容なども含めて上書きすることになるので、メールアドレスを差し替えることによる情報漏えいは起きにくいかと思います。むしろ、クロスサイトスクリプティングそのものを使った情報漏えいの方が可能性が高いです。
クロスサイトスクリプティングがある(かもしれない)という前提では、情報をセッション変数で受け渡すよりも、hiddenパラメータで渡した方が攻撃はしにくくなります。セッション変数は情報をサーバー側で覚えているので、その覚えている情報が漏れる可能性があるのに対して、hiddenパラメータの場合は情報を覚えているのはブラウザであり、サーバー側の情報は保持されない(処理が終われば直ちに消える)からです。
クロスサイトスクリプティング脆弱性をなくすことが本筋ではありますが、上記に対する緩和策としては、用済みのセッション変数は直ちに削除することや、セッションタイムアウトを短くすることが考えられます。

ockeghemさんが例でおっしゃってくださったパターンだと、よく会員制サイトのパスワード変更などをしてパスワード変更完了を告げるメールが届いたときに記載してある「このメールに覚えがない場合は下記URLまでご連絡ください」といった文言があるもののことでしょうか?

これは直接関係ありません。このメールの意図は、攻撃者がなりすましでパスワードを変更した場合に、「パスワードが変更された」旨を利用者に通知し、利用者が意図したパスワード変更かどうかを確認してもらうためです。なので、メール送信自体は、セキュリティ強化の意図によるもので、このメールにより情報を盗むとか詐欺行為をしたいわけではありません。

投稿2019/09/19 07:11

編集2019/09/20 06:12
ockeghem

総合スコア11701

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

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

ringoman

2019/09/20 04:23

回答ありがとうございます。 1つ目の観点に関しては、hiddenは使っていないのですが、それでも送信画面で再度バリデーションした方がよろしいでしょうか? どちらかというと自分的には1つ目の観点を心配しておりました。 確認画面でバリデーションしてても送信画面を表示、確認ボタン(メール送信)押下の段階で攻撃者に不正なアドレス入れられたりするのだろうか?と。。 2つ目の観点に関しては、自分的には「第三者の予期しないアドレス」は、正規の手順で正規の目的のため(店舗に予約する)弊社サイトで予約を行なったユーザの予約確認メール(個人情報記載)が実は予期せず攻撃者のアドレスにも送られてしまうのではないかと考えていました。 そういう意味で「第三者の予期しないアドレス」と表現していました。 ockeghemさんが例でおっしゃってくださったパターンだと、よく会員制サイトのパスワード変更などをしてパスワード変更完了を告げるメールが届いたときに記載してある「このメールに覚えがない場合は下記URLまでご連絡ください」といった文言があるもののことでしょうか?
ringoman

2019/09/24 03:28

丁寧に回答していただき、ありがとうございます。 おかげさまで見直すべきはメールがどうとかよりクロスサイトスプリクティング対策の観点だということがわかりました。 大変助かりました。
guest

0

第三者のアドレスが勝手に挿入されて勝手にメールを受信されたり、メール本文に勝手に不正なスクリプトなどを入れられたりしないのでしょうか?

mb_send_mailを使って書く限り、fromは適切なものに制限されますし、テキスト形式のメールであれば、不正なスクリプトが入ってもただメール本文になるだけです。

投稿2019/09/19 04:08

maisumakun

総合スコア145121

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

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

ockeghem

2019/09/19 04:24

fromをadditional_headers(mb_send_mailの第4引数)に文字列として渡す場合は、メールヘッダ・インジェクションの可能性があります(配列で渡す場合は問題ないがPHP7.2以降の機能)が、今回の仕様だと、fromではなく、toに外部入力を指定することになりそうで、その場合は問題ないと思います。
ringoman

2019/09/19 05:39

>maisumakunさん 回答ありがとうございます。 メールの本文的にはhtmlタグは入っていないのでテキストメールかと思うのですが、メールの本文にhtmlタグ入っていないからテキストメールであると判断してしまってよろしいんでしょうか? それともこの関数使ってればテキストメールとか、この設定を行なっていればテキストメールとか明確にテキストメールかhtmlメールか判別できるようなものがありますか?
ringoman

2019/09/24 03:32

>maisumakunさん 回答ありがとうございます。 本件はテキストメールであると判明したので、メール本文になるだけとのことで安心しました。 大変助かりました。
guest

0

POSTで受け取った内容をそのままメールの宛先アドレスや、メール本文に使っています。途中エンコードしているところはありますが、エスケープはされていません。これはセキュリティ的には問題ないのでしょうか?

コード無いので適当な回答ですが、問題あります。
記述そのままであれば、スパムの発射台として使用できるかと。

表現としては「エスケープ」とはチョット違うかなぁ。。。

投稿2019/09/19 04:09

退会済みユーザー

退会済みユーザー

総合スコア0

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

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

ringoman

2019/09/20 04:43

追記したのですが、入力画面で入力した後「確認画面へボタン」があり、これを押下するとバリデーションチェックが走り、形式が不正なら入力画面へ戻り、正常なら確認画面を表示します。 確認画面に「予約確定ボタン」があり、これを押すと、メール送信、DB登録の処理が走ります。 会社のコードなのでなるべくコードは公開したくないのですが、特にどの段階で誰のアドレスがスパムの発射台にされそうかご教授いただけませんか? ユーザアドレスは入力画面でユーザが入力し、宛先アドレスとメール本文へバリデーション有エスケープ無しで使用されます。 店舗アドレスは弊社DBから取得し、宛先アドレスとメール本文にエスケープ無しで使われます。 管理者アドレスはコード内で直打ちしています。 スパム発射台について調べたのですが、メールアカウントのパスワード管理不足によるアカウント乗っ取りしか出てきませんでした。。。
退会済みユーザー

退会済みユーザー

2019/09/20 05:24

> 特にどの段階で誰のアドレスがスパムの発射台にされそうかご教授いただけませんか? すでに回答しています。 指針がないから悩むし、相談が要領をえません。コードも無いし。。。 セキュリティ要件の整理と設計からしてみては?
ringoman

2019/09/20 05:27

わかりました。 ありがとうございます。
guest

0

とにもかくにもJavaScript(一部を除く)やPHPは入力値をエスケープをするのが安全かと。

te2jiさんからご指摘いただきましたがこの場合はバリデーション(入力値検証)でした。

投稿2019/09/19 04:11

編集2019/09/19 11:49
kyoya0819

総合スコア10429

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

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

退会済みユーザー

退会済みユーザー

2019/09/19 04:14

本件だと、エスケープと言うよりは、バリデーションの問題かと。
kyoya0819

2019/09/19 11:44 編集

そうですね、バリデーションでした。 (普段あんまり人に向けて説明しないので自分自身混同してました)
ringoman

2019/09/24 03:29

回答ありがとうございます。 再度バリデーションとエスケープの違いについて勉強することができました。
guest

0

HTMLメールでなければ大丈夫だとは思いますが
HTMLは本来7bitJISエンコードするものなので基礎だけ抑えて置く必要はあります

予約システムとリンクしているなら
HTMLは登録されたことだけを知らせるアラートとして使えばよいような気もします

投稿2019/09/19 04:10

yambejp

総合スコア114572

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

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

ringoman

2019/09/20 04:57

本件はテキストメールであるということが発覚しました。 回答ありがとうございます。 助かりました。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

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

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

質問する

関連した質問