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

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

ただいまの
回答率

90.34%

ログイン型掲示板のセキュリティ対策

解決済

回答 2

投稿 編集

  • 評価
  • クリップ 4
  • VIEW 1,434

Nzc

score 258

現在,練習用にログイン型掲示板の制作を模索しています.その中で,Webアプリケーションのセキュリティ知識が不足しているため,いくつかご教授いただければ幸いです.

ログイン型掲示板として,PHP, phpMyAdmin, MySQLを用いたWebアプリケーション,並行してAPIを作成し,AndroidやiOSのクライアントアプリケーションからリクエストを送信可能にしようと考えております.ユーザをログインに用いるID, Passwordで管理し,送信者が,受信者(複数可)を設定できるようにします.SSLなしのHTTP通信を考えています.

  1. 一時キーを発行してのメールアドレス認証は安全か.
  2. POSTリクエストによるユーザ認証は安全か,もっと強固な認証方法はあるか.
  3. クライアント,サーバ両サイドでのハッシュ処理は妥当か.
  4. POSTリクエストによる個人情報を含むデータ送信は妥当か.
  5. URL引数による個人情報を含まないデータ送信は妥当か.
  6. HTTPS通信の優位性は何か.

の6点について,教えていただきたいです.1点でも知識をお貸しください.

以下,現在の設計を記載します. 現在考えているデータテーブルはこのような形です.

-- メッセージ保管テーブル 第3正規形
CREATE TABLE massages (
    message_id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
    sender_user_id BIGINT UNSIGNED NOT NULL,
    message_body LONGTEXT NOT NULL,
    sending_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP);

-- 受信者特定テーブル 第4正規形
CREATE TABLE receivers (
    message_id BIGINT UNSIGNED,
    receiver_user_id BIGINT UNSIGNED NOT NULL
    receiving_time DATETIME);

-- ユーザ情報テーブル 第3正規形
CREATE TABLE user_info (
    user_id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
    user_name TINYTEXT NOT NULL,
    user_mail_address TINYTEXT NOT NULL,
    user_password_hash INT UNSIGNED NOT NULL);

-- 未認証ユーザ情報テーブル 第3正規形
CREATE TABLE user_info (
    user_mail_address TINYTEXT PRIMARY KEY,
    user_one_time_key VARCHAR(8) UNSIGNED NOT NULL);

1. 一時キーを発行してのメールアドレス認証は安全か.

signup.php では,利用者はメールアドレスをPOSTリクエストにて送信します. サーバサイドでは,一時認証キーを発行,POSTリクエストを読み取り,未認証ユーザ情報テーブルに登録します.登録後,メールアドレスに,登録用の一時認証キー(英数字8文字程度)を送信します.

signup2.php では,利用者はメールアドレスと一時認証キー,パスワードをPOSTリクエストにて送信します.メールアドレスと一時認証キーは平文,パスワードは「ソルトを付与しつつ,複数回ハッシュ関数を通したもの」をPOSTリクエストによって送信します. サーバサイドでは,POSTリクエストを読み取り,未認証ユーザ情報テーブルに問い合わせ,検証が成功すれば,ユーザ情報テーブルに追加します.

この一時キーによって情報漏えいにつながることは少なく,メールアドレスによる登録数制限が可能であると考えています.これよりも簡易な手法はあるのでしょうか.また,この手法の危険性はあるのでしょうか.

2. POSTリクエストによるユーザ認証は安全か,もっと強固な認証方法はあるか.

3. クライアント,サーバ両サイドでのハッシュ処理は妥当か.

login.php では,利用者はメールアドレスとパスワードによって認証します. 認証は,平文のメールアドレスと,「パスワードにソルトを付与し,複数回ハッシュ関数を通したもの」をPOSTリクエストによって送信します. サーバサイドでは,POSTリクエストを読み取り,ハッシュ関数を通したパスワードに,更にソルトを付与し,ハッシュ関数を施します.このハッシュ値で,データベースに問い合わせてログイン処理とします.

POSTリクエストに情報を乗せるのは,URL引数に比べ安全かと思います.しかし,これ以外の送信手法について詳しくないため,これよりも安全性に優れるものがあれば,教えてください. パスワードのハッシュ化は,クライアントのみで行うと,容易に偽装可能である.サーバサイドのみで行うと,クライアントはパスワードをPOSTリクエストに平文で乗せなければならない.という問題があると思いますが,実際はどのように対処しているのでしょうか.POSTリクエストに平文を乗せても良いのでしょうか.実際,POSTリクエストは第三者からどこまで読めるのでしょうか.

