ユーザー入力
コンテンツを「入力をサニタイズする」(または事前エンコードまたは事前エスケープ) という考えはひどいものです。本当に必要なときに実際には保護されず、あらゆる種類の設計上の頭痛の種になります. PHPでさえ、最終的にテクニックを捨てました。
リスクを排除するために、適切な API を介してデータを正しく処理することを常にお勧めします。たとえば、SQL インジェクションは、準備されたステートメントまたはコンテンツのプレースホルダーを含むステートメントを使用して完全に排除されます。この手法は非常に長い間使用されてきました (私が Java と SQL を使用している限り)。
Grails (GORM) は、単一のプロパティの設定、新しいオブジェクトの作成と保存、プロパティの設定など、オブジェクトを介して保存されたコンテンツのエンコードを自動的に処理しますobj.properties = params
。
GORM を使用している限り、SQL インジェクションのリスクはありません。
コンテンツ ストレージ
また、エンコーディングは特定の表示タイプ (HTML など) に対してのみ正しいため、既にエンコードされた情報をデータベースに保存することは一般的に正しくないと考えられています。代わりに JSON を使用してレンダリングしたい場合は、HTML エンコーディングが正しくありません。XML も少し異なり、プレーン テキストを好む場合もあります。
代わりに、通常は未加工 (UTF8 または類似の) データをデータベースに保存し、表示用にレンダリングするときに正しい表示タイプに変換する必要があります。レンダリング時に変換されることに注意してください。これは、クライアントに送信するたびに変換されるとは限りません。Grails 2.1 に追加された新しいキャッシュ プラグインなど、さまざまなキャッシュ技術を使用して、これが頻繁に発生しないようにすることができます。
ただし、次のようにgrails.views.default.codec
オプションを使用して、デフォルトのビュー コーデックを HTML に設定することを強くお勧めします。
grails.views.default.codec = 'html'
これは GSP のみに影響し、ドル記号構文 ( ${foo}
) を使用してエコーされたコンテンツのみに影響します。これにより、タグ (推奨される方法) または<%= %>
1 回限りの状況の構文を使用して、この動作を柔軟にオーバーライドできます。ただし、一般的な XSS 攻撃を防ぐための適切なキャッチを提供する必要があります。
パフォーマンスに関する考慮事項
最後に 1 つ: コンテンツを HTML としてエンコードすることがパフォーマンスの問題であるという懸念は、時期尚早の最適化と見なされます。パフォーマンスのボトルネックは、コンテンツのエンコーディングではなく、別の場所にある可能性が非常に高くなります。適切な設計を使用して最初にアプリケーションを構築し、実行中のアプリケーションのベンチマークと分析を行った後で最適化します。