PHPで、とあるシステムのユーザーが使う管理画面を作っています。

ユーザーは、個々のID、PASSでログインし、
それ以降はFORMに保持されたID、PASSでPOSTの度にcsvデータとの認証を行っています。
※今のところ、セッション、クッキーを使っていません(^^;)

次の点についてご教授ください。

1.上記仕様のシステムで、ログアウトを実装するスマートな方法
(ブラウザで戻った時に認証切れを演出する方法など)

2.認証を伴うシステムの一般的な手法や、それらのセキュリティ強度
(セッション、クッキー、その他技術も含む)

皆様の知識や、参考URLなどをお願いいたします。

回答の条件
  • URL必須
  • 1人2回まで
  • 登録:
  • 終了:--
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

回答4件)

id:ito-yu No.1

回答回数323ベストアンサー獲得回数14

ポイント100pt

1. FORMにID、PASSを保持していると言うことは、FORMもPHPで生成しているということですよね。併せて、FORM生成時刻もhiddenで埋め込み、POSTデータを処理するときに現在時刻と比較、有効時間を超えていたらログインを無効としログイン画面にリダイレクトする(header(’location: ~’);などを使う)のはどうでしょう。

時間を記録・比較するにはtime()関数で十分でしょう。


2. セキュリティ強度について。

サーバーに侵入され、root権限を奪われたとき、、なんていう仮定ではないとして。

ID、PASSをhiddenで持ち回る方法や、BASIC認証はパケット解析で破られます。ダメダメです。

ワンタイムパスワード方式(ログイン/画面遷移ごとに認証キーを発行、サーバ側の認証キー/有効期限と付き合わせる)ならば、仮にパケットを読まれても有効期限以内でない限りセーフかもしれません。

いずれも、HTTPSにして経路を暗号化することで強度はアップすると思います。

id:webuser

1のご回答

なるほど〜大変参考になりました。

2のご回答

やはりHTTPSは最低限ですよね。。。

検討してみます。

他にも、後学の為、回答をお願いいたします。

1のみ、あるいは2のみでもまったく構いません。

2006/01/13 13:57:48
id:tomo_k No.2

回答回数426ベストアンサー獲得回数26

ポイント150pt

それでは、2のみ回答します。


hiddenでID,PASSを持ち回る方法はもっとも危険といえます。

たとえば、1の回答者の1の答えのように時刻をhiddenにもって有効期間を決めるような場合、そのHTMLを保存の上HTMLに手を加えることでいくらでもおかしなことがでてしまいます。

これと同じ理由で、hiddenといえどもどんな入力値があろうと想定外の動作をしないようにしましょう。具体的にはエラーである旨を返すようにすればよいと思います。


ほかに、クロスサイトスプリクティングの脆弱性が存在する場合、クッキーに格納されたセッション情報が盗まれる場合がある。

クッキーの属性情報の設定が不適切な場合、HTTPS通信をしていてもHTTP通信によってクッキーが送出される。

有効期限を長く設定しているとクライアント側の問題によって悪用される場合がある。

セッション管理にバグがある場合認証を経ずにアクセスされる場合がある。


対策としては、セッションに重要な情報を載せず、せっしょんIDのみにする。

セッションIDは十分な長さを持った乱数などを使う。

GETメソッドを受け入れないようにする。(POSTメソッドのみでのやりとりとする)

インシデント発生時に備えPOSTメソッドでやりとりした内容のログをとるようにする。これによって、問題があったときのすみやかな対応を可能とする。

入力データのチェックを確実にすべての入力項目hiddenやセレクトボックス、チェックボックスなどについても行う。

セッション管理はできるだけ言語やアプリケーションサーバに備えられている機能を使う。


一般にセキュリティ強度が高い方法としてはID、パスワードをできるだけ送信しない方法です。

たとえば、一度ID、パスワードで認証後セッション管理に移行する。その際にセッションIDに連番を使うことは非常に危険です。推測不可能なセッションIDを使う必要があります。リクエストごとにセッションIDを変更するのも有効です。

また、一回もID、パスワードを送信せずに認証する方法としてはハッシュ値を使う方法です。サーバ側から送信されたキーを元にハッシュ値を生成し、同時にサーバ側でも送信したキーを元にハッシュ値を生成しておいて、クライアント側から送信されてきたハッシュ値と比較するというものです。

http://takagi-hiromitsu.jp/diary/

高木浩光@自宅の日記

id:webuser

ご回答ありがとうございます。

参考URL読ませていただいております。

ハッシュ値の扱いに関するページがあれば、どなたかお願いいたします。

後学の為、引き続きお願いいたします。

2006/01/13 22:54:50
id:esecua No.3

回答回数510ベストアンサー獲得回数10

ポイント100pt

http://www.ipa.go.jp/security/awareness/vendor/programming/a01_0...

1-5. hiddenは危険(セッション変数を利用しよう)

私はまったくの初心者なので参考としてみていただければ幸いです。


以前私も似た質問をしたのですが、やはり危険が伴いどうしてもセキュリティを考えるとセッションの使用は避けれそうにないです。


セッションですとユーザー側ではなくサーバ側で情報が保持されますのでセキュアな認証を行うことが可能です。又毎回ランダムな文字で構成されたセッションでユーザーを判断するため認証後はサーバーにIDやパスワードを送信せずに認証状態を保持できます。従いSSLでの保護はログイン時のみとなります。


ログアウト機能ですが、これは単にセッションなどを破棄させればその後認証が確認されずログイン画面に戻すことが可能です。


PHPで認証システムを作成するのであればPearを使用すると容易に作成できます。標準ライブラリなので信頼できますし解説しているサイトも多く存在しますので初心者の方にもさほど難しいものではありません。ただどうしてもセキュリティの高さが求められるので最終的には詳しい方にソースに目を通してもらうのがいいかもしれません。

id:webuser

ありがとうございます。

SSLは予算の都合上無理になってしまった為、

最低限としてセッションを使おうと思います。

もし、セッションで認証を行うフリーのPHPがありましたら

教えていただくと幸いです。

2006/01/15 01:19:20
id:esecua No.4

回答回数510ベストアンサー獲得回数10

ポイント100pt

http://jp.xoops.org/

XOOPS Cube公式サイト - Simple, Secure, Scalable

ログインはソースを見られてしまうとセキュリティ的にも問題があるのでなかなか配布していないようです。


BASIC認証タイプは多く見かけますがログアウトができなかったりパスワードが平分で流れるなどの危険性もあります。


xoopsならはじめからログイン機能を搭載しており数多くのモジュールなどがあり、ポータルサイトを簡単に作成することが可能です。(アップしてインストールするのみ)


又ログイン機能はセッションでの管理なので安全なユーザー認証も簡単に実現できます。

id:webuser

ありがとうございます。

XOOPSは前から気になってたところでもあるので、

いろいろと勉強してみます。

2006/01/15 04:49:39

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません