ユーザーがクエリ文字列パラメータを操作できないようにする

Question

状況：登録されていないユーザーがWebサイトを訪問し、アイテムのリクエストを発行します。現在のデータフローごとに、このリクエストは最初にdbに挿入され、リクエストIDは以降のページのURLに引き継がれます（ユーザーが詳細情報を追加する場合）。

問題：ユーザーはIDを変更できます。私がこれまで行ってきた何

：をできるだけ早く要求はにおけるlastInsertIdを（使用して挿入された後、私はIDを取得すると）、私は、セッション変数内に格納し、$ _GETからのIDに対して後続のページでご確認ください。私もCRSF保護を実装しましたが、トークンが一致するとセッショントークンは設定されません。したがって、ユーザーが同じURLをリフレッシュしても、チェックは失敗します。

この問題を解決するにはどうすればいいですか？私には欠けている概念を指摘してください。また、多くの同時ユーザーがリクエストを発行する場合、サーバーは、どのユーザーがどのユーザーのIDであるかを判別します。異なるユーザーのセッションIDは異なります。正しいですか？この並行性のために問題や脆弱性はありますか？

Answer 1

'（ユーザーが追加情報を追加する場所）'という行に基づいて、データを取得するためにある種のフォーム/ POSTを使用していると仮定します。 AtulBhatSコメントに記述されているテクニックを使用して、ハッシュされたデータを使用します。ハッシュされたデータをGETに設定するか、前述のフォーム/ POSTフィールドの隠しフィールドに設定できます。

基本的にはこのようなものです：

$id = $thisRequestIdOfYours; 
$hash = hash('sha512', 'aRandomSaltStringOnlyKnownByYourScript'.$id); 

（あなたが今のように、代わりにのみ$ IDを）だけの$ _GET、これら2つの値を使用します。または、隠しフィールドに設定します。そのためだけではデコードして取得変えることは非常に非常に難しい、スクリプト内で知られている「塩」（aRandomSaltStringOnlyKnownByYourScript）の

// Use $_POST if you use the hidden field way. 
if(hash(sha512, 'aRandomSaltStringOnlyKnownByYourScript'.$_GET['id']) !== $_GET['superSecretHash']) { 
    // h4x0r d3tect3d 
    die('you have no business here'); 
} 

：あなたがチェックを行うことができ、ポストの再送時に

手動で変更されたIDと一致するハッシュ

明らかに、すべてのパスのように、塩が強ければ強いほど、亀裂はより硬くなります。したがって、いくつかの空白、数字、または他の文字を投げ込んで、悪い人を捕まえます。

Answer 2

理想的には、秘密と思われるデータをURLに表示しないようにする必要があります。そのため、Pimのソリューションを適用して、ハッシュ値をcookieに保存することをお勧めします。