2012-05-10 11 views
6

受信したコードが自分のフォームから来たものであり、外的な影響を受けていないことを保証する方法がありますか?基本的に私は誰かがアカウント作成など普遍的に利用可能なページに$_POSTをスプーフィングすることを望んでいません。アカウント作成ページにはどのユーザーもアクセスできますが、account_creationフォームから送信されたデータのみが処理されるようにしたいと考えています。

私が考え得る唯一のことは、$_SESSIONを開始してから、非表示入力を使用してフォームにsession_idを指定することでした。 $ _POSTのとき、隠された入力の値は現在のsession_idと照合されます。

この結果を得るためのより良い方法がある場合は、もし私がそれを聞くのを楽しみにしています。

答えて

7

データがフォームからのものであることを保証することはできません。 POST要求は単なるPOST要求であり、任意の数の方法で生成できます。 HTML形式は、の1つで、非常にユーザーフレンドリーです。サーバーは、POST要求を介して受信したデータが有効かどうか、およびそれに基づいて動作するかどうかを検証する必要があります。

このように、提出されているデータの制限と検証に役立つものがあります。まず、ユーザーが(セッション)Cookieを使用してログインしていることを要求します。これにより、匿名ユーザーによるランダムなリクエストが排除されます。第2に、トークンを隠しフィールドとしてフォームに埋め込み、ユーザーのセッションに保存することもできます。有効にするには、POST要求にそのトークンを含める必要があります。トークンは単なる擬似ランダム文字列です。
これを強化するには、ユーザーが送信すると予想されるフォームフィールドのハッシュを準備します。フォームの値を読み取り専用にする必要がある場合は、その値をハッシュに含めることもできます。例えば。:ちょうど簡単な例だ

$rand = md5(mt_rand()); 
$hash = sha1('lastname:firstname:email:' . $rand); 

$_SESSION['rand'] = $rand; 
$_SESSION['hash'] = $hash; 

// on form submit: 

$keys = array_keys($_POST); 
$checkHash = sha1(join(':', $keys) . ':' . $_SESSION['rand']); 
if ($checkHash != $_SESSION['hash']) { 
    die('Form submission failed token validation'); 
} 

は、おそらくそれはのためのユニークなトークンを持っている必要がユーザーの概念を示していますが、同じハッシュを取得しますなどを確認するために、アルファベットのキーをソートしたいと思いますそれぞれの要求はフォームによるテンパリングを防ぎ、必要以上のデータを提出することを防ぎます。

これは、ユーザーが実際にフォームを使用してデータを送信したという意味ではありません。

1

user_agent、user_ip、その他の$ _SERVER変数などの検証を追加するほうが少し優れています。これは私が使用する2つの変数です。

したがって、あなたが記述しているように一意のID(またはセッションID)を作成しますが、エージェントとipも一致することを少し余分に検証します。愚かな証拠ではなく、セキュリティのもう一つの小さな層を追加します。

編集:私はあなたにユーザーエージェントを送り返さないように付け加えるべきです。そのサーバー側を保持し、返されたセッションIDに対して黙って検証します。

投稿が妥当性検査に失敗した場合、その理由をユーザーに知らせることは絶対にありません。そのようにしてチートはあなたの追跡方法を知りません。あなたはまた、 "5人の恋人とあなたは"追跡を追加することができますが、あなたはそのためのログインを並べ替える必要があります。

1

セッションIDを使用することは確かにその1つの方法です。しかし、他のオプションがあります(すべてではないにしても)、いくつかのデータを隠しフィールドとして追加するオプションがあります。

  1. CAPCHAを使用してください。それは常に各ページの読み込みに固有なので、フォームを使用することが必須です。
  2. ランダムデータを生成してDBに格納し(または$_SESSION変数のみ)、フォームが送信されたらチェックします。

オプションは、ユーザ作成フォームにお勧めします。独自のフォームの自動提出を停止し、$_POSTのデータが自分のフォームから得られていることを確認します。

0

これは、XSRFを防止するための標準パターンパターンです。基本的にはあなたが言及したのと似ています。サーバーは、フォームがユーザー用にレンダリングされるときにランダムトークンを作成します。ユーザーのブラウザクッキーに関連付けられています。フォーム提出時に、サーバーにポストバックされます。サーバーはトークンと発行されたものを比較し、フォームのアクションは一致した後にのみ実行されます。

0

フォームに一意の値を設定し、サーバー側のセッションで格納されている値と照合することについて、よく言及しています。これを行うだけでなく、ユーザーが戻るボタンを使用してフォームを2回送信しようとした場合や、2つ目のブラウザウィンドウ(同じセッション!)を開いたり、サイトで複数のフォームを使用したりするとどうなるか考えてみてください。

あなたのシステムを考えないでクレイジーバグを作成しないでください。

+0

このことはありがたいことですが、私はこの行為の他の含意について考えることはできませんでした。これらの問題は、このif(!isset($ _ SESSION ['hash'])){create hash} else {use existing hash} 'のようなものを使って回避することができると思います。 –

2
$ref = $_SERVER['HTTP_REFERER']; 
if($ref !== 'some site path/index.php') 
{ 
    die("Access Denied!"); 
} 

これは、外部からの影響からデータベースにデータをポストからほとんどの人々を防ぐ必要があります。

関連する問題