web-dev-qa-db-ja.com

ODBC接続文字列の一部のユーザー入力を許可することにはどのような危険がありますか？

私は、ユーザーがデータベースにアクセスするためのホスト名、データベース名、ユーザー名、およびパスワードを入力できるようにするアプリケーションを開発しています。アプリケーションは、プレースホルダーを入力してODBC接続文字列を作成します。Cでは、次のように変換されます。

snprintf(connStr, sizeof(connStr),
         "DRIVER={%s};SERVER={%s};DATABASE={%s};UID={%s};PWD={%s}",
         myDriver, hostName, dbName, userName, passWord);

私が最初に考えたのは、「;」を削除する必要があるということです。すべてからのキャラクター。 （そして、パスワードにセミコロンを含めることはできないことをユーザーに指示します。）

この場合、私はある種の敵対的な入力に対して脆弱ですか？ （質問する前に、はい、入力が大きすぎるかどうかを確認します。connStrバッファーで十分であると想定できます。それか、マネージ文字列タイプで高級言語を使用します。）

databasesinjection
4
JCCyC

@Sigtranのポイントの1つを少し拡張するために、特別なデリミネーター文字でのフィルタリングは、もちろんインジェクション攻撃から保護する際の重要なコントロールですが、可能な限り制限的なホワイトリストを利用して、クリエイティブなエンコーディングの可能性から保護することもお勧めします。 ;などの文字を単に置き換えるのではなく、リストアプローチ。 'など。このような正規表現を使用できる可能性があります（もちろん、アルファ/数字/ダッシュのみで正当な機能を壊さない場合）：

/ [^ A-Za-z-_0-9]/g、 ""

3
TobyS

まあ、このコードが脆弱かどうかはわかりません。 ODBC接続文字列の形式についてはよくわかりません。

しかし、正直なところ、そのコードは私に悪臭を放ちます。特定の攻撃についてはわかりませんが、潜在的なセキュリティリスクのようなにおいがします。それは起こるのを待っている注射の脆弱性かもしれないようににおいがします。

ODBC文字列を処理するときにデータベースドライバが解釈する可能性のあるすべてのメタ文字の完全なリストを知っていることをどの程度確信していますか？（バックスラッシュをエスケープとして扱いますか？ユーザー定義パラメータの1つがクローズカーリーブレース、いくつかのもの、および別のオープンカーリーブレースが含まれていますか？1つのパラメーターにオープンカーリーブレースが含まれているがクローズが含まれておらず、後のパラメーターにクローズカーリーブレースが含まれている場合はどうなりますか？）接続文字列を解析するときにデータベースドライバが使用する可能性のある文字エンコーディング？使用するデータベースの将来のバージョンや、将来切り替える可能性のある他のデータベースでは、これが変更されないことをどの程度確信していますか？これらの質問に対する答えを私が知っているとは確信できません。多分あなたは私よりも知っているでしょう。

私なら、これらのリスクにさらされることはありません。警戒します。これらのリスクを取る必要はないようです。代わりに、問題ないように見える文字のホワイトリストを作成し、それらの文字列をすべて、ホワイトリスト内の文字のみを使用するように制限することをお勧めします。多分これは不必要な注意ですが、それは私がすることです。

2
D.W.