4. POSTリクエストによる個人情報を含むデータ送信は妥当か.

insert.php では,利用者はコメントを送信します. コメントは,massagesテーブルのうち,receiving_timeを除くすべての要素を含むPOSTリクエストによって送信します. サーバサイドでは,POSTリクエストを読み取り,整合性の確認(ユーザの存在確認,本文の内容確認),HTMLパース可能な文字列のエスケープを行い,SQLインジェクション対策を行ってinsert文を実行します.

個人情報を含まないのであれば,POSTリクエストに平文が乗っていても大丈夫であると思っています.メッセージ本文には,個人情報を特定できる文が含まれる可能性がありますが,POSTリクエストを用いるべきではないのでしょうか.

5. URL引数による個人情報を含まないデータ送信は妥当か.

massages.php では,利用者はコメントを見ることができます. コメントは,receiversテーブルから,自分自身を含むmessage_idによって,messageをselectして出力します.URL引数による検索を備えます.例) massages.php&senderid=23

個人情報を含まないので,GETリクエストに平文を乗せようと考えております.

-- 依頼により追加 --

6. HTTPS通信の優位性は何か.

現在,すべての通信をSSLなしのHTTP通信で行うことを考えております. しかし,SSLなしのHTTP通信は、設定によりGET/POSTリクエストの中身が見えてしまう場合があるとお聞きしました.POSTリクエストはhidden属性によって,第三者から隠すことができる認識でおりましたが,この通りではない状況があるのでしょうか. また,SSLは,ブラウザとサーバ間の通信を暗号化し,その間の通信を盗み見ることを難しくする認識でおりました.これは,GET/POSTリクエストに対してどの程度効果があるのでしょうか.また,SSL+POST(hidden)ならば,その通信は秘匿されると考えてよいのでしょうか.

-- --

の6点について,1点でもいいので,教えていただければ幸いです.どうぞよろしくお願いします.

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

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

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

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • jinco

    2015/12/12 22:04

    SSLで暗号化されているのでしょうか?

    キャンセル

  • Nzc

    2015/12/12 22:08

    閲覧ありがとうございます.
    現在,利用しているレンタルサーバはSSLに対応しておりませんでした.

    キャンセル

  • jinco

    2015/12/12 22:35

    SSLなしのHTTP通信は、確か状況によってはPOSTでもGETでも第三者に丸見えになるのではないかと。。詳しい方の回答が待ち遠しいですね。

    キャンセル

  • Nzc

    2015/12/12 22:44

    hidden属性付きのPOSTは見えないと思っていましたが,大手のサイトではSSL通信が主流になっていますね.移行を検討します.ありがとうございます.
    はい.クリップ数からそれなりに需要のある項目だと思うので,詳しい方のご意見を聞きたいです!

    キャンセル

回答 2

checkベストアンサー

+5

まず、SSLによる途中経路の暗号化となりすましによる盗聴防止は全ての前提となります。 それが無いと全てが安全ではありません。 その上で

1. 一時キーを発行してのメールアドレス認証は安全か.  

基本的に問題が無いとは思いますが、

signup2.php では,利用者はメールアドレスと一時認証キー,パスワードをPOSTリクエストにて送信します.メールアドレスと一時認証キーは平文,パスワードは「ソルトを付与しつつ,複数回ハッシュ関数を通したもの」

これはクライアント側でjavascript等でのハッシュを想定していますか?クライアント側のハッシュ、暗号化はブラウザが実行できている時点でユーザが把握出来るので基本的に意味がありません。javascriptでハッシュ化したところでそのソースが読めてしまうため、途中経路で悪意を持った盗聴者が居た場合(当然そのjavascriptも把握していると考えるのが妥当)全くの無力です。 途中経路の暗号化はSSLに任せましょう。

サービス的な問題点としては、例えばgmailの場合、ピリオド及び+によってエイリアスが作れてしまうため
(例 examples@gmail.comのエイリアスとしてe.xamples@gmail.comとexamples+test1@gmail.comが無手続きで使用可能)
gmailを使う場合はこの方法ではメールアドレスによるユーザ登録制限は破綻します。
gmailに限って言えばエイリアスルールが明確なので対応が可能ですが、他のケースや使い捨てメールサービスの利用などがあるためメールアドレスによる厳密な制約をかけることは現実的に不可能です。

そのため、より厳密な制限を行う場合は、SMSや郵送などの個人が大量に取得することが困難な情報にトークンを紐づける場合が多いです。

2. POSTリクエストによるユーザ認証は安全か,もっと強固な認証方法はあるか.

