CSRFの保護のポイントは何ですか？つまり、トークンを生成し、フォームにトークンを含む隠しフィールドを入れ、POSTが完了した後、2つのトークンを制御することです。私は私のウェブページとそれを回避するために全部をテストしていました - 私は、生成されたフォーム（HTMLソースコード）全体をコピーし、フォームアクション属性を変更しました。 Webボットが似たようなことを行っているのではないのですか？効率的なCSRFの保護を行うにはどうすればいいですか？私はKohanaの（セキュリティ::トークンとセキュリティ::チェック）を使用していCSRF、どのようにそれを調理する？
P.S
ありがとうございます！
Wikipediaから：
攻撃が 、ユーザーが知られているために（あるいは想定している） を認証されたためにサイトにアクセスし、ページ内のリンクやスクリプトを含めることによって動作します。たとえば、あるユーザーBobが、他のユーザーフレッドがメッセージを投稿した フォーラムのチャットをブラウズしている可能性があります。ボブの銀行はクッキーに自分の認証情報を保持している場合、 フレッドは（むしろイメージファイルより） ボブの銀行のウェブサイトでアクションを参照するHTML画像要素、例えば細工したこと
<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=Fred">
を仮定 クッキーの有効期限が切れていない場合、及び、その後、画像を ロードするために、ボブのブラウザでの試みは、このように はボブの承認なしに取引を認可する、彼のクッキーで出金フォームを送信します。
フォームにランダムなトークンを生成して含めると、投稿されたトークンが生成されたトークン（通常はユーザーセッションに格納されているもの）と一致するかどうかを確認することで攻撃を回避できます。
Kohanaのdocsは1つがそれを行うべきかはっきり言う：
あなたが隠しフィールドとしてフォームにこのトークンを挿入することができます。
echo Form::hidden('csrf', Security::token());
そして検証を使用したときにそれを確認してください。
$array->rules('csrf', array(
'not_empty' => NULL,
'Security::check' => NULL,
));
セキュリティトークンを生成してフォームで使用するための組み込みヘルパーは既にいくつかあります。トークンを生成し、それを隠しフィールドに挿入し、Validatorを使用してSecurityヘルパークラスに対して検証することができます。
は、ドキュメントを参照してください：http://kohanaframework.org/3.0/guide/api/Security#token
まあ、実際に私はあなたがそれを記入し、提出しなければならない基本的なPOSTフォームについて話していました。それがフォームの外に出てからそれを保護する方法（可能な場合）？ – Dmitri
これはCSRFではなく、あなたはそれを防ぐことができません。なぜなら、なぜあなたがしたいのか分からないからです。任意のWeb URLに任意のPOSTデータを送信できます。達成しようとしていることは何ですか？ – matino
Ah。私は多くの選択フィールドを持つフォームを持っています。このフォームを外部のどこかに提出することは望ましくありません（偽のものが投稿されるように）。だから、私の悪いアイデアの代わりに検証を行うべきですか？ – Dmitri