WCF 查询拦截器：此 MSDN 示例是否存在安全风险？答案

【问题标题】：WCF Query Interceptors: Is this MSDN sample a security risk?WCF 查询拦截器：此 MSDN 示例是否存在安全风险？
【发布时间】：2011-05-08 05:33:40
【问题描述】：

如果您查看this MSDN 文档，则有一个包含以下代码的示例：

// Define a change interceptor for the Products entity set.
[ChangeInterceptor("Products")]
public void OnChangeProducts(Product product, UpdateOperations operations)
{
    if (operations == UpdateOperations.Add ||
       operations == UpdateOperations.Change)
    {
        // Reject changes to discontinued products.
        if (product.Discontinued)  //<-- IS THIS BASED ON UNVERIFIED CLIENT DATA???
        {
            throw new DataServiceException(400,
                        "A discontinued product cannot be modified");
        }
    }
    else if (operations == UpdateOperations.Delete)
    {
        // Block the delete and instead set the Discontinued flag.
        throw new DataServiceException(400, 
            "Products cannot be deleted; instead set the Discontinued flag to 'true'"); 
    }
}

查看所有大写字母的评论。我的问题是：“该行是否取决于客户提供的数据......如果是，我们可以做些什么来进行安全验证”？

【问题讨论】：

感谢您在文档中报告可能存在的问题！

标签： c# security entity-framework wcf-security odata

【解决方案1】：

更改拦截器应该在应用客户端的修改后获取实体。所以行为取决于提供者。如果您的提供将此属性实现为只读（这通常意味着对其的任何更新都将被忽略），那么上述检查没有问题。我确实同意样本在这方面可能会更好。同样取决于您的提供者，如果此属性不是只读的，您需要向提供者询问未更改/先前的值。执行此操作的方法取决于提供者。所以如果是EF，这更像是一个EF问题，如何确定修改后的属性的原始值（实体实例将在当前数据源上跟踪）。

【讨论】：

"在应用修改后"...这是否意味着客户端 HTTP 帖子将往返一些（可能）无效数据，它被应用于 (a) EF 或 (b)提供者。如果 case "b" 那么，SQL server 会得到一个 "write" 然后回滚事务吗？
如果提供者是 EF，则实现将更改应用于服务器端 EF 实体（EF 生成类的实例，上面示例中的 Product 类），但不会传输这些更改任何地方都没有，因为没有在底层 EF 上下文中调用 SaveChanges。
如果提供者不是 EF，那么实际行为取决于提供者对 IUpdatable 接口的实现，但如果它遵循这一规范，它的行为方式应该与 SaveChanges 类似尚未调用，因此更改应仅缓存在服务器本地，而不应用于任何持久存储。