SQLインジェクションに関しては、stringパラメーターをパラメーター化する必要性を完全に理解しています。それは本の中で最も古いトリックの1つです。しかし、いつパラメーター化しないことが正当化できるのSqlCommandでしょうか？パラメータ化しないで「安全」と見なされるデータ型はありますか？

たとえば、私はSQLの専門家の近くにいるとは考えていませんが、SQLインジェクションに対して脆弱で、a boolまたはan を受け入れ、それをintクエリに直接連結する可能性があるとは考えられません。

私の仮定は正しいですか、それとも私のプログラムに大きなセキュリティの脆弱性を残す可能性がありますか？

明確にするために、この質問にはタグが付けられています c＃これは強く型付けされた言語です。私が言うとき、「パラメータを、」のようなものだと思います public int Query(int id)。

技術的には安全だと思いますが、侵入するのはひどい習慣です。このようなクエリを本当に作成しますか？

var sqlCommand = new SqlCommand("SELECT * FROM People WHERE IsAlive = " + isAlive + 
" AND FirstName = @firstName");

sqlCommand.Parameters.AddWithValue("firstName", "Rob");

また、型が整数から文字列に変わる状況で脆弱になります（名前に関係なく、文字が含まれている可能性がある従業員番号を考えてください）。

そのintためstring、EmployeeNumberのタイプをからに変更しましたが、SQLクエリを更新するのを忘れていました。おっとっと。

あなたは（Webサーバなど）を制御コンピュータ上で強く型付けされたプラットフォームを使用する場合は、あなただけでクエリーのコードインジェクションを防ぐことができbool、DateTimeまたはint（およびその他の数値）の値。懸念事項は、SQLサーバーにすべてのクエリの再コンパイルを強制し、どのクエリがどのような頻度で実行されているかに関する適切な統計情報を取得できないことによって引き起こされるパフォーマンスの問題です（キャッシュ管理に悪影響を及ぼします）。

しかし、「コンピュータ上で制御する」部分は重要です。それ以外の場合、ユーザーは、システムが使用する動作を変更して、これらの値から文字列を生成し、任意のテキストを含めることができるためです。

長期的に考えるのも好きです。今日の古くて強く型付けされたコードベースが自動翻訳を介して新しいホットネスの動的言語に移植され、突然型チェックが失われたが、動的コードに対する適切な単体テストがまだない場合に何が起こるか？

実際、これらの値にクエリパラメータを使用しない理由はありません。これについては、これが正しい方法です。値が実際に定数の場合は、SQL文字列に値をハードコードしますが、それ以外の場合は、なぜパラメーターを使用しないのですか？難しいことではありません。

結局のところ、これ自体をバグとは呼びませんが、匂いと呼びます。それ自体は、バグだけでは不十分ですが、バグが近くにあるか、最終的にはバグになるという強い兆候です。良いコードは臭いを残すことを避け、どんな良い静的分析ツールもこれにフラグを立てます。

残念ながら、これは真に勝てる種類の議論ではないことを付け加えておきます。「正しい」だけでは不十分で、同僚のつま先を踏んでこの問題を自分で解決しても、チームのダイナミクスが向上することはありません。それは最終的にそれが助けるよりももっと傷つく可能性があります。この場合のより良いアプローチは、静的分析ツールの使用を促進することです。これにより、既存のコードを対象にして、戻って修正する取り組みに正当性と信頼性がもたらされます。

場合によっては、文字列値以外のパラメータ化されていない（連結された）変数を使用してSQLインジェクション攻撃を実行することが可能です-Jonによるこの記事を参照してください：http : //codeblog.jonskeet.uk/2014/08/08/the-bobbytables -culture /。

ToString呼び出されたときに、一部のカスタムカルチャープロバイダーは、文字列以外のパラメーターをそのSQLをクエリに注入する文字列表現に変換できるということです。

これは非文字列型であっても安全ではありません。常にパラメーターを使用します。限目。

次のコード例を検討してください。

var utcNow = DateTime.UtcNow;
var sqlCommand = new SqlCommand("SELECT * FROM People WHERE created_on <= '" + utcNow + "'");

一見コードは安全に見えますが、Windowsの地域設定でいくつかの変更を行い、短い日付形式でインジェクションを追加すると、すべてが変更されます。

結果のコマンドテキストは次のようになります。

SELECT * FROM People WHERE created_on <= '26.09.2015' OR '1'<>' 21:21:43'

