ソースを直接閲覧することもできます。不明確な部分がある場合には、たびたび役立ちます。クラスをクリックします。クラスの実装があります。それらの名前をクリックします。次のデータベースエンコーダーがあります。ServerPostgreSQLは、近日中に入手できます。目的のデータベースエンコーダーが見つからない場合は、お知らせください。エンコーダーが開発されている、次の各データベースのエスケープ処理の詳細を参考にしてください。エスケープ文字情報に基づいています。データベースコーデックは、とても簡単に使用できます。用例は、次のようになります。向けられてコード内で生成される既存の動的クエリがあったとします。}次に示すように、最初の行を書き直します。インジェクションに対して安全になります。作成することもできます。渡されるユーザー指定の各パラメーターをラップすることだけです。使用して、自動的な文字置換をオフにします。変数のプレフィックスのように扱われることになり、攻撃者による機密データの取得に利用される可能性があります。キーワードにより、テキストの検索が可能になります。文字はゼロ個以上の任意の文字を検索します。句の条件内ではエスケープする必要があります。配置して、その文字列全体をエスケープする方法も使用できます。文字が含まれていないことに注意する必要があります。置き換える必要があります。ないと、その文字の位置で早まってエスケープ処理が終了してしまい、脆弱性を招き入れる可能性があります。つのエスケープ処理モードをサポートしています。モードというモードです。モードは、以下のエンコードが行われます。元の英数文字以外の文字です。エスケープ文字情報に基づいています。インジェクション攻撃を防止する方法について説明した記事への適切なリンクが含まれています。特殊文字の情報に基づいています。ドライバーの情報に基づいています。ドライバー間の相違点に関する情報は、次の場所にあります。(これは、文字ごとのエスケープ処理と見なせます)。ステートメントに含めるようにする必要があります。ステートメントは、この事実を考慮に入れて、それに応じたデータの比較を行う必要があります。ステートメントは次のようになります。使用しているデータベースの特定の機能に置き換える必要があります)。進数値にして並べたものです)。ステートメントは次のようになるだけです。進数エンコードされたものです。インジェクションを可能にするような特殊文字は一切含まれなくなります。つを採用することに加え、ここに示す追加の対策すべてを採用して、多層防御を実現するようにお勧めします。追加の対策は、次のとおりです。インジェクション攻撃が成功したときの潜在的な被害を最小化するには、各データベースアカウントに割り当てる権限を最小限にする必要があります。管理者タイプのアクセス権は、アプリケーションのアカウントに割り当ててはいけません。便利なことは確かですが、とても危険です。アプリケーションアカウントにとって不要なアクセス権を削除しようとするのではなく、そもそも必要なのはどのアクセス権かを一から考えて決定していきます。読み取りアクセスのみが必要なアカウントには、アクセスする必要のあるテーブルへの読み取りアクセスのみを付与していることを確認します。テーブルの一部のみへのアクセスを必要とする場合は、そのデータ部分にアクセスを限定するビューを作成して、アカウントのアクセスを元のテーブルではなくビューに割り当てることを検討します。特別な場合を除いて、データベースアカウントに作成や削除のアクセス権は付与しません。アプリケーションアカウントに独自クエリの直接実行を許可せず、すべてにおいてストアドプロシージャを使用するポリシーを採用している場合は、アカウントのアクセス権を制限して必要なストアドプロシージャのみを実行できるようにします。データベースのテーブルへの直接的なアクセス権を付与してはいけません。インジェクションは、データベースのデータに限られた脅威ではありません。攻撃者は、パラメーターに指定されている正当な値を不正な値に変更するだけで、アプリケーション自体がこの不正な値にアクセスするのを待てばよいのです。したがって、アプリケーションに付与する権限を最小限に抑えることで、不正アクセスが試行される可能性が減ります。インジェクションを使用しようとしていない場合でも同じです。実行するオペレーティングシステムアカウントの権限も最小化する必要があります。実行してはいけません。アカウントで実行します。アカウントは、より適切に権限が制限されたものに変更してください。管理者アカウントの使用を避けるだけでは不十分です。ユーザーを使用できます。することでアプリケーション設計者は、アクセス制御の適切な詳細度を設定し、権限を可能な限り小さくできます。ユーザーは、必要とするアクセスのみを選択して、必要に応じて書き込みアクセスを選択します。どれも必要ありません。その一方、サインアップページでは、そのテーブルへの挿入権限が確実に必要になります。ユーザーを使用してデータベースに接続している場合にのみ実施できます。ビューは、特定テーブルのフィールドまたはテーブルの結合に読み取りアクセスを制限することで、アクセスの詳細度をさらに緻密にできます。これには、追加のメリットもあります。(特殊な法的要件などにより)。設計者は、ビューを使用することで、この制限を補強できます。すべて取り消して、パスワードフィールドのハッシュを出力するビューを作成して、フィールド自体は出力しないようにします。盗み出すにとどまります。ユーザーは存在しないからです。クエリに渡される前に検出できます。詳細については、「入力認証に関するチートシート」を参照してください。次の点に注意が必要です。クエリに挿入すると、安全でなくなることがあります。攻略する方法について説明しています。パラメーター化されたプリペアドステートメントとストアドプロシージャに関する、さまざまな言語での例が多数あります。OWASPDisclaimers。