32

私が最近頻繁に始めたことの1つは、タスクの開始時にデータを取得し、それを$_SESSION['myDataForTheTask']に格納することです。

今ではそうするのはとても便利なようですが、このアプローチを使用した場合のパフォーマンスやセキュリティリスクなどについては何も知りません。それは、より専門知識のあるプログラマーによって定期的に行われていることですか、それともアマチュアのことですか?

例えば:

if (!isset($_SESSION['dataentry']))
{
    $query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=" . mysql_real_escape_string($_GET['wave_id']);
    $result_taskinfo = $db->query($query_taskinfo);
    $row_taskinfo = $result_taskinfo->fetch_row();

        $dataentry = array("pcode" => $row_taskinfo[0], "modules" => $row_taskinfo[1], "data_id" => 0, "wavenum" => $row_taskinfo[2], "prequest" => FALSE, "highlight" => array());

        $_SESSION['dataentry'] = $dataentry;
}
4

15 に答える 15

20

さて、セッション変数は、訪問者がWebサイトにいる間ずっとこれらの変数を利用できるようにする唯一の方法(そしておそらく最も効率的)の1つであり、ユーザーがそれらを編集する実際の方法はありません(コード、またはPHPインタープリター)なので、かなり安全です。

これは、ユーザーが変更できる設定を保存するための良い方法です。セッションの開始時にデータベースから設定を1回読み取ることができ、そのセッション全体で使用できるため、設定があればさらにデータベースを呼び出す必要があります。が変更され、もちろん、コードに示されているように、設定がすでに存在するかどうか、または設定をデータベースから抽出する必要があるかどうかを確認するのは簡単です。

一時変数を安全に保存する他の方法は考えられません(Cookieは簡単に変更でき、ほとんどの場合これは望ましくないため)。そのため、$_SESSIONが最適です。

于 2008-09-16T22:26:16.180 に答える
6

私は常にセッション変数を使用して、ユーザーの情報を保存しています。パフォーマンスに問題はありません。セッションデータは、Cookie(またはCookieがオフになっている場合はPHPSESSID)に基づいてプルされます。他のCookieベースの認証よりもセキュリティ上のリスクが高く、実際のデータをユーザーのCookieに保存するよりも安全であるとは思いません。

ただし、SQLステートメントにセキュリティ上の問題があります。

SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=".$_GET['wave_id'];

ユーザーが提供したデータを取得し、それを使用して最初にサニタイズせずにSQLステートメントを実行することは絶対にしないでください引用符で囲み、関数を追加しますmysql_real_escape_string()。それはほとんどの攻撃からあなたを守ります。したがって、あなたの行は次のようになります。

$query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id='".mysql_real_escape_string($_GET['wave_id'])."'";
于 2008-09-16T22:24:43.173 に答える
6

$_SESSION メカニズムは Cookie を使用しています。

Firefox の場合 (新しい IE の場合もあるかもしれませんが、自分で確認しませんでした)、開いているタブ間でセッションが共有されていることを意味します。これは、デフォルトで期待するものではありません。これは、セッションが「単一のウィンドウ/ユーザーに固有のもの」ではなくなったことを意味します。

たとえば、サイトにアクセスするために 2 つのタブを開いた場合、最初のタブを使用して root としてログインすると、もう 1 つのタブで root 権限を取得します。

これは、特に電子メール クライアントやその他のもの (e-shop など) をコーディングする場合には、非常に不便です。この場合、セッションを手動で管理するか、常に再生成されたキーを URL に導入するか、何か他のことを行う必要があります。

于 2008-10-13T05:53:08.160 に答える
3

一時データを保存する場所を決定する際に考慮したいいくつかの要因があります。セッションストレージは、単一のユーザーに固有のデータに最適です。デフォルトのファイルベースのセッションストレージハンドラーが非効率的であることがわかった場合は、データベースまたはmemcacheタイプのバックエンドを使用して他の何かを実装できます。詳細については、 session_set_save_handlerを参照してください。

ユーザーのセッションに一般的なデータを保存するのは悪い習慣だと思います。複数のユーザーが頻繁にアクセスするデータを保存するのに適した場所があります。このデータをセッションに保存することで、このデータを必要とするユーザーごとにデータを複製できます。あなたの例では、このWaveデータ(wave_idに基づく)に対して、ユーザーのセッションに特に関連付けられていない別のタイプのストレージエンジンをセットアップする場合があります。そうすれば、データを一度プルダウンすると、複数のユーザーが別のプルを必要とせずにデータにアクセスできる場所にデータが保存されます。

于 2008-09-16T22:19:31.673 に答える
3

独自のサーバーで実行している場合、またはサーバー上のファイル/メモリをだれも詮索できない環境で実行している場合、セッション データは安全です。それらはサーバーに保存され、識別 Cookie がクライアントに送信されます。もちろん、問題は、他の人がクッキーを盗んで他の誰かになりすますことができるかどうかです. HTTPS を使用し、セッション ID を URL に含めないようにすることで、これらの問題のほとんどからユーザーを保護できます。(注意しないと、XSS が引き続き Cookie を奪うために使用される可能性があります。これに関する Jeef Atwoods の投稿も参照してください。)

セッション変数に何を保存するかについては、買い物かごなど別のページで再度参照したい場合はそこにデータを入れますが、この結果を生成するために使用される一時的なデータにすぎない場合はそこに入れないでくださいページ、現在表示されている投稿のタグのリストなど。セッションは、ユーザーごとの永続データ用です。

于 2008-09-16T22:21:10.827 に答える
2

