問題タブ [csrf-protection]

jquery ui dialogフォームを表示するために使用しています。残念ながら、この関数csrf tokenはフォーム内の非表示の入力をクリアします。ダイアログがこのフィールドをクリアしないように強制することはできますか、またはこのトークンをどこかに保存して適切なフィールドを自分で設定する必要がありますか?

誰かがCSRFからアプリケーションを保護する方法に関する情報を教えてもらえますか？

これに関連するコード。

UIにはextjsを使用し、バックエンドではJavaを使用し、Tomcatサーバーを使用しています。

前もって感謝します。

Tomcat で CSRF の脆弱性を防ぐにはどうすればよいですか?

アプリケーションに Tomcat サーバーを使用していますが、CSRF 攻撃からアプリケーションを保護する必要があります。これを行うためのテクニックはありますか？

はい、こんにちは、今日は自分のサイトのハッキングを発見しました。

ユーザー ウォール (私のコミュニティ サイト) にメッセージを書き込むと、ajax 呼び出しが実行され、メッセージがデータベースに挿入され、成功するとスライドして表示されます。

問題なく正常に動作します。

だから私は少し考え直していました.これにはPOSTメソッドを使用しています.GETメソッドなら?msg=haxmsg&usr=12345679を簡単に実行できます. しかし、POST メソッドを回避するにはどうすればよいでしょうか?

私は新しいhtmlドキュメントを作成し、フォームを作成し、アクションで「site.com/insertwall.php」（通常はajaxで使用されているファイル）を設定し、私が行っているのとまったく同じ名前の入力フィールドをいくつか作成しましたajaxcall (msg, uID (userid), BuID (by userid) ) で送信ボタンを作りました。

ログインが必要な page_protect() 関数があることは知っています。そうでない場合は、index.php のヘッダーになります。だから私はログインし（私のsite.comでセッションを開始しました）、次にこの送信ボタンを押しました。そして、それが新しいメッセージを作成したことを私のサイトで見ました。

POSTメソッドをハイジャックするのはとても簡単だったので、もう少し安全か何かだと思いました。

このハイジャックを防ぐために何ができるか知りたいですか? 本当のハッカーがこの「穴」で何ができるか知りたくないからです。page_protect は、セッションが同じ http ユーザー エージェントからのものであることを保証します。これは正常に機能します (ログインせずにフォームを実行しようとすると、ヘッダーが startpage に表示されるだけです)。最初にそれを実行します。

どんなアドバイスも大歓迎です。私は ajax 呼び出しを可能な限り安全に保ちたいと思っており、それらはすべて POST メソッドで実行されています。サーバーまたは何かからのものであることを確認するために、insertwall.phpに何ができますか..

ありがとうございました

Django 1.2では、POSTフォームを実行すると、このCSRF検証エラーが常に発生します。私は、Django1.2ドキュメントで求められているすべてのことを実行したと「思います」。

1. MIDDLEWARE_CLASSESが「django.middleware.csrf.CsrfViewMiddleware」に含まれていることを確認します

2. {％csrf_token％}を確認します

   /li>

3. 私の応答でRequestContextを使用してください

   /li>

GETアクションはこの関数で機能することに注意してください。だから私はrender_to_responseを正しく使っていると思います。

@csrf_protectデコレータを挿入しようとしましたが、それでも機能しなかったようです。私はアイデアがなく、ラップトップで自分を窒息させようとしています。

皆さんが思いつくことはありますか？

ありがとう！

私のサイトでアクションがあります：

これにより、現在のユーザーがセッションからログアウトされます。これは単純なGETリクエストであるため、悪意のあるユーザーがこのページへのリンクを作成するか、このリンクを画像のsrc属性に配置して、ユーザーを強制的にログアウトさせる可能性があります。ログアウトリンクのシンプルさを行き過ぎずに維持したいのですが、同時に上記のシナリオが発生しないようにしたいと思います。

何か案は？

