詳細情報:
B2C Commerce でのデータの検証
ユーザー入力の検証は、アプリケーションセキュリティの基礎です。データの検証によって、データがアプリケーションで予想されている種類のものであることが確認されます。B2C Commerce では通常、無効なリクエストは完全に拒否され、ユーザーにエラーが返されます。データの検証を行う場所を選択しますが、ここではクライアント側とサーバー側の検証に重点を置きます。
-
通常クライアント側の検証は、スクリプティング言語によって実装され、データがサーバーに送信される前に、クライアントマシンでチェックされます。Salesforce B2C Commerce では、ユーザーのブラウザーで実行されてフォームデータを検証する JavaScript コードを作成します。ただし、クライアント側の検証は、セキュリティ管理としては信頼できません。
-
サーバー側の検証を実装するには、ビジネスフローに追加のステップを記述します。このステップは効果的なセキュリティ管理です。通常デベロッパーは、B2C Commerce API といくつかの基本的なサニティチェックを使用して、B2C Commerce スクリプトでサーバー側の検証を実行します、
クライアント側の検証を使用する基本的なデータのサニティチェックは、ストアフロントユーザーにただちにフィードバックを表示できます。一方、堅牢なサーバー側の検証は、悪意をもつリクエストを停止できます。
リクエストの送信後に、データを再度検証します。データが無効な場合は、B2C Commerce は処理を中止し、エラーメッセージを介してユーザーに通知します。その結果、クライアント側の検証では、誤って入力されたデータを正規のユーザーに報告し、サーバー側の検証では、悪意のあるユーザーがサーバーに直接リクエストを送信するのを阻止します。
インジェクション攻撃に対する保護
適切な検証によって、インジェクション攻撃から保護することができます。出力のエンコードとともに使用すると、インジェクション攻撃に対してさらに堅牢な防御が提供されます。以下に注意事項を示します。
-
クライアント側の検証における内部の機密データの公開:
データを検証する際には、クライアント側のチェックで内部ロジックをあまり使用しないようにします。これによって、クライアントのチェックで使用される、予想される値や有効なデータの候補のリストが公開される恐れがあります。貴重なデータが、脆弱性を探している悪意をもつ攻撃者を含むすべてのクライアントにさらされてしまいます。
-
セキュリティが万全であるという錯覚につながる、不正確な検証:
セキュリティでは、検証にあまり頼らないようにします。検証ステップは、複数の段階によるセキュリティチェックを推進する、より大規模な奥の深いセキュリティ管理の一部にすぎません。これは一般的な問題です。特に、徹底的に検証することの難しい正規表現で問題となります。
次の方法でユーザー入力を検証します。
| ユーザーの検証方法 | 説明 |
|---|---|
| 許可リストへの追加 | 許可リストへの追加はもっとも厳格な検証戦略です。許容可能な入力を定義し、これ以外はすべて拒否します。たとえば、入力が曜日である場合は、予想される値は 7 つのみになります。 また、入力形式を許可リストに追加することもできます。たとえば、日付とソーシャルセキュリティナンバーには特定の形式があります。 |
| ブロックリストへの追加 | 許可リストに追加する入力の形式が多すぎる場合は、ブロックリストが効果的なオプションです。ブロックリストを使用して、許容できないことがわかっている特定のタイプの入力をブロックします。潜在的に害となるすべての入力を特定することはできませんが、ブロックリストを実装する場合には、以下の点を考慮してください。
|
