SQLクエリで使用する前に、$_SESSION配列から何かをエスケープする必要があるかどうか疑問に思っています。
Cookieはセッションハイジャックに使用される可能性があると聞いているため、アプリケーションではCookieを使用しないことに注意してください(?)
どうもありがとう
SQLクエリに渡すすべての文字列を、その起源に関係なくエスケープする必要があります。
データベースから取得したデータであっても。
PHPにはまだエクスプロイトが明らかにされていないことを前提として、データベースへのアクセスを許可する前に、プリペアドステートメントまたはmysql_real_escape_stringを使用してすべてをエスケープする必要があります。
$_SESSIONに保存されているデータは常にクリーンであるとは限りません。マルチページフォームの場合、すべてをデータベースに書き込む最終ページまで、ユーザー入力を$_SESSIONに保存できます。$ _SESSIONが「クリーン」であると考える習慣を身につけると、最終的には問題が発生します。
エスケープするまで、システム内のすべてのデータがダーティであると想定する習慣を絶対に身に付ける必要があります。動的テーブル名を使用している場合、エスケープは役に立ちません。 ユーザーの近くに行ったことのあるクエリで、テーブル名または列名を使用しないでください。さまざまなエスケープメカニズムは、バックティックをエスケープしません。たとえば、準備されたクエリがある場合:
"SELECT * FROM `:aTable`;"
そして、aTableはユーザーから来ています。ユーザーは次のようなものを入力します。
` WHERE id IN (DELETE FROM user);
すべてのユーザーレコードを削除した可能性があります。
変数は、誤って使用された場合の変数$_SESSION
と同じである$_GET
ため、質問に対する答えは「はい」です。セッションにRAWユーザー入力を格納する場合(これは実行すべきではありません)、エスケープする必要があります。
セッション変数は、他の変数とまったく同じです。そこにあるデータはどこかから来ている必要があります。投稿された変数を直接そこに格納する場合、基本的には投稿された変数を使用するのと同じです。
唯一の違いは、セッション変数が異なるアクセス間で存続することであり、それはそれについてです。
データがあなた(つまりあなたのシステム)から発信されたものでない限り、 1つの黄金のルールはユーザー入力を信頼することは決してありません。それは「ユーザー入力」と見なされるべきであり、これには間違いなくセッションデータが含まれます。
SQLのセッションデータをエスケープするという条件では、mysql_real_escape_string()を使用するなど、SQLで使用するためにデータを効果的にクリーンアップすることができ、またそうする必要がありますが、セッションに含まれるデータに応じて、セッションに含まれるべきものに対してセッションを検証します。
Cookie /セッションハイジャックのコメントに関してあなたが何を意味するのかよくわかりませんが、データを保存するためにセッションのみを使用するという意味だと思いますか?通常のphpインストールセッションでは、Cookieを純粋にユーザーのセッションへのポインタとして使用します。