[解決済み] パラメータを使用しないSQLインジェクションの回避

質問

私たちのコードでパラメータ化されたSQLクエリを使用することについて、職場で別の議論をしています。この議論には 2 つの側面があります。私と、SQL インジェクションを防止するために常にパラメータを使用する必要があると言う他の人たちと、その必要がないと考える他の人たちです。その代わりに、SQLインジェクションを避けるために、すべての文字列でシングル・アポストロフィをツー・アポストロフィに置き換えることを望んでいます。私たちのデータベースはすべてSql Server 2005または2008を実行しており、私たちのコードベースは.NETフレームワーク2.0で実行されています。

C# で簡単な例を挙げてみましょう。

これを使って欲しい。

string sql = "SELECT * FROM Users WHERE Name=@name";
SqlCommand getUser = new SqlCommand(sql, connection);
getUser.Parameters.AddWithValue("@name", userName);
//... blabla - do something here, this is safe

他の連中はこうしたいのに。

string sql = "SELECT * FROM Users WHERE Name=" + SafeDBString(name);
SqlCommand getUser = new SqlCommand(sql, connection);
//... blabla - are we safe now?

ここで、SafeDBString関数は以下のように定義されています。

string SafeDBString(string inputValue) 
{
    return "'" + inputValue.Replace("'", "''") + "'";
}

さて、クエリ内のすべての文字列値に対してSafeDBStringを使用している限り、安全であるはずです。そうでしょう？

SafeDBString関数を使用する理由は2つあります。1つ目は、石器時代から行われている方法であること、2つ目は、データベース上で実行される実際のクエリを見ることができるので、SQLステートメントのデバッグがより簡単になることです。

それでは。私の質問は、sql インジェクション攻撃を避けるために SafeDBString 関数を使用するだけで本当に十分なのかどうかということです。この安全策を破るコードの例を探しているのですが、そのような例は見当たりません。

これを破ることができる人はいますか？あなたならどうしますか?

EDITです。 今までの返信をまとめると

• Sql Server 2005 または 2008 で SafeDBString を回避する方法は、まだ誰も見つけていません。それは良いことだと思いますが?
• いくつかの返信で、パラメトリッククエリを使用するとパフォーマンスが向上することが指摘されました。その理由は、クエリプランを再利用できるからです。
• また、パラメトリッククエリを使用すると、より読みやすいコードになり、保守が容易になることにも同意します。
• さらに、さまざまなバージョンの SafeDBString、文字列から数値への変換、文字列から日付への変換を使用するよりも、常にパラメータを使用する方が簡単です。
• パラメータを使用すると、自動的な型変換が行われます。これは、日付や10進数を扱うときに特に便利です。
• そして最後に セキュリティを自分で行おうとしないでください JulianRが書いているように。データベースベンダーはセキュリティに多くの時間とお金を費やしています。私たちがそれ以上のことをできるわけがありませんし、彼らの仕事をしようとする理由もありません。

誰もSafeDBString関数の単純なセキュリティを破ることができなかった一方で、私は他の多くの良い議論を得ることができました。ありがとうございます。

どのように解決するのですか?

正解は

自分でセキュリティを行おうとしない . あなたがやろうとしていることに対して、信頼できる、業界標準のライブラリがあれば何でも使ってください、むしろ 試みる を使うようにしましょう。あなたがセキュリティについて行うどのような仮定も、正しくないかもしれません。自分のやり方が安全そうに見えても（よくても不安定に見えても）、何かを見落としている可能性があり、セキュリティに関してそのようなチャンスを本当に得たいですか？

パラメーターを使用する