途中経路で悪意のある第三者が盗聴をしようとしている場合、POSTとGETの安全性は「完全に同じ」です。  リファラーやブラウザの履歴を考えてフォーム値送信にPOSTを使うのは正しいですが、安全性が保障されるわけではありません。

3. クライアント,サーバ両サイドでのハッシュ処理は妥当か.  

クライアント側でのハッシュは基本的に意味がありません。
通信経路の暗号化はSSLが担当するべき領域です。

4. POSTリクエストによる個人情報を含むデータ送信は妥当か.

個人情報の扱いは技術的な問題というよりはポリシー的な問題ですが、一般的には非SSLで送信されるのはPOSTであろうと論外です。

5. URL引数による個人情報を含まないデータ送信は妥当か.

URL引数(GET)とPOSTは盗聴に対する安全性においては完全に同一なので、その操作がHTTP GETメソッドに相応しいか、HTTP POSTメソッドに相応しいかによって判断される部分です。目安としては「そのURLが再利用される可能性があるか(再利用しても良いものか)≒主に情報の取得を目的としている」場合はGETになります。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/12/12 23:42 編集

    回答いただきありがとうございます.大変参考になっております.SSL前提は必須条件なのですね。全くの無知でした.SSL通信と,その周辺セキュリティについて勉強してみます.
    クライアント側でのハッシュ計算は全く無意味ですね.クライアントサイドではソースコードを見れることが普通ですね.おっしゃる通りです.
    gmailのエイリアスは懸念事項でした.SMSや郵送の利用はユーザのアカウント数制限に大きな効果を発揮すると容易に想像されますね.しかし,その反面でコストが大きいですね.検討します.ありがとうございます.メールアドレスでやるなら,ホワイトリスト制で,エイリアスを排除しながらドメインを追加していくのもありですかね.
    POSTやGETの検討の前にまず,SSLなのですね.承知しました.「HTTP環境ではDigest認証なども聞かれますが,HTTPS環境では,GET/POSTの利用で十分なのでしょうか.それとも,重ねてOAuthを利用することで安全性の向上につながるのでしょうか.」重ねての質問ですみませんが,お教えください.
    「そのURLが再利用される可能性があるか(再利用しても良いものか)」これは大変重要なキーセンテンスですね.よく考えてPOST/GETを検討します.SSL通信でも,リファラーにGETリクエスト引数は残りますよね.原則POSTで,再利用するものに対し,GETを検討すべきですね.
    大変参考になりました.本当にありがとうございます.

    キャンセル

  • 2015/12/13 00:11

    Digest認証はあくまで認証情報をチャレンジレスポンス方式でハッシュ化しているだけなので、それ以外の情報は平文で流れるはずです(この点はうろ覚えなので、正確な情報はご自身で確認してください)。そのため直接比較するのは不適切ですが、正しく実装されたGET/POST+HTTPS通信はDigest認証+HTTP通信よりも確実にセキュリティ性能は高いです。

    キャンセル

  • 2015/12/13 03:15

    そうなのですね.SSLを利用するようにします.ありがとうございました.

    キャンセル

+2

6. HTTPS通信の優位性は何か.

SSL/TLS解説
HTTPSによる通信は、途中経路の暗号化、改竄からの保護、及び受信者が成りすましを行っていないことが保証されます。(所謂オレオレ証明書ではDNSポイゾニングやhostsの書き換えによる通信先の錯誤に対して無力)
(ただし、これはアルゴリズムやCPUの性能の進化によって陳腐化する可能性はあります。)

それに対してHTTPによる通信は全て平文で送信されるため、途中経路のあらゆる地点で盗聴が可能です。
暗号化されていない/wep等の脆弱な暗号化通信の無線LANの場合はその電波を受信できる人全員、 内部ルータの管理者、スイッチングハブの管理者、内部プロキシサーバの管理者、プロバイダの管理者、相手先サーバのルータ管理者、サーバ管理者、その他あらゆる箇所でです。

hidden属性は単純に「ブラウザがレンダリングする時に表示しない属性」であって、安全性とは一切関係ありません。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/12/12 23:58

    追記まで回答くださり,本当に丁寧にありがとうございます.
    SSLは改竄,成りすましも防ぐことができるのですね.
    hidden属性では,人に対して隠すことはできないのですね.まったく無知でお恥ずかしい限りです.知ることができて本当によかったです.今回回答いただいたことを元に,再度設計しなおしてみます.

    キャンセル

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

  • ただいまの回答率 90.34%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

同じタグがついた質問を見る