入力の検証を改善する別の方法は、_GET['wave_id'] 変数をキャストすることです。

$query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=".(int)$_GET['wave_id']." LIMIT 1";

wave_id は整数で、答えは 1 つだけだと思います。

意思

于 2008-09-16T22:47:31.263 に答える
2

セッションを使用することの他のいくつかの欠点:

  1. $_SESSIONsession.gc_maxlifetime秒の非アクティブ状態が続くと、データは期限切れになります。
  2. session_start()セッション データを使用するすべてのスクリプトを呼び出すことを覚えておく必要があります。
  3. 複数のサーバー間で負荷を分散して Web サイトをスケーリングすると、ユーザーが毎回同じサーバーにリダイレクトされる必要があるため、問題になる可能性があります。これを「Sticky Sessions」で解決します。
于 2009-04-20T11:20:38.193 に答える
1

$ _SESSIONアイテムはセッションに保存され、デフォルトではディスクに保存されます。独自の配列を作成して、「dataentry」配列エントリに詰め込む必要はありません。$ _SESSION ['pcode']、$ _SESSION['modules']などを使用できます。

私が言ったように、セッションはディスクに保存され、セッションへのポインタはクッキーに保存されます。したがって、ユーザーはセッションデータを簡単に取得できません。

于 2008-09-16T22:16:34.630 に答える
1

IMO、セッションに物を保存することは完全に許容されます。これは、データを永続化するための優れた方法です。また、多くの場合、すべてをCookieに保存するよりも安全です。ここにいくつかの懸念があります:

  • 誰かがセッションを乗っ取る可能性があるため、それを使用してユーザー認証を追跡する場合は、注意が必要です。詳細については、これをお読みください。
  • これは、データを保持するための非常に怠惰な方法になる可能性があります。後でクエリを実行する必要がないように、セッションにすべてをスローするだけではいけません。
  • オブジェクトをセッションに保存する場合は、次のリクエストでセッションを開始する前にクラスファイルを含めるか、オートローダーを構成する必要があります。
于 2008-09-16T22:20:49.020 に答える
1

Zend Frameworkには、セッションデータ管理に役立つライブラリがあり、有効期限とセキュリティ(キャプチャなど)に役立ちます。彼らはまた、セッションの有用な説明を持っています。http://framework.zend.com/manual/en/zend.session.htmlを参照してください

于 2008-09-16T22:25:58.537 に答える
1

セッションは非常に便利ですが、注意すべき点がいくつかあります。

1) PHP は、サーバー上の他のユーザーがアクセスできる tmp フォルダーまたはその他のディレクトリにセッションを保存する場合があります。php.ini ファイルに移動して、セッションが保存されているディレクトリを変更できます。

2) 非常に厳格なセキュリティを必要とする価値の高いシステムをセットアップしている場合は、データをセッションに送信する前に暗号化し、復号化して使用することができます。注: トラフィックやサーバーの容量によっては、オーバーヘッドが大きくなりすぎる可能性があります。

3) session_destroy(); が見つかりました。セッションがすぐに削除されないため、PHP ガベージ コレクターがセッションをクリーンアップするまで待つ必要があります。ガベージ コレクターが実行される頻度は、php.ini ファイルで変更できます。しかし、まだあまり信頼性がないようです。詳細はhttp://www.captain.at/howto-php-sessions.phpをご覧ください。

于 2008-09-17T00:03:11.050 に答える
1

これがどれほどRESTフルかを考えてみてはいかがでしょうか?

つまり、「 A Brief Introduction to REST 」の「Communicate stateless」の段落を参照してください...

「RESTは、状態をリソース状態にするか、クライアントに保持することを義務付けています。つまり、サーバーは、単一の要求を超えて通信するクライアントのいずれかに対して、ある種の通信状態を保持する必要はありません。」

(またはRESTのウィキペディアの他のリンクのいずれか)

あなたの場合、「wave_id」はGETするのに適切なリソースですが、本当にそれをSESSIONに保存したいですか? 確かにmemcachedは、オブジェクトリソースをキャッシュするためのソリューションですか?

于 2009-03-11T13:05:00.493 に答える
0

私はこのアプローチをかなり使用していますが、問題はありません。Cookieとは異なり、データはクライアント側に保存されません。これは多くの場合、大きな間違いです。

ただし、他の場合と同様に、特にユーザー入力を$ _SESSION変数に入れて、後でSQLクエリでその変数を使用する場合は、常にユーザー入力をサニタイズすることに注意してください。

于 2008-09-16T22:17:00.137 に答える
0

$_SESSION は、ユーザーがアクティブにページにアクセスしている間に情報を保存するサーバー側の方法であるため、セキュリティ上非常に役立ちます。したがって、実際の php ファイルまたはサーバーに悪用される弱点がない限り、ハッキングするのは困難です。非常に優れた実装の 1 つは、ユーザーがログインしていることを確認する変数を格納し、ログインが確認された場合にのみアクションを実行できるようにすることです。

于 2009-04-29T16:15:33.687 に答える
0

これはかなり一般的なことであり、セッションは通常、連続したデータベース ヒットよりも高速になります。また、PHP 開発者はセッション ハイジャックを防ぐために懸命に取り組んでいるため、かなり安全です。

唯一の問題は、何かが変更されたときにセッション エントリを再構築することを覚えておく必要があることです。また、セッションを所有しているユーザー以外のユーザーが何かを変更して、このキーを更新する必要が生じた場合、このセッション キーを更新するようにシステムに通知する簡単な方法はありません。大したことではないかもしれませんが、知っておくべきことがあります。

于 2008-09-16T22:23:04.753 に答える