問題タブ [sql-injection]

議論のために、INSERT を持つ SQL クエリを含むローカル変数を作成する必要があるとしましょう。

この INSERT には、列の値も含まれます。

さて、私は明らかにインジェクション攻撃を懸念しており、@message の値によって @insert の値が悪意のあるものや、EXEC へのクエリとして不正な形式にならないようにしたいと考えています。

これは私の質問につながります: @message の ' 文字をエスケープするだけで十分ですか? @message に表示され、エスケープできる他の文字はありますか?

例：

(私が「する必要がある」と言うとき、これはクエリがストアド プロシージャにあり、このストアド プロシージャが INSERT 先のテーブルである @table を受け入れるためです。自分のアーキテクチャや、なぜテーブルがto INSERT into は、プロシージャ パラメータを介して「動的に」指定されます。テーブル名をプロシージャ パラメータとして受け取ったときに、INSERT 先のテーブルを指定するクエリを EXEC() する以外に別の方法がない限り、これについてコメントすることは控えてください。)

MySQL インジェクションが不可能であることを確認するために、文字列を実行するための最適な関数は何ですか?

また、正しく表示するには、途中で別の関数を実行する必要がありますか?

こちらもご覧ください

Sqlインジェクションを防ぐのにパラメータは本当に十分ですか?
C# Parameterized Query MySQL with inclause
一重引用符をエスケープし、ユーザー入力を一重引用符で囲むことにより、SQL インジェクションから保護できますか?

別の質問には、次のようなコメントがあります。

「データベースクエリに関しては、常に準備されたパラメーター化されたクエリを試して使用してください。mysqli および PDO ライブラリはこれをサポートしています。これは、mysql_real_escape_string などのエスケープ関数を使用するよりもはるかに安全です。」

ソース

だから、私が聞きたいのは、準備されたパラメーター化されたクエリがより安全なのはなぜですか?

このコードを使用して SqlCeResultSet で行を挿入すると、

SQL インジェクション攻撃を防ぎますか?

SubSonic を使用して Web プロジェクト用の DAL を作成する場合、SQL インジェクション攻撃の防止について心配する必要はありますか?

ですから、私は少し経験豊富なphp開発者であり、2007年から「ひどいことをしている」のです。ただし、アプリケーションのセキュリティ保護に関しては、まだ比較的問題があります。自分ができること、すべきことをすべて知っているわけではないという意味で。

私はPHPWebアプリケーションの保護を取り上げ、その過程で物事をテストする方法を読んでいます。データベースクエリ（主にmysqlの下）に関連する一般的なSOグループについていくつか質問があります。

データベースにデータを配置するアプリを作成する場合、mysql_real_escape_stringと入力データの一般的なチェック（is_numericなど）で十分ですか？SQLインジェクションとは異なる他のタイプの攻撃についてはどうでしょうか。

誰かがストアドプロシージャとプリペアドステートメントを、あなたがそれらを作成して呼び出すよりも少し多くの情報で説明できますか？それらがどのように機能するのか、舞台裏でどのような検証が行われているのかを知りたいです。

私はphp4にバインドされた環境で作業していますが、当面はphp5はオプションではありません。他の誰かが以前にこの立場にあったことがありますが、すべてのクールな子供たちがその甘い新しいmysqliインターフェイスを使用している間に、アプリケーションを保護するために何をしましたか？

アップグレードや可能な移行（php4からphp5への移行など）に耐えられるインフラストラクチャの作成に重点を置いて、人々が有利であると考えている一般的なグッドプラクティスは何ですか。

注：検索したところ、php-mysqlのセキュリティに影響を与えるこれに類似したものは見つかりませんでした。

PHP ではmysql_real_escape、addslashes. addslashesただし、 SQL インジェクションが発生する状況の例は見つかりませんでした。

誰でもいくつかの例を挙げることができますか?

私はあらゆる種類のPythonモジュールを試しましたが、エスケープしすぎるか、間違った方法でエスケープします。Pythonで引用符（ "、'）をエスケープするために見つけた最良の方法は何ですか？

ステートメントを考えると：

次のsqlite3_bind_text(および関連するsqlite3_bind_*関数) の使用は、SQL インジェクション攻撃を防ぐのに十分ですか?

コードでパラメーター化された SQL クエリを使用することについて、ここで別の議論を行っています。議論には 2 つの側面があります。SQL インジェクションから保護するために常にパラメーターを使用する必要があると言う私と他の何人かと、それが必要だとは思わない他の人たちです。代わりに、SQL インジェクションを回避するために、すべての文字列で単一のアポストロフィを 2 つのアポストロフィに置き換えたいと考えています。データベースはすべて Sql Server 2005 または 2008 を実行しており、コード ベースは .NET Framework 2.0 で実行しています。

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

これを使用してほしい：

他の人はこれをしたいのですが：

SafeDBString 関数は次のように定義されています。

ここで、クエリのすべての文字列値で SafeDBString を使用する限り、安全です。右？

SafeDBString 関数を使用する理由は 2 つあります。第一に、これは石器時代から行われてきた方法であり、第二に、データベースで実行される exact クエリが表示されるため、SQL ステートメントのデバッグが容易になります。

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

これを打破できる人はいますか？どのようにしますか？

編集： これまでの返信を要約するには：

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

そのため、SafeDBString 関数の単純なセキュリティを破ることはできませんでしたが、他にも多くの良い議論を得ました。ありがとう！