DocumentDB Sql Injection？

Question

私はいくつかのクライアント固有のクエリビルドをクライアントにオフロードしようとしています。私はそれがUPDATEまたはDELETEステートメントを持っていないので、私はdocumentdbのSQLインジェクションの危険にあるとは思わないが、私は肯定的ではない。また、今後追加されるかどうかはわかりません。

これは私の問題の例です。

IceCreamAppは、名前が「choco」のようなすべての味を見つけたいと考えています。味の文書がthis-

{ 
    "name": "Chocolate", 
    "price": 1.50 
} 

のように見えるAPIはDocumentDBを知っていて、そこからデータを要求する方法を知っているが、それは、クライアントエンティティのいずれかのエンティティの構造を知りません。だから、API-

_documentClient.CreateDocumentQuery("...") 
    .Where((d) => d.name.Contains(query)); 

でこれを行うには、（dは動的であり、nameは必ずしも共通プロパティではありません）エラーをスローしていました。

これをクライアント上に構築して送信することができます。

クライアントの検索が、これはSQLの無大しただろうsanitzationなければ

{ 
    "page": 1, 
    "pageSize": 10, 
    "query": "CONTAINS(name, 'choco')" 
} 

を要求しました - 。しかし、それは/それはdocumentdbのために重要ですか？消毒されていないクライアントクエリを実行するにはどのくらい安全ですか？

Answer 1

この公式文書Announcing SQL Parameterization in DocumentDB通り：

この機能を使用すると、あなたは今パラメータ化されたSQLはを照会書くことができます。パラメータ化されたSQL は、 "SQLインジェクション" *を使用して、偶発的なデータエクスポージャを防止しながら、ユーザ入力の堅牢な処理とエスケープを提供します。 .NET SDKを使用したサンプルを見てみましょう。プレーンなSQL文字列とLINQ式に加えて、パラメータ化されたクエリを構築するために使用できる新しいSqlQuerySpecクラスを追加しました。

クエリは厳密に読み取り専用の操作あるためDocumentDBは「特権の昇格」につながるインジェクション攻撃の最も一般的な種類の影響を受けません。しかし、は、ユーザーが悪意のあるSQLクエリを作成することによって、同じコレクション内でアクセスすべきでないデータにアクセスする可能性があります。 SQLパラメータ化のサポートは、これらの種類の攻撃を防ぐのに役立ちます。

ここでは著者名のために、単一のユーザ指定されたパラメータで「ブック」コレクションを照会する公式のサンプルです：

POST https://contosomarketing.documents.azure.com/dbs/XP0mAA==/colls/XP0mAJ3H-AA=/docs 
HTTP/1.1 x-ms-documentdb-isquery: True 
x-ms-date: Mon, 18 Aug 2014 13:05:49 GMT 
authorization: type%3dmaster%26ver%3d1.0%26sig%3dkOU%2bBn2vkvIlHypfE8AA5fulpn8zKjLwdrxBqyg0YGQ%3d 
x-ms-version: 2014-08-21 
Accept: application/json 
Content-Type: application/query+json 
Host: contosomarketing.documents.azure.com 
Content-Length: 50 
{  
    "query": "SELECT * FROM books b WHERE (b.Author.Name = @name)",  
    "parameters": [   
     {"name": "@name", "value": "Herman Melville"}   
    ] 
}