Question

我有一个Silverlight应用程序，它通过WCF与ASP.NET后端进行通信。我有一组DataContract对象，我定义的（大部分）与我的ASP.NET后端使用的LINQ to SQL生成的类型相匹配。当我需要将数据传输到Silverlight客户端时，我的WCF代码从LINQ to SQL生成器类型生成我的DataContract对象的实例。

我的问题如下：通过我的DataContract对象公开索引（在数据库中用作主键）有什么安全隐患？

我的数据库中的示例表（位置）包含以下列：

PositionIndex：int（主键）
PositionName：string
PositionType：int

相应的对象是（或多或少）这个：

public class Position
{
    public int PositionIndex { get; set; }
    public string PositionName { get; set; }
    public int PositionTYpe { get; set; }
}

我很担心，因为我知道通过Reflection对Silverlight DLL进行逆向工程是多么容易 - 任何潜在的坏人都会知道我给客户端提供了数据库索引，并且因为他们可以对Silverlight DLL进行逆向工程，所以他们可以轻松获取我的WCF服务的URL并尝试打破它们。现在，我一直很好，接受了许多前来我的建议，我在ASP.NET方面做了很多检查，以验证我的WCF服务是否得到合法的输入，但我仍然担心通过给潜在的坏人提供一些，不多，但有些，洞察我的系统的后端是如何设计的，我做了一件坏事，而且我已经足够长时间知道这对于一个坚定的人来说已经足够了从...开始。

你们觉得怎么样？如果我在DataContracts中使用索引做了一些不好的事情，你能建议一个替代方案吗？我发现很难想出一个不提供该索引的设计，因为我需要Silverlight客户端来更新我的数据库中已有的行，并且索引是我能想到帮助的最佳方式ASP.NET端确定需要更新数据库中的哪一行。

Answer 1

有一点可以帮助实现某种授权，以便您跟踪哪些客户“拥有”哪些密钥，这样他们就无法改变他们不应该改变的记录。

Answer 2

https://stackoverflow.com/questions/的 454771 / IS-它安全到暴露-数据库索引到Silverlight的客户端

标准做法是在URL等中使用主键。您需要注意的是确保允许客户端在发送资源之前查看资源。

：）

Answer 3

使用数据库ID或“自然键”无关紧要 - 安全问题是相同的：您需要一种方法来唯一地识别记录，并且该知识可能会被滥用。

自然密钥的主要优点是，如果您需要存储与系统断开连接的中长期记录，或者在并行系统之间传输记录（主键不再有用） - 但是这似乎不是问题。

如果安全性是主要问题，您可以为仅存在于客户端会话的对象发出临时密钥（可能是guids） - 将它们重新映射回服务器。然而，在实践中这将是安静的痛苦。

当然，您可以使用Guids 作为主键（uniqueidentifier）：基于guid的键的另一个优点是（如果随机生成）它们不允许您使用数据查询的“key + 1，key + 2”方法。

无论哪种方式，您都应该验证客户端是否允许[创建/读取/更新/删除适当的]他们试图操作的记录。

向Silverlight客户端公开数据库索引是否安全？

3 个答案: