小さなサイトでシンプルなショッピング カートを作成しています。
カートのアイテムとログインした user_id をセッション変数に保存する予定です。
物事をもう少し安全にするために、私はこれを行うと思いました：
セッションに格納する前に、user_id を sha1() します。
また、sha1() を使用して http_user_agent 変数をいくつかのソルトとともに保存し、これを user_id とともにチェックします。
できることは他にもあることは知っていますが、これは少なくともかなり役立つと思いましたよね？簡単に実装できます。
セッションハイジャックの意味を誤解していると思います。あなたの最初のアイデアは、セッションのハイジャックをまったく防げないようです。
セッション ハイジャックとは、誰かのセッション ID を盗み、そのセッション ID になりすますことです。ユーザーは実際のセッション データを変更することはできません。そのため、何かを暗号化/ハッシュ化してもアクセスできないため、実際には問題になりません。
やりたいことは、IP とユーザー エージェント文字列をセッションに保存し、ページの読み込みごとにユーザーがログインしたことを宣言する前に確認することです。IP とユーザー エージェントが一致しない場合は、ログインを促す必要があります (少なくとも、ユーザー エージェントが同じであることを確認してください)。
これは少なくともかなり役立つと思いましたよね？
あまり。user_id はおそらくセッションの一部であるため、user_id をハッシュしても何も起こりません。
IP または UA をハッシュし、一致することを要求することは、検証の脆弱な形式であり、深刻なアクセシビリティの問題も引き起こします。プロキシ ユーザーは、毎回異なるアドレスから来る可能性があります。ユーザーは、定期的に変更される動的 IP を持っている場合があります。1 つの IP が多くの実際の顧客を表す場合があります。全体として、これは解決するよりも多くの問題を引き起こします。
いずれにせよ、IP と UA の両方が完全に一致する XSRF 攻撃に対しては、これは何もしません。アンチ XSRF 戦略については、この質問を参照してください。
一般に、セッション ハイジャックとは、個人が別のセッションへのアクセスを試みるという概念を指します。通常は、クライアント側のデータ置換によって行われます。
たとえば、人物 X が twitter.com のログイン フォームに入力します。Twitter.com が個人 X に Cookie を送信します。人物 Y は、パケットをスヌープし、その Cookie を手動でブラウザに挿入し、twitter.com にアクセスしてログインしていることを確認します。これがセッション ハイジャックです。
次に、リンクhttp://www.blah.com/?phpsessid=1234を提供するセッション固定があります。次に、URL の PHPsessid に気付かずに、そこにアクセスしてログインすることを祈ります。その場合、サイトがセッション ID を再生成しない場合 (アクセス許可の状態が変更された場合は常に再生成されるため)、ハッカーは blah.com/?phpsessid=1234 にアクセスでき、あなたとしてログインします。このようにして、彼らはあなたにセッション ID を与えたので、セッション ID を詮索する必要はありませんでした。
これは、基本的な PHP セッションのハイジャックを防止するための情報が掲載された優れたサイトで、調査の入門書になると思います。