2

私は答えを知っているはずなので、少し恥ずかしそうにこの質問をします。誰かが親切で、次のコードでインジェクションが発生する可能性があるかどうか、およびどのように発生するかを説明できますか?

<cfquery>
    select * from tableName
    where fieldName = '#value#'
</cfquery>

「通常の」ユーザー入力を処理するためのベスト プラクティスや入力検証ではなく、インジェクションの試みやその他の悪意のある入力に特に興味があります。CFQueryParam の使用を強く推奨している人を見かけますが、その要点が理解できていないと思います。ユーザー入力がデータベース スキーマとの整合性について検証されている場合 (たとえば、数値データベース フィールドの入力は数値でなければならないなど)、CFQueryParam を使用することで得られるものは他にありますか? それは何<cfqueryparam CFSQLType = "CF_SQL_VARCHAR">を'#value#'しませんか？

4

3 に答える 3

9

アップデート：

これはあなたの質問の一部に答えますが、「CF が単一引用符をエスケープして保護を自動的に追加するのに、なぜ cfqueryparam を使用するのですか?」という質問に直接対処するという点で、 Peter の回答の方が優れています。回答: 要するに、後者が常に機能するとは限らないためです。変数をバインドします。

ドキュメントには「一重引用符で文字列変数をエスケープする」と書かれていますが、評価された変数を一重引用符で囲むと、CFはすでに「魔法のように」CFクエリタグでこれを行っていませんか?

はい、ほとんどのバージョンでは、cfqueryparam を使用しない場合の保護手段として、単一引用符が自動的にエスケープされます。ただし、Scott が前述したように、cfqueryparam (バインド変数) を使用することをお勧めします。これは、パラメーターがsql コマンドとして実行されないようにするためです。ピーターの答えが示すように、自動エスケープが機能しない場合でも、バインド変数は機能します。

つまり、SQL インジェクション保護は、実際にはバインド変数を使用することの副作用にすぎません。バインド変数を使用する主な理由はパフォーマンスです。変数をバインドすると、#parameters# が変更されるたびに新しいプランを作成するのではなく、データベースがクエリ プランを再利用するようになります。これにより、コンパイル時間が短縮され、パフォーマンスが向上します。

Cfqueryparam には他にも多くの利点があります。

  • データ型チェック (長さ、値、型など) を提供します
  • 「リスト」とnull値の処理を簡素化する属性を提供します
  • SQL がデータベースに送信される前にデータ型チェックを実行し、無駄なデータベース呼び出しを防ぎます。

文字列列には実際には適用されませんが、IMO を使用するもう 1 つの大きな理由は精度です。引用符で囲まれた文字列をデータベースに渡す場合、暗黙的な変換に依存しています。基本的に、比較を最適に実行する方法をデータベースに任せているため、結果が常に期待どおりになるとは限りません。(日付文字列が代表的な例です)。データベースがどのように SQL を実行するかによって、結果が不正確になったり、クエリが遅くなったりする可能性があります。cfqueryparam を使用すると、あいまいさがなくなり、これらの問題が回避されます。

于 2013-09-13T19:30:14.580 に答える