4

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

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

私は近視眼的ですか？それとも、次の優れたDBシステムが定着し、それらのシステムへの注入が行われるのは時間の問題ですか？

4

4 に答える 4

7

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

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

しかし、GQLは特にこれらの1つではありません。これは文字列クエリ言語であり、信頼できないエスケープされていないマテリアルをのようなクエリに連結すると、フルオン"WHERE title='%s'" % titleSQLの場合と同じように脆弱になります。GQLの機能が制限されているため、アプリケーションを完全に侵害するためにそれを悪用することはより困難ですが、一般的には確かに不可能ではありません。最も良い場合、アプリケーションはまだ間違っており、人々がアポストロフィを合法的に使用しようとすると倒れます。

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

于 2009-12-01T02:11:43.767 に答える
2

GQLのようなSQLサブセットは、明らかにそれ自体に関係していますが、CouchDB、Voldemortなどの純粋な非SQLデータベースは、SQLインジェクションスタイルの攻撃を気にせずにデータを配置および取得する必要があります。

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

于 2009-12-01T01:53:15.083 に答える
1

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

于 2009-12-01T01:58:30.593 に答える
1

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

技術的には、JavaScriptなどを「挿入」することができます。

于 2009-12-01T01:58:38.083 に答える