詳細情報:
Business Manager での CSRF に対する保護
CSRF 攻撃は、悪意をもつ攻撃者が使用する手法で、被害者が Business Manager に対して保護されたリクエストを行うように強制します。このようなリクエストは eコマースビジネスに大きな混乱を引き起こす可能性があります。このトピックは、B2C Commerce に該当します。
CSRF 攻撃
すべての Business Manager ページは、CSRF 攻撃に対して自動的に保護されます。Business Manager ページが Commerce Cloud サーバーにリクエストを行うたびに、ページによって特別な CSRF トークンが自動的にリクエストに挿入されます。サーバーがリクエストを受信すると、リクエストが保護された (害となる可能性のある) アクションを実行しようとしているかどうかが判定されます。リクエストがこのようなアクションを実行しようとすると、挿入されたトークンがサーバーによって自動的に検証されます。トークンが検証されると、サーバーは保護されたアクションを完了し、予想されている応答を返します。検証されなかった場合は、SIG では 17.4 および PIG では 17.5 から、サーバーによって警告がログされ、場合によってはエラーページが返されます。
エラーページが表示された場合は、指示されたステップにしたがって、エラーが発生したページを再試行してください。再試行が成功した場合は、エラーは無視できます。しかし再試行が失敗してエラーが再度表示された場合は、CSRF 攻撃が行われている可能性が高く、また、同時にこの攻撃から保護されています。この場合は、セキュリティ部門に連絡してください。
CSRF に関連するエラーやログエントリがあっても、攻撃が実際に行われているとは限りません。Salesforce 管理者は、CSRF ログエントリをトラブルシューティングして、実際の原因を調査し、適切な対応を決定できます。Business Manager のカスタム拡張機能を使用している場合は、CSRF トークンを適切に挿入するためにデベロッパーが拡張機能のカスタムコードを変更する必要があります。その他の場合は、特定のパイプラインやユーザーエージェントを許可リストに追加できます。
CSRF ログエントリのトラブルシューティング
CSRF ログエントリは次の形式を使用しています。
Pipeline CSRF Token not valid[reason]: pipeline: (token|no_token)::Referer/Origin: URL::UserAgent: agent
各パラメーターの説明:
-
reason は検証が失敗した理由を説明する文字列です。以下のような理由が考えられます。
- Origin validation ― リクエストが Business Manager ページではない Web サイトから送信された。
- No token ― リクエストに CSRF トークンが挿入されていない。
- CSRF token validation ― トークンがこのユーザーに対して正しくない、または、タイムアウトしている (タイムアウトは 1 時間)。
- Exception occurred ― 処理中に予想外の事態が発生した (このエラーはキャッチオールです)。
- pipeline はリクエスト内のパイプラインの名前です。
- token はサーバーが受信したトークンです (リクエストでトークンが送信された場合)。
- no_token は、リクエストにトークンが見つからなかったことを示す文字列です: "CSRF Token doesn't exist." (CSRF トークンがありません。)
- URL はリクエストの起点を示す URL です。
- agent は、ユーザーエージェントの最初の 32 文字です。
ログファイルでこれらのエントリを見つけるには、「Pipeline CSRF Token」という文字列を検索します。
Log Center を参照してください。
ログエントリは、サーバーが有効な CSRF トークンを予想する際に、トークンが見つからない、またはトークンが無効な場合に作成されます。次の表に示すように、この動作はさまざまな状況で発生します。
| 状況 | 対応策 |
|---|---|
| Business Manager ユーザーが攻撃を受けている場合。ユーザーが別のサイトを訪問した後にエラーページが表示された場合は、この別のサイトが Business Manager に対して保護されたリクエストを試み、フレームワークによって攻撃に対する適切な保護が行われています。 | Business Manager ユーザーは、この攻撃をセキュリティ部門に報告してください。 |
Business Manager ユーザーは攻撃を受けておらず、ログエントリにトークンが見つからなかったことが示されている場合。Business Manager のカスタム拡張機能でトークンの自動挿入が適切に行われなかった可能性があります。 Commerce Cloud では、このような事態が発生する可能性がある場所として、次のような状況を特定しています。
|
デベロッパーは、 デベロッパーは次のように変更できます: |
| Business Manager ユーザーは攻撃を受けておらず、ログエントリにトークンが無効であることが示されている場合。トークンは 60 分後に無効になるため、ユーザーが古いブラウザーのタブに戻ってリクエストを行うと、検証に失敗することがあります。また、Business Manager の他のページにナビゲートしなくてもページ内に表示されるデータが更新されるいくつかのページでも、このような状態が発生することがあります。 | Business Manager ユーザーがエラーの発生したページを更新できる。 |
| Business Manager ユーザーは攻撃を受けていないが、Business Manager からサーバーにリクエストを行う代わりに、Eメール、ブックマーク、または別の Web サイトからユーザーがリクエストを行った場合。 | ユーザーが Eメール、ブックマーク、別の Web サイトからリクエストできるようにするには、目的のページへの安全なリダイレクトとして機能する新しい開始ノードを、パイプラインに作成することをお勧めします。この作業はデベロッパーが実行する必要があります。 デベロッパーがこの作業を完了したら、管理者はこのリダイレクトパイプライン - 開始ノード (redirect pipeline-start node) の組み合わせを許可リストに追加できます。これによって、すべてのユーザーに対し、この開始ノードの CSRF 検証が無効になります。 |
| Business Manager ユーザーは攻撃を受けていないが、リクエストを保護できないか、リクエストがまだ保護されていない場合。 | 管理者は CSRF 許可リストを使用して、パイプラインまたはパイプライン/開始ノードの組み合わせの検証を一時的に無効にできます。これは一般的に推奨されません。 |
| Business Manager インスタンスからのデータ収集、または自動テストのためのデータのインポートに、自動スクリプトが使用される場合。 | 管理者は CSRF 許可リストを使用して、スクリプトのユーザーエージェントを許可することができます。このアプローチを使用する場合は、ブラウザー以外のユーザーエージェント文字列を使用することを強く お勧めします。これによって、ユーザーエージェントが許可リストの値と完全に一致する場合、すべてのリクエストの検証ロジックが無効になります。 または、顧客が (すべての Business Manager ページに埋め込まれている) CSRF トークンの自動スクリプトの知識を提供して、スクリプトベースのリクエストでトークンを使用することができます。これによってブラウザーベースのナビゲーションの動作が模倣されます。これが推奨されるアプローチです。 |
