スレッド表示 | フラット表示〕 全トピック 920 件中 197 番目 次≫ ≪前

セッションが使えない場合での認証維持

created: 2006-08-22 12:28 | modified: 2006-08-27 10:06 | reply: 7

[3240] セッションが使えない場合での認証維持

user: さと | created: 2006-08-22 12:28
こんにちは。
早速ですが、私が借りている共用サーバーがクラスタリング環境というものらしく、セッション機能は使えないと言われました。
書籍などで勉強をしているのですが、ログイン認証のサンプルはセッションを使うものばかりで困っています。
代替案として考えたのは、最初の認証が通ったらIDとパスワードをクッキーに保存しておき、各ページでクッキーがあるか→クッキーのIDとパスワードを使って確認(MySQLのユーザーデータテーブルを参照)…と考えたのですが、この方法は問題はないのでしょうか? ご教授お願いします。
reply: 3245 3253 返信 編集 削除

[3245] セッションが使えない場合の認証照合

user: ゆうじ | created: 2006-08-23 18:21
こんばんわ。

クッキーにIDとパスワードを保存するのは危険です。
通信の傍受によって漏洩することが考えられます。
データの重要度によるところですが、
MySQLのユーザーデータテーブルというのが個人情報を含なら、
認証フォームの段階からSSL通信は必須でしょう。

通信傍受以外にも、
クロスサイトスプリクティングの脅威もありますので
万が一漏洩した場合の防衛措置も必要です。


クッキーを使うにしても、せめて、
認証がOKならば「一時的なユニークなID」を生成し
クッキーとサーバの両方に保存して、
これらを照合して認証済みの確認にすべきです。

さらに、ユニークなIDが漏洩した時のために、
IDの妥当性を確認する仕組みや、
すみやかにIDを無効にする仕組みが必要です。

今、コードをさわれないので、お時間頂ければ、
これらを考慮した自前のセッションハンドラに手を加えて見ます。

# このユニークなIDを使う方法は、
# PHPのセッションの仕組みを真似てみましたが、
# 実は、PHPのデフォルトのセッションハンドラも、
# IDが盗まれた場合の防衛措置がまったく無いので
# デフォルトのままユーザ認証に用いるのは危険です。
Parent: 3240  reply: 3250 返信 編集 削除

[3250] Re.セッションが使えない場合の認証照合

user: さと | created: 2006-08-25 13:07
ありがとうございます。

SSLに関しては今借りているサーバーに標準で付いているので、
使い方を調べて利用します。

XSSについては、JavaScriptを実行させない方法等は
書籍に書いてありますので対策を施したいと思いますが、
漏洩した場合の防衛措置とは、
それらのことを言っているのでしょうか。

「一時的なユニークなID」を使う流れについては
大体は理解したつもりなのですが、正直言いますと、
見本が欲しいのが本音です。自分のレベルでは残念ながら
書籍を真似していくしかありません。
ユニークIDを発生することもできないのですが、
IDの妥当性を確認するロジックも想像がつきません。
例えば、ユニークIDは認証者のIPアドレスを
使って生成されているので、たとえ同じユニークIDを使って
攻撃者がアクセスをしてきても、IPアドレスが違うから
認証者ではないと判断し、ユニークIDをDBから削除…と考えたのですが、
こういった感じでしょうか。

勉強不足で申し訳ありませんが、
よろしければ続けてご教授をお願いします。
Parent: 3245  reply: 3252 返信 編集 削除

[3252] 認証の保持・確認・破棄を行うクラス

user: ゆうじ | created: 2006-08-26 19:26
思いのほかてこずって遅くなりました。

XSSについては、JavaScriptを実行させない方法等は
書籍に書いてありますので対策を施したいと思いますが、
漏洩した場合の防衛措置とは、
それらのことを言っているのでしょうか。

いいえ。XSS対策やSSL通信は、
これらは情報が漏洩しないための対策ですね。

SSL通信と、XSS対策を施しても
ウイルスやスパイウェアなど、
ユーザの不注意で情報が漏れることもあります。
なので、クッキーにも、ID以外の情報は残さない。
さらに、他のユーザがそのIDを使っても
意味がないものにしてしまおう、という発想です。

漏洩した場合の防衛措置とは、
この、IDの妥当性を確認したり、古いIDを無効にしたり、
といったことを指しています。

ユニークIDを使う流れは、
さとさんが考えていらっしゃる通りです。


そこで、今使ってるセッションハンドラに手を加えて
認証状態の管理を行うクラスを書いてみました。
コピーして使ってみてください。
http://www.sound-uz.jp/php/archives/source/beAuth/beAuth.class.php

このクラスは、認証されたことを、
登録・確認・破棄するだけで、認証処理は含んでいません。
今の認証処理は変えずに利用できます。

■特徴
・登録の有効期限を秒単位で設定できます。
・指定の時間が経過するとuidを自動更新します。

使い方ですが、
あらかじめ、これ用のテーブルを作っておきます。
CREATE TABLE `beauth` (
`uid` varchar(50) NOT NULL default '',
`user_id` varchar(50) NOT NULL default '',
`time` int(11) NOT NULL default '0',
PRIMARY KEY (`uid`)
) TYPE=MyISAM;

BEAUTH_DSN を自分の環境に合わせて書き換えます。
define('BEAUTH_DSN', '・・・');

このファイルを、beAuth.class.php という名前で
include_path の通ったところに置きます。

あとは、ログイン・ログアウト、また確認を必要とする
ページで beAuth.class.php 読み込み、
下のコードを参考にそれぞれの処理に書き加えてください。

