我对此很陌生,但我已经开始了解使用 Breeze 公开 IQueryable<> 的安全风险。有人可以向我建议一些最佳实践(或仅仅是一些建议)来保护在 JavaScript 中公开的 IQueryable 集合吗?谢谢。
2 回答
我不会通过 IQueryable 公开任何应该通过随机查询发送给客户端的数据。因此,可以暴露投影或 DTO。
我不确定这是否能回答您的问题……您担心什么“安全风险”?
我也支持这个问题。但是要在 Ward 提出的问题中添加一些细节:
在保护可查询服务时,会想到两个传统问题:
1) 垂直安全性:当前登录的用户(基于用户身份或角色)不允许在 UI 中看到哪些项目。那些需要从可查询列表中删除。IMO,这可以通过在返回的 IQueryable 上链接一些排除逻辑来作为可查询 ActionFilter 魔术的一部分来完成。2) 横向安全性:某些模型包含不适合登录用户查看(和/或编辑)的字段。这更难处理,因为这不仅仅是从返回的 IQueryable 中删除实例的问题。返回的类具有不同的形状,因此可以通过 json 格式化程序处理基于安全性(AFAIK 搞砸了微风元数据)的字段,或者在这种情况下返回 DTO,因为元数据中不存在 DTO它' s 不是一个完整的生命周期(可更新)类?(我问这个不是说明它)
我希望看到内置支持或易于实施的 2 号食谱)。也许一些示例代码可以修改客户端元数据,以使 DTO 与模型对象完美结合。newset VS 2012 SPA 模板(在 TodoList 应用程序中)似乎在可查询和插入/更新端推送模型对象的 DTO 变体。这类似于传统的 MVC 模型视图......
最后 - 我会添加一个请求以自动处理插入和更新的过度发布安全问题。这是 2) 的倒数。某些用户不应该能够编辑某些字段。