session - セッションは改ざんできますか?

Question

SQL インジェクションを防ぐために、すべての ASP コードをチェックする必要があります。

セッションオブジェクトもチェックする必要がありますか?

セッションはどのように乗っ取られる可能性がありますか?

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

Answer 1

SQL インジェクションを回避するには、文字列を連結して SQL クエリを作成する代わりに、パラメーター化されたクエリを使用します。セッションハイジャックは、まったく別のトピックです。リクエストごとにセッション Cookie を変更することでより困難にすることができ、HTTPS を使用することで完全に回避できます。関連する (そしてより大きな) 問題は、クロスサイト リクエスト フォージェリです (調べてください)。

Answer 2

セッションがハイジャックされる可能性があります。私の記憶が正しければ、Classic ASP は Cookie ベースのセッション ID のみをサポートします。誰かがその Cookie を盗むことができた場合 (盗聴)、正当なユーザーと同じセッションを取得できます。

セッションオブジェクトもチェックする必要がありますか? 場合によります。セッションに保存されているすべてのオブジェクトが「安全」である (入力がサニタイズされている) ことを確認できる場合は、セッション オブジェクトをスキップできます。アプリケーションのどこかで安全でないソースからデータを取得し、それを Session オブジェクトに入れる場合は、それもチェックする必要があります。

Answer 3

まあ、本当にユーザー入力を保護する必要があるだけです。したがって、自問しなければならない質問は、「このデータはユーザー入力から得られたものですか?」ということです。その場合は、SQL パラメータを使用する必要があります。

より大きなスケールでは、データ アクセスを実行するための個別のメソッドとクラスがあることを考慮して、SQL に提供するすべてのテキスト パラメータに対して SQL パラメータを使用する必要があります。このシナリオでは、SQL パラメーターは実際には必要ありません。メソッド パラメーターとして数値を受け取った場合、SQL インジェクションを行う方法がないためです。

ただし、疑わしい場合は、SQL パラメータを使用してください。

Answer 4

セッション変数は、サーバー上のメモリに保存されます。クライアントには Cookie ID のみが保存されます。クライアントからのものでない限り、セッション内の変数について心配する必要はありません。多くの場合、SQL インジェクションのためにデータベースに渡されたすべての変数をチェックする方が簡単です。