6

私はこれにかなり慣れていませんが、Breeze を使用して IQueryable<> を公開することのセキュリティ リスクを理解するようになりました。JavaScript で公開されている IQueryable コレクションを保護するためのベスト プラクティス (または単にいくつかの推奨事項) を教えてください。ありがとう。

4

2 に答える 2

4

ランダムクエリを介してクライアントに送信されるべきではないIQueryableを介してデータを公開することはありません。したがって、プロジェクションが公開されるか、DTOになる可能性があります。

これがあなたの質問に答えるかどうかはわかりません...あなたはどのような「セキュリティリスク」を心配していますか？

于 2012-12-13T19:38:25.553 に答える
3

私もこの質問に賛成です。しかし、Ward が尋ねた質問に沿っていくつかの詳細を追加すると、次のようになります。

クエリ可能なサービスを保護する際に、2 つの従来の問題が頭に浮かびます。

1) 垂直方向のセキュリティ: 現在ログインしているユーザー (ユーザー ID またはロールに基づく) が UI で表示できない項目。それらはクエリ可能なリストから削除する必要があります。IMO、これは、返された IQueryable でいくつかの除外ロジックをチェーンすることにより、クエリ可能な ActionFilter マジックの一部として実行できます。2) 水平方向のセキュリティ: 一部のモデルには、ログインしたユーザーが表示 (および/または編集) するのに不適切なフィールドが含まれています。これは、返された IQueryable からインスタンスを削除するだけの問題ではないため、処理がより困難になります。返されたクラスは異なる形状を持っているため、json フォーマッタがセキュリティに基づいてフィールドを省略して処理するか (AFAIK はブリーズのメタデータを台無しにします)、または DTO を返すことで処理できます。この場合、DTO はメタデータに存在しないためです。それ' 完全なライフ サイクル (更新可能な) クラスではありませんか? （私はこれを述べているのではなく尋ねています）

ビルトインのサポート、または番号 2 の簡単に実装できるレシピを確認したいと思います)。おそらく、クライアント側のメタデータを修正して、モデル オブジェクトと組み合わせて DTO を完全に正常に動作させるためのサンプル コードです。newset VS 2012 SPA テンプレート (TodoList アプリ内) は、クエリ可能側と挿入/更新側の両方でモデル オブジェクトの DTO バリアントをプッシュしているようです。これは、従来の MVC モデルビューに似ています...

最後に、挿入と更新のオーバーポスティング セキュリティ問題の自動処理にリクエストを追加します。これは 2) の相反する側面です。一部のユーザーは、特定のフィールドを編集できないようにする必要があります。

于 2012-12-23T17:43:12.617 に答える