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

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

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

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

phpMyAdmin

phpMyAdminはオープンソースで、PHPで書かれたウェブベースのMySQL管理ツールのことです。

セキュリティー

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

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

PHP

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

Q&A

解決済

2回答

4154閲覧

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

退会済みユーザー

退会済みユーザー

総合スコア0

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

phpMyAdmin

phpMyAdminはオープンソースで、PHPで書かれたウェブベースのMySQL管理ツールのことです。

セキュリティー

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

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

PHP

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

1グッド

4クリップ

投稿2015/12/12 11:43

編集2015/12/12 13:58

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

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

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

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

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

SQL

1-- メッセージ保管テーブル 第3正規形 2CREATE TABLE massages ( 3 message_id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT, 4 sender_user_id BIGINT UNSIGNED NOT NULL, 5 message_body LONGTEXT NOT NULL, 6 sending_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP)7 8-- 受信者特定テーブル 第4正規形 9CREATE TABLE receivers ( 10 message_id BIGINT UNSIGNED, 11 receiver_user_id BIGINT UNSIGNED NOT NULL 12 receiving_time DATETIME)13 14-- ユーザ情報テーブル 第3正規形 15CREATE TABLE user_info ( 16 user_id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT, 17 user_name TINYTEXT NOT NULL, 18 user_mail_address TINYTEXT NOT NULL, 19 user_password_hash INT UNSIGNED NOT NULL)20 21-- 未認証ユーザ情報テーブル 第3正規形 22CREATE TABLE user_info ( 23 user_mail_address TINYTEXT PRIMARY KEY, 24 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点でもいいので,教えていただければ幸いです.どうぞよろしくお願いします.

KiyoshiMotoki👍を押しています

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

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

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

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

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

jinco

2015/12/12 13:04

SSLで暗号化されているのでしょうか?
退会済みユーザー

退会済みユーザー

2015/12/12 13:08

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

2015/12/12 13:35

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

退会済みユーザー

2015/12/12 13:44

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

回答2

0

ベストアンサー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

投稿2015/12/12 13:56

編集2015/12/12 14:31
tanat

総合スコア18709

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

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

退会済みユーザー

退会済みユーザー

2015/12/12 14:45 編集

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

2015/12/12 15:11

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

退会済みユーザー

2015/12/12 18:15

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

0

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

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

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

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

投稿2015/12/12 14:19

編集2015/12/12 14:43
tanat

総合スコア18709

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

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

退会済みユーザー

退会済みユーザー

2015/12/12 14:58

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

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

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

質問する

関連した質問