intタイプについても同じことができます。ユーザーはカスタムの負の符号を定義でき、SQLインジェクションに簡単に変更できます。

現在のカルチャの代わりにインバリアントカルチャを使用する必要があると主張する人もいますが、私はこのような文字列の連結を何度も見たことがあります+。

"SELECT * FROM Table1 WHERE Id =" + intVariable.ToString（）

セキュリティ
大丈夫です。
攻撃者は、型指定されたint変数に何も注入できません。

パフォーマンスが
良くない。

パラメータを使用する方が良いので、クエリは一度コンパイルされ、次回の使用のためにキャッシュされます。次回、異なるパラメーター値を使用した場合でも、クエリはキャッシュされ、データベースサーバーでコンパイルする必要はありません。

コーディングスタイル
悪い習慣。

• パラメータが読みやすくなりました
• 多分それはあなたがパラメータなしでクエリに慣れるようにして、多分あなたは一度ミスをしてこのように文字列値を使用し、そしてあなたはおそらくあなたのデータに別れを告げるべきです。悪癖！

"SELECT * FROM Product WHERE Id =" + TextBox1.Text

それはあなたの質問ではありませんが、将来の読者のために役立つかもしれませんが：

セキュリティ
災害！フィールドが整数の
場合でもId、クエリはSQLインジェクションの影響を受ける可能性があります。アプリケーション"SELECT * FROM Table1 WHERE Id=" + TextBox1.Textにクエリがあるとします。攻撃者がテキストボックスに挿入する1; DELETE Table1と、クエリは次のようになります。

"SELECT * FROM Table1 WHERE Id=1; DELETE Table1"

ここでパラメーター化されたクエリを使用しない場合は、型指定された値を使用する必要があります。

string.Format("SELECT * FROM Table1 WHERE Id={0}", int.Parse(TextBox1.Text))

あなたの質問

私の質問は、同僚が整数値を連結した一連のクエリを作成したために発生し、それらすべてを調べて修正するのは私の時間の無駄ではないかと思っていました。

これらのコードの変更は時間の無駄ではないと思います。確かに着替えがオススメです！

同僚がint変数を使用している場合、セキュリティリスクはありませんが、これらのコードを変更しても時間の無駄ではなく、実際にこれらのコードを変更することをお勧めします。これにより、コードが読みやすくなり、保守が容易になり、実行が速くなります。

実際には2つの質問があります。そして、タイトルからの質問は、その後のコメントでOPによって表明された懸念とはほとんど関係がありません。

OPにとって重要なのは特定のケースであることは理解していますが、Googleからの読者にとっては、より一般的な質問に答えることが重要です。私が連結しているすべての文字は安全ですか？」なので、この後者に集中したいと思います。そして答えは

間違いなくNO。

説明はほとんどの読者が望むほど直接的ではありませんが、最善を尽くします。

私はしばらくの間この問題について考えていましたが、その結果（PHP環境に基づいていますが）記事にまとめて、すべてをまとめようとしました。SQLインジェクションからの保護の問題は、文字列のエスケープ、型のキャストなど、関連しているがより狭いトピックに対してはしばしば見逃されていることに気づきました。一部の対策は、単独で使用しても安全と見なすことができますが、従うべきシステムや単純なルールはありません。そのため、開発者の注意と経験に過度の負担がかかり、非常に滑りやすくなっています。

SQLインジェクションの問題は、いくつかの特定の構文問題の問題に単純化することはできません。かつて考えられていた平均的な開発者よりも幅が広いです。それは方法論的な問題でもあります。「どの特定のフォーマットを適用する必要があるか」だけでなく、「どのように行う必要があるか」も同様です。

（この観点から、他の回答で引用されたJon Skeetの記事は、特定の構文の問題に集中していて問題全体に対処できずに、いくつかのエッジケースで再び問題を引き起こしているため、良いというよりはむしろ悪いことをしています。）

保護の問題全体ではなく、一連の異なる構文問題として対処しようとすると、多くの問題に直面します。

• 可能なフォーマットの選択肢のリストは非常に膨大です。簡単に見落とす可能性があることを意味します。または、それらを混同します（たとえば、識別子に文字列エスケープを使用します）。
• 連結とは、すべての保護手段をプログラムではなくプログラマが実行する必要があることを意味します。この問題だけで、いくつかの結果が生じます。
  • このようなフォーマットは手動です。手動は非常にエラーが発生しやすいことを意味します。申請を忘れる可能性があります。
  • さらに、フォーマット手順をいくつかの集中化された関数に移動し、さらに混乱させ、データベースに送らないデータを損なう誘惑があります。
