CSRF からユーザーを保護する方法で Opportunity オブジェクトに追加されたカスタム ボタンから Apex コードを実行する手法を探しています。
現在使用されているアプローチは、カスタム ボタンまたはカスタム コントローラーを使用した Visualforce ページへのリンクという質問から来ています。基本的に:
- コンテンツ ソースが「Visualforce ページ」に設定された商談カスタム ボタンがあります。
- このボタンのコンテンツは、標準コントローラの Opportunity を使用する Visualforce ページに設定され、拡張 Apex クラスが入力され、そのクラスのメソッドのアクションが含まれます。
- アクション メソッドは、商談 ID を持つパラメータの追加を含め、PageReference を別のカスタム Visualforce ページに返します。
- この 2 番目のカスタム Visualforce ページは、Web サービス コールアウトの作成や DML 操作の実行など、実際の作業の大部分を行ってから、ユーザーを商談にリダイレクトします。
このアプローチの問題は、2 番目のカスタム Visualforce ページが HTTP GET を介して取得され、クエリ文字列からパラメーターを取得し、CSRF 保護なしで DML 操作の更新/挿入を実行することです。これは、Force.com Security Source Code Scanner によって検出されています。
この apex コードは管理パッケージと未管理パッケージの両方としてデプロイされるため、PageReference を使用してターゲットの Visualforce ページにリダイレクトする追加の作業が必要になることを付け加えておきます。これにより、必要に応じて名前空間プレフィックスが追加されます。
CSRF の問題を回避するにはどうすればよいですか?
プロセスを開始するために押す必要があるボタンを使用して、2 番目の visualforce ページにフォームを追加したくありません (したがって、ポストバックで ViewStateCSRF 保護を取得します)。ユーザーの観点からは、ユーザーは既にボタンを押して操作を実行しています。
以前開発者フォース フォーラムでこの質問をしたことがありますが、解決策が思いつきませんでした -クロスサイト リクエスト フォージェリ (CSRF/XSRF) 安全なカスタム ボタン アクション
おそらく、2 番目のビジュアル フォース ページのコードをコントローラーから移動し、代わりにスタンド コントローラーの拡張機能を使用する必要がありますか?
Apex Web サービスへの Javascript コールバックに切り替えることはできますが ( 「カスタム ボタンから apex メソッドを呼び出す」および「カスタム ボタンから APEX メソッドを呼び出す方法」で提案されているように)、少し面倒なようで、切り替えるべきかどうかわかりません。 Web サービスで別の範囲のセキュリティ問題が発生するだけです。