CodeIgniterで非常に奇妙なCSRF保護の問題が発生しています。form_openを使用してフォームを開始し、構成ファイルでcsrf_protectionがtrueに設定されていることを確認しました。また、非表示のcsrfの名前と値のフィールドがcsrf cookieと一致していることを確認しました：http：// d .pr/3cfB。

フォームを送信すると、「エラーが発生しました。要求されたアクションは許可されていません」というメッセージが表示されます。エラーが発生し、理由がわかりません。csrf_protectionをオフにすると、フォームは正常に機能します。

さらに奇妙なのは、認証にtank_authライブラリを使用し、ログインフォームにもform_openを使用していることです。csrf_protectionがオンのときにログインフォームに非表示のcsrfフィールドがあることを確認し、フォームを送信して問題なくログインできました。

この問題をデバッグするために何ができるかについての考えはありますか？

「ライブ」データを表示するために Web ページの 1 つで使用される JSON Web サービスがあります。このページにアクセスするには、ユーザーがログインする必要があります。私たちは、悪意のあるサイト (競合他社) がこのデータを収集できることを懸念しています。しかし、私たちが予想している問題がもっともらしいかどうかはわかりません。

ユーザーがログインすると、「remember me」Cookie がユーザーのマシンに保存されます。誰かが私たちの Web サービスに AJAX リクエストを送信し、ログインしているユーザーにそのサイトにアクセスするように仕向けるサイトを構築した場合、彼らは私たちのサービスから情報を取得して保存することができるでしょうか? もしそうなら、どうすればそのようなことから身を守ることができますか?

例えば：

悪意のある Web サイトが次のようなスクリプトを作成してデータを取得する可能性があります。

彼らは私たちの JSON フィードをヒットしているので、私たちのサイトに Cookie を送信しないで、ユーザーは認証されます。それらは認証されるので、機密データを送り返しませんか?

私は奇妙な問題を抱えています。最近、AJAX 経由で投稿されたテキスト フィールドでエラーが発生していることに気付きました。調査の結果、この POST AJAX リクエストでセッションがリセットされることがわかりました。csrfの問題だと思いました。トークンを確認したところ、レイアウト ファイルのように正しく渡されています。

そして、私の AJAX リクエストは次のようになります。

しかし、デバッガーでは、csrf トークンが既にハッシュされているトークンとは異なることに気付きました。私はこれらすべてを理解することができません。このすべての理由は何か手がかりはありますか?

これは私のテスト構成によるものだと思いますが、皆さんの考えをお聞きしたいと思います. 私は簡単なテストプロジェクトで遊んでいました。シンプルなフォーム認証ページと注文ページ (2 つのフィールドと「注文」を表示するリスト) がありました。注文ページは、パラメーターを取得するときに Request.Form[] を使用して、入力が GET 操作として入るのを防ぐように設定されていました。

Page_Init で ViewStateUserKey を設定し、EnableViewStateMac を明示的に true に設定します (デフォルトは true ですが)。

次に、2 つのフィールド (製品と数量) の値を設定する注文ページへのフォーム投稿を行う .HTM を作成しました。フォーム送信の一部としてビューステートをわざわざ作成しなかったことに注意してください。ブラウザの実際のページでソースを表示し、フォームフィールド以外をすべて切り取り、JavaScript を追加してフィールド値を設定し、form.submit() を実行しました。

テスト プロジェクトにログインし、.HTM を開きました。.HTM はフォームを正常に送信し、注文ページを更新すると、偽の注文が表示されました。

ViewStateUserKey がこれを防止しなかったのはなぜですか? まさにそのタイプの攻撃をブロックすることになっていませんか？この例では、ビューステートを改ざんしませんでした。通常のフォームの投稿を行うページを作成しただけなので、ViewStateUserKey は、ViewStateの改ざんから保護するためだけに存在します (これはまったく価値がないと思います。または、両方のページが生きているため、これは機能しています)。同じ物理マシン上で？