• 複数の開発者が関与する場合、問題は10倍になります。
• 連結を使用すると、潜在的に危険なクエリを一目で見分けることはできません。それらはすべて潜在的に危険です！

その混乱とは異なり、準備されたステートメントは確かに聖杯です。

• それは従うのが簡単な1つの単純なルールの形で表すことができます。
• それは本質的に切り離すことのできない手段であり、開発者が干渉することはできず、喜んでまたは思わずにプロセスを台無しにすることを意味します。
• インジェクションからの保護は、実際には準備されたステートメントの副次的な効果にすぎません。その真の目的は、構文的に正しいステートメントを生成することです。そして、構文的に正しいステートメントは100％インジェクションの証拠です。しかし、注入の可能性があっても、構文を正しくする必要があります。
• ずっと使用すると、開発者の経験に関係なくアプリケーションを保護します。たとえば、2次注入と呼ばれるものがあります。そして、「保護するために、ユーザーが提供するすべての入力をエスケープする」という非常に強力な妄想 。これらを組み合わせると、開発者が自由に判断し、何を保護する必要があり、何をしないかを決定する場合、それらは注入につながります。

（さらに考えると、配列などの複雑なデータ構造と、SQLキーワードや識別子でさえ追加する必要がある場合があるため、現在のプレースホルダーのセットは実際のニーズに十分ではなく、拡張する必要があることを発見しました。動的にもクエリを実行しますが、開発者はそのような場合に準備ができておらず、文字列の連結に強制的にフォールバックしますが、それは別の問題です）。

興味深いことに、この質問の論争は、スタックオーバーフローの非常に物議を醸している性質によって引き起こされています。このサイトのアイデアは、直接尋ねるユーザーからの特定の質問を利用して、検索から来たユーザーに適した汎用回答のデータベースを作成するという目標を達成することです。アイデア自体は悪くありませんが、次のような状況では失敗します。ユーザーが非常に狭い質問をするとき、特に同僚との論争で議論を得るとき（またはコードをリファクタリングする価値があるかどうかを決定するとき）。経験豊富な参加者のほとんどが回答を書き込もうとしていますが、、使命て全体的にスタックオーバーフローを念頭に置き、OPだけでなく、できるだけ多くの読者に回答を提供します。

セキュリティやタイプセーフの考慮事項だけを考えてみましょう。

パラメータ化されたクエリを使用する理由は、データベースレベルでパフォーマンスを向上させるためです。データベースの観点からは、パラメーター化されたクエリはSQLバッファー内の1つのクエリです（Oracleの用語を使用するには、内部的にはすべてのデータベースに同様の概念があると思います）。したがって、データベースは一定量のクエリをメモリに保持し、準備して実行する準備ができています。これらのクエリは解析する必要がなく、より高速になります。頻繁に実行されるクエリは通常バッファ内にあり、使用されるたびに解析する必要はありません。

なし

誰かがパラメータ化されたクエリを使用していません。この場合、バッファはほぼ同一のクエリのストリームによって継続的にフラッシュされ、それぞれがデータベースエンジンによって解析および実行される必要があり、頻繁に実行されるクエリでも何度も再解析されるため、パフォーマンスはオールラウンドに低下します。日。私はデータベースを生計用に調整しましたが、これは簡単に実を結ぶ最大の情報源の1つです。

今

質問に答えるために、クエリに少数の個別の数値がある場合、おそらく問題は発生せず、実際にパフォーマンスが無限に向上する可能性があります。ただし、値が数百にもなる可能性があり、クエリが頻繁に呼び出される場合は、システムのパフォーマンスに影響を与えるため、実行しないでください。

はい、SQLバッファーを増やすことはできますが、最終的には常に、インデックスやデータのキャッシュなど、他のより重要なメモリの使用が犠牲になります。道徳的に、パラメーター化されたクエリをかなり忠実に使用して、データベースを最適化し、重要なもののためにより多くのサーバーメモリを使用することができます...

Maciek回答に情報を追加するには：

リフレクションによってアセンブリのmain関数を呼び出すことにより、.NETサードパーティアプリのカルチャ情報を簡単に変更できます。

using System;
using System.Globalization;
using System.Reflection;
using System.Threading;

namespace ConsoleApplication2
{
  class Program
  {
    static void Main(string[] args)
    {
      Assembly asm = Assembly.LoadFile(@"C:\BobbysApp.exe");
      MethodInfo mi = asm.GetType("Test").GetMethod("Main");
      mi.Invoke(null, null);
      Console.ReadLine();
    }

