SQL以外のデータベースを使用すると、「SQLインジェクション」から保護する必要がなくなりますか？

Question

これは明白な（またはそれほど明白ではない）質問のように思えるかもしれませんが、説明させてください。 GoogleのデータベーステクノロジーであるBigTableを使用して、Google App Engineサイトをコーディングしています。 App Engineコーダーは、GoogleがGQLと呼ばれる独自の限定されたクエリ言語を持っていることを知っています。その結果、Googleはデータを取得するためにバックエンドメソッドで生の文字列クエリを使用していないと想定しているため、アプリでSQL（またはGQL）インジェクションをチェックしないように誘惑されます。

さらに、CouchDB、MongoDB、その他のオブジェクトまたはドキュメント（別名NoSQL）データベースなどのDBテクノロジーのライブラリは、悪意のあるユーザーがデータベース操作コマンドを注入しているかどうかをチェックする必要をなくすようです。多くの場合、データベース内のオブジェクトを選択した言語のオブジェクトに直接マップするライブラリがあります。これを行うSQLライブラリも多数ありますが、何らかのレベルでパラメーターを組み合わせて文字列に対してクエリを実行すると想定しているため、これらのフレームワークでもSQLインジェクション保護を使用する必要があります。

近視眼ですか？または、次の優れたDBシステムが定着し、それらのシステムへのインジェクションが見られるようになるのは時間の問題ですか？

Answer 1

「インジェクション」ホールは、テキストコンテキストの不一致に関連しています。文字列の別のコンテキストにテキスト文字列を配置するたびに、変更されたコンテキストに合わせてエンコードを行う必要があります。文字列を盲目的に詰め込むのは誘惑的に簡単に思えますが、文字列処理の難しさは欺cept的です。

純粋にオブジェクトベースのインターフェースを備えたデータベースは、パラメーター化されたクエリがSQLにあるように、インジェクションの脆弱性の影響を受けません。攻撃者が自分の文字列を入力して、あなたが入力した文字列リテラルコンテキストから抜け出すことはできません。

しかし、GQLは特にこれらの1つではありません。これは文字列クエリ言語であり、信頼できないエスケープされていないマテリアルを＆quot; WHERE title = '％s'＆quot;のようなクエリに連結すると、 ％title 、完全なSQLを使用した場合と同様に脆弱です。 GQLの機能が制限されているため、アプリケーションを完全に侵害することを悪用することは難しくなりますが、一般的には不可能ではないことは確かです。 / p>

GQLには、パラメーターバインディングインターフェイスがあります。これを使って。文字列のハッキングの魅力に抵抗する。

Answer 2

GQLのようなSQLサブセットは明らかにそれと関係がありますが、CouchDBやVoldemortなどのような純粋な非SQLデータベースは＆amp; SQLインジェクションスタイルの攻撃を気にせずにデータを取得します。

ただし、データベースを壊すことはないかもしれませんが、アプリケーションを壊し、XSS（Webアプリの場合）などを許可する可能性があるため、コンテンツ検証を行うことを許しません。

Answer 3

ユーザー入力からのデータまたはユーザー入力によって操作されるデータは、コードの実行を制御するために使用されるため、サニタイズが必要です。コードがユーザー入力を使用して、入力を無害化せずにコマンドを実行するケースを見てきました。悪用されていませんでしたが、悪用された場合は恐ろしい攻撃ベクトルになっていたでしょう。

Answer 4

SQlインジェクションは、制御されていない入力が評価されるセキュリティ欠陥の一種のサブセットにすぎません。

技術的には、「注入」できます。とりわけJavaScript。