注意が必要なのは、
このクラス内からクッキーを送信してますので、
何かを出力(表示)する前に使用してください。
もしくは、output_buffering = On で使ってください。

また、クッキーはページを更新しないと有効になりませんので、
更新せずに処理を続けると誤動作することが考えられます。
可能な限り別のページに飛ばす処理を行ってください。


認証が通ったことを登録する場合
<?php
/*
* beAuth クラスをロード
*/
require_once 'beAuth.class.php';

/*
* beAuth 生成時は、
* '$beAuth = new beAuth();' を使わず
* 以下の静的メソッドでインスタンスを獲得すること
*/
$beAuth =& beAuth::getInstance();


/*
* ここは現在の認証処理に置き換えてください。
* ユーザ 'asdf1234' が認証OKとなったと仮定します。
*/
$user_id = 'asdf1234';


/*
* 登録する: $beAuth->regist($user_id)
*
* 引数:ユーザID(文字列)
* 戻り値:
* 登録成功:true
* 登録失敗:false
*/
if($beAuth->regist($user_id)) {
echo 'beAuth status: Login start<br>';
} else {
echo 'beAuth status: Login error<br>';
}
?>

登録を確認する場合
<?php
require_once 'beAuth.class.php';
$beAuth =& beAuth::getInstance();

/*
* 登録を確認する:$beAuth->registed()
*
* 戻り値:
* 登録済の場合:登録の際与えた$user_id
* 登録未の場合:false
*
*/
if ($id = $beAuth->registed()) {
echo "beAuth status: Login. user_id:$id<br>";
} else {
echo 'beAuth status: Logout<br>';
}
?>

登録を破棄する場合
<?php
require_once 'beAuth.class.php';
$beAuth =& beAuth::getInstance();

/*
* 登録を破棄する: $beAuth->destroy()
*/
$beAuth->destroy();

// 破棄されたか確認
if ($id = $beAuth->registed()) {
echo "beAuth status: Login. user_id:$id<br>";
} else {
echo 'beAuth status: Logout<br>';
}
?>
Parent: 3250  reply: 3257 返信 編集 削除

[3257] Re.認証の保持・確認・破棄を行うクラス

user: さと | created: 2006-08-27 10:06
わざわざサンプルを上げていただき、
ありがとうございます。
サンプルをテストして勉強します。
書籍よりもゆうじさんに講師になってもらいたいぐらいです。
Parent: 3252  返信 編集 削除

[3253] クラスタリングについて

user: ach | created: 2006-08-26 23:08
すみません,本題から外れますが,クラスタリングについてちょっと疑問に思ったことがあったので質問させていただきます.


セッションは通常テンポラリーディレクトリに一時ファイルを作成し,
そこにセッションのデータ配列をシリアライズして保存する,という手法を用いますよね.

でもサーバー管理者いわく
>クラスタリングのせいでセッションがつかえない
これはPHPが作成したファイルはクラスターごとに共有しないってことですよね.
ってことは,記憶装置を共有していないってことで,つまりは掲示板も正常には動かない.

ってことなんでしょうか?


分散処理系は使わしてもらったことがあるという程度なのですが,
記憶装置は記憶装置専用のクラスター(?)が全部持っていて,
NFSか何かでマウントして使うものなのでは……
Parent: 3240  reply: 3255 3256 返信 編集 削除

[3255] Re.クラスタリングについて

user: sato | created: 2006-08-27 09:31
> すみません,本題から外れますが,クラスタリングについてちょっと疑問に思ったことがあったので質問させていただきます.
>
>
> セッションは通常テンポラリーディレクトリに一時ファイルを作成し,
> そこにセッションのデータ配列をシリアライズして保存する,という手法を用いますよね.
>
> でもサーバー管理者いわく
> >クラスタリングのせいでセッションがつかえない
> これはPHPが作成したファイルはクラスターごとに共有しないってことですよね.
> ってことは,記憶装置を共有していないってことで,つまりは掲示板も正常には動かない.
>
> ってことなんでしょうか?
>
>
> 分散処理系は使わしてもらったことがあるという程度なのですが,
> 記憶装置は記憶装置専用のクラスター(?)が全部持っていて,
> NFSか何かでマウントして使うものなのでは……
Parent: 3253  返信 編集 削除

[3256] Re.クラスタリングについて

user: さと | created: 2006-08-27 09:40
日本語入力がONになってなく送信されてしまいました…。
パスワードも空だったので、上のレスは消せません。
すみません。

さて、

大した返事ではなく恐縮なのですが、
最初はセッションを使って書籍の通りにテストしたことが
あったのですが、その時はセッションは有効でした。
しかし、サポートで使えませんと明記してあるので、
サーバー管理者に問い合わせたところ
それはたまたま同じサーバーにアクセスしたからであって、
同じサーバーを使うとは限らないので使用できない…
といった返事をもらいました。

achさんの質問をチャンスがあったら、
サーバー管理者へ質問してみたいと思います。
Parent: 3253  返信 編集 削除
スレッド表示 | フラット表示〕 全トピック 920 件中 197 番目 次≫ ≪前
ページの一番上へ
Googleグックマークに登録 Yahooグックマークに登録 livedoorクリップに登録 @niftyクリップに登録 はてなブックマークに登録 deliciousに登録 Buzzurlに登録 FC2ブックマークに登録
最近更新された掲示板トピックス
管理人Blog
Yahoo Search

最近更新したNote
PHPマニュアル
今日のブックマーク
PHPマニュアル関数検索
関数名を入力し検索ボタンをクリック↑