    static Program()
    {
      InstallBobbyTablesCulture();
    }

    static void InstallBobbyTablesCulture()
    {
      CultureInfo bobby = (CultureInfo)CultureInfo.InvariantCulture.Clone();
      bobby.DateTimeFormat.ShortDatePattern = @"yyyy-MM-dd'' OR ' '=''";
      bobby.DateTimeFormat.LongTimePattern = "";
      bobby.NumberFormat.NegativeSign = "1 OR 1=1 OR 1=";
      Thread.CurrentThread.CurrentCulture = bobby;
    }
  }
}

これは、BobbysAppのMain関数がパブリックである場合にのみ機能します。Mainがパブリックではない場合、呼び出す他のパブリック関数がある可能性があります。

私の意見では、使用するパラメーターに文字列が含まれないことを保証できる場合、それは安全ですが、どのような場合でもそれは行いません。また、連結を実行しているため、パフォーマンスがわずかに低下します。私があなたに尋ねる質問は、なぜパラメータを使用したくないのですか？

それは問題ありませんが、決して安全ではありません。セキュリティは常に入力に依存します。たとえば、入力オブジェクトがTextBoxの場合、テキストボックスは文字列を受け入れることができるため、攻撃者はトリッキーなことを行うことができ、何らかの検証/変換を行う必要があります。ユーザーの誤入力を防ぐことができます。しかし問題は、安全ではないということです。それと同じくらい簡単です。

いいえ、SQLインジェクション攻撃をその方法で受けることはできません。私はトルコ語で古い記事を書いています。PHPとMySQLの記事の例ですが、概念はC＃とSQL Serverで同じように機能します。

基本的には次のように攻撃します。整数のID値に従って情報を表示するページがあるとしましょう。以下のように、これを値でパラメーター化しません。

http://localhost/sqlEnjeksiyon//instructors.aspx?id=24

さて、あなたはMySQLを使用していると思います。私は次のように攻撃します。

http://localhost/sqlEnjeksiyon//instructors.aspx?id=ASCII((SELECT%20DATABASE()))

ここで注入された値は文字列ではないことに注意してください。ASCII関数を使用してchar値をintに変更しています。"CAST（YourVarcharCol AS INT）"を使用して、SQL Serverで同じことを実行できます。

その後、データベースの名前を見つけるために、長さと部分文字列関数を使用します。

http://localhost/sqlEnjeksiyon//instructors.aspx?id=LEN((SELECT%20DATABASE()))

http://localhost/sqlEnjeksiyon//instructors.aspx?id=ASCII(SUBSTR(SELECT%20DATABASE(),1,1))

次に、データベース名を使用して、データベース内のテーブル名の取得を開始します。

http://localhost/sqlEnjeksiyon//instructors.aspx?id=ASCII(SUBSTR((SELECT table_name FROM INFORMATION_SCHEMA.TABLES LIMIT 1),1,1))

もちろん、クエリごとに1文字しか取得できないため、このプロセスを自動化する必要があります。しかし、簡単に自動化できます。私の記事はwatirの 1つの例を示しています。パラメータ化されたID値ではなく、1ページのみを使用します。私はあなたのデータベースのすべてのテーブル名を知ることができます。その後、私は重要なテーブルを探すことができます。時間はかかりますが、実行可能です。

ええと... 1つ確かなことは、SQLコマンド文字列と文字列（ユーザーが取得した文字列）を連結する場合、セキュリティには問題があるということです。where句がIntegerまたは任意の型を参照する場合は常に問題ではありません。注射が発生する可能性があります。

SQLインジェクションで重要なのは、ユーザーから値を取得するために使用された変数のデータ型です。

where句に整数があり、次のように仮定します。

1. ユーザー変数は文字列です。その後、OK（UNIONを使用して）を注入することは非常に簡単ではありませんが、「OR 1 = 1」を使用してバイパスすることは非常に簡単です-攻撃のように...

2. ユーザー変数が整数の場合。次に、システムのクラッシュや隠しバッファのオーバーフロー（最後の文字列）の異常なテストに合格することで、システムの強度を「テスト」できます...;）

クエリへのパラメーター、またはストアドプロシージャへのパラメーター（さらに優れた-imo）は100％脅威に対して安全ではありませんが、最小化するために最低限必要な手段（または必要に応じて基本的な手段）です。