简单的 Linq 安全性答案

【问题标题】：Simple Linq Security简单的 Linq 安全性
【发布时间】：2015-09-14 01:11:18
【问题描述】：

我正在尝试查找我的 ASP.NET 登录页面中的安全漏洞。我将如何清理用户输入，以便不可能进行 XSS 和 SQL 注入？我觉得我的 Linq 查询是安全的，但我可能是错的。如果您需要更多信息，请告诉我。

String username = usernameTxt.Text.toString();

Company check = (from u in context.Company
                                where u.companyadminUserName.Equals(username)
                                select u).FirstOrDefault();

if (check == null)
{        
    return BAD_USER;
}
else
{
    return GOOD_USER;
}

【问题讨论】：

见stackoverflow.com/questions/305044/…和stackoverflow.com/questions/3955658/…
这是 Linq（语言集成查询），而不是 Lync（企业通信产品）
L2S 和 L2E 使用参数化（使用分析器或手动转储查询非常容易检查），所以你应该很好。
@DavidL，但从某种意义上说，这是一种错误的安全感，在某种意义上，如果没有系统地处理问题，我会断然地说“我受到 XSS/SQL 注入的保护”，我会感到不舒服.如果它是一个在你没有意识到之前的实现细节，那么它就是一个问题
@tacos_tacos_tacos 首先，值得指出的是，这个问题并没有以任何方式解决 XSS。其次，如果您使用的是对象模型 api（OP 是），您的查询将被参数化并且不使用字符串连接，所以是的，您可以说只要您不执行 sql 命令，您就可以防止注入和/或通过实体框架的不安全存储过程。

标签： c# sql asp.net xss sql-injection

【解决方案1】：

嗯，这有助于了解您正在使用的LINQ-to-SQL 的实现。我想每个实现都会默认将参数转义到 LINQ 扩展方法，但仔细检查不会有坏处。

通常，您希望在用户界面和服务层之间始终有一个中间人。你可能在你的应用程序中都有它们；验证器。在验证数字是数字或邮政编码是邮政编码的情况下，它们更明显是必要的，但没有什么比验证所有用户输入都没有被转义的风险更高。但这还不够好 - 这只是开始。

我的建议是在边界处设置ASP.NET 提供的东西 - 以防止 HTML 也被输入到用户界面输入中 - 但也在瘦控制器和厚服务之间的边界处，或者作为它自己的层。

在这样的设计中，也许您可以在每个数据库输入参数上实现一个属性或注释，如InterrogateTheCarrierAttribute（假设您已将所有数据库调用参数化为函数，并且您没有连接字符串来进行查询）。在任何类似的事情上：每个Powershell 调用包装器或sh 包装器或访问银行帐户和提取资金等功能。然后，当对象以一种或另一种形式出现时，每次它们通过“验证”边界”，它们必须进行消毒，就好像无法保证超出范围的卫生一样。这是矫枉过正，但除非验证成本高昂，否则为什么不呢？

想一想：如果文本文件或受信任的 Web 服务遭到破坏，而不是糟糕的用户界面输入，该怎么办？如果您从“这一层，这一层”的角度来考虑它，您可以说服自己，在没有安全的地方有安全。 Microsoft 的 Web 服务器永远不会向您发送格式错误的数据包，对吗？您的记录器永远不会发送您的数据库错误SQL，对吗？但它可能发生。因此，使用“跨领域”验证方法，您总是在边界处进行验证，至少在进入的过程中，并且可能在退出的过程中。这样一来，您就不太可能因为错误的假设而让您的数据库接口完全打开。

示例：接受您的查询。关键的问题是 1) username 是否被转义，以及 2) 未转义的 username 是否有可能以某种方式克服 LINQ to SQL 是一个主要抽象并且不适合立即注入的事实。

现在您应该知道这些问题的答案，但我们的系统不应该要求全知才能有效。所以，我建议实现一个横切层来进行验证，但是你想这样做。

【讨论】：