2009-07-25 12 views
48

「ユーザー」テーブルのデータとユーザー名/パスワードを照合するログインスクリプトがあります。さらに、私は与えられたユーザーのアクセスレベルを指定する 'ロール'テーブルを持っています。安全なログインスクリプトを使用していると仮定すると、ログインの成功時に 'roles'テーブルに対して追加のクエリを実行してユーザーの認可レベルを検出し、これをセッション変数に格納するだけのセキュリティホールがありますか?したがって、混合された権限を持つすべてのページで、セッション変数を照会してログインしているユーザーの認可レベルを検出することができます。PHPセッション変数はどれくらい安全ですか?

ありがとうございました。

答えて

69

セッションは、クッキーよりもはるかに安全です。しかし、セッションを盗むことはまだ可能であり、そのため、ハッカーはそのセッションにあるものすべてに完全にアクセスできます。これを避けるためのいくつかの方法は、IPチェック(かなりうまくいくが、非常に低いので、それ自身では信頼できない)とノンスを使うことです。一般的にノンスでは、ページごとに「トークン」があるので、各ページは、最後のページのノンスと、それが保存したものと一致するかどうかをチェックします。

いずれのセキュリティチェックでも、使い勝手が低下します。 IPチェックを行い、そのユーザーが固定IPを保持していないイントラネットのファイアウォール(またはこれを引き起こす他の状況)の後ろにいる場合、IPを失うたびに再認証する必要があります。ノンスで、あなたはいつも楽しい "クリックするとこのページが壊れる"という状況が発生します。

しかし、クッキーを使用すると、ハッカーは簡単なXSS技術を使用するだけでセッションを盗むことができます。ユーザーのセッションIDをCookieとして保存すると、これも脆弱です。したがって、サーバーレベルのハッキングを行うことができる人にはセッションが忍耐強くても(サーバーが安全であれば、より洗練された方法と通常はいくらかの特権が必要になります)、さらに何らかのレベルの検証が必要になります各スクリプト要求時にクッキーとAJAXを一緒に使用するべきではありません。これは、クッキーが盗まれた場合、町に行くのが簡単になります。たとえば、ページでnonceが使用されていてもページが再ロードされない場合、スクリプトは一致するものだけをチェックしている可能性があります。そして、クッキーが認証方法を保持しているなら、今度は盗まれたクッキーとAJAXの穴を使って町に行くことができます。

+19

PHPはセッションIDをクッキーとして保存することに注意してください。 –

+0

+1ナンスについてもっと詳しく説明できますか?可能なリンク? – Petrogad

+5

nonceのwiki記事はかなり軽いですが、まともなリンクがあります:http://en.wikipedia.org/wiki/Cryptographic_nonce基本的な考え方は、理解しているようにトークンのようですが、一度しか使用できません1回使用)。各ページリクエストは最後のノンスをチェックし、新しいノンスを作成します。だからパスワードに無差別な攻撃をしようとすると、ナンセンスが2ラウンドで一致しないので、私はワンショットを手に入れます。セッションとそのページのナンスを盗んだ場合、リクエストを作成してノンセを更新するまでノンスの試合を捨てるようにリクエストする。それは私の要求と私のノンスを見るので、 – Anthony

16

サーバーで実行中のスクリプトのみが_SESSION配列にアクセスできます。セッションクッキーの範囲を定義すると、特定のディレクトリに制限することもできます。あなた以外の誰かがセッションデータを取得できる唯一の方法は、PHPコードをページの1つに注入することです。

使用しているシステムでは、これは許容され、データベース呼び出しを保存するのには良い方法ですが、適用するためには、ログアウトして再度ログインする必要があります。したがって、アカウントをロックアウトしたい場合、そのユーザーが既にログインしている場合は、ログインできません。

2

セッション変数の内部に格納されている値を使用してロールを決定すると、DBの値を変更してユーザーの現在のセッションに反映させることができなくなります。 Zend Frameworkを見ると、認証と認可の区別がはっきりしており、マニュアルではセッションに最小限のデータしか格納しないという警告が強く出ています(つまり、「彼はログインしました。ユーザーは#37 &ログインしました) 。

あなたが共有ホストにいない限り、 '安全性'については、心配することはありません。適切に構成された共有ホストでは、それらも比較的安全でなければなりません。

13

ApacheではPHP $ _SESSIONのスーパーグローバルがバーチャルホスト間でアクセス可能であることに注意してください。

  • サーバーでは、2つのドメインexample.comとinstance.orgをホストしています。 PHPセッションは、ドメインに制限されたCookieに格納されます。
  • ユーザーはexample.comにログインし、セッションIDを受け取ります。 Example.comはいくつかのセッション変数を設定します(これはサーバー上に保存され、クッキーには保存されません)。
  • 第三者が送信中にCookieを傍受し、それをinstance.orgに渡します。 Instance.orgはexample.comセッション変数にアクセスできるようになりました。

あなたのサーバー上のすべての仮想ホストを制御する場合、これは大したことではありませんが、共有マシンにいる場合は問題があります。

+1

可能であれば、仮想ホストごとに1つのSperglobalを制限する方法を知っていますか? – JRsz

+0

@JRszセッションがphp.ini ouのsession_save_path()関数(http://php.net/manual/en/function.session-save-path.php)に保存されているディレクトリを変更することができます。 – SandroMarques

関連する問題