SQL識別子は結局どうすればよいか

今まで2回にわたって、SQL識別子のエスケープの問題を取り上げました。 間違いだらけのSQL識別子エスケープ SQL識別子エスケープのバグの事例 3回目となる本稿では、SQL識別子の取り扱いに関する問題を整理して､一般的な原則を導きたいと思います。 SQL文が動的に変化する場合のSQLインジェクション対策 「間違いだらけの…」で示したように、識別子エスケープが必要な局面でそれが洩れていると脆弱性の要因になることがありますが、それは外部から指定したデータにより、SQL文の構造が変化してしまい、アプリケーションの要件にないSQL呼び出しがなされてしまうからでした。 しかし、「間違いだらけ…」の後半で示したように、識別子のエスケープだけではセキュリティ問題を防ぐことはできず、情報漏洩を招いてしまいました。外部から任意のSQL識別子を指定できることが問題という結論でした。 上記のように、アプリケー

[kazuyadesse]

( ´ ▽ ` )ﾉ

[takc923]

SQL文を文字列連結せずにプレースホルダー使わない、ことが出来ない場合はここまで考えないといけない

[moondoldo]

SQL

[Itisango]

“SQLの識別子に使う文字は、英数字とアンダースコアに限定する”“外部からの値から識別子を生成する場合は、表名の配列などを使用することにより、外部由来の値を識別子に（ひいてはSQL文に）混ぜないこと”

[pullphone]

“文字列連結でSQL文を組み立てるな パラメータはプレースホルダで指定せよ” 結局コレに行き着くんだよなー

[kits]

「外部由来の値をSQL文に混ぜない」「SQL文の妥当性は、SQL文組み立ての箇所で担保されるべき」