C#/SQL Server中的客户端/服务器安全

我有一台运行在Windows 2008 R2机器上的SQL Server，它需要在上面运行基本查询（选择/插入/更新）。这些操作由客户机直接执行，客户机是一个用C#编写的应用程序，安装在一台位于不同位置的计算机上，因此连接是通过internet进行的

由于在DB上运行的操作的性质非常简单，所以我不希望在SQL Server上编写后端。因此，安全设置：

1） 在客户端写入并提交的用户名和密码

2） 在服务器上运行（参数化）查询，并将密码哈希和salt返回给客户端

3） 密码和salt被追加，使用SHA_512散列，并与密码散列进行比较

4） 如果两者匹配，则可以访问创建和发送查询的工具集

---

在研究了这个主题之后，我觉得这个系统有一些安全漏洞，但我无法准确指出这些漏洞可能是什么。

如果我理解正确，那么整个密码检查都是在客户端完成的。对吗？如果是这样的话，它似乎有潜在的不安全感

你完全信任客户自己吗？如果未经授权的人可以访问客户端，或者创建另一个模仿您的客户端的客户端，那么这将显著增加他们访问您的服务器端的机会

听起来，创建后端系统肯定会更安全，即使它只是一个非常简单的代理服务，只需检查用户名和密码，然后按原样转发查询本身

---

这样，密码散列和盐将永远不需要离开服务器。

根据您的情况，我会考虑为您的应用程序的每个用户创建SQL帐户。当用户登录到应用程序时，请在构造SQL Server连接字符串时使用这些凭据，并允许服务器执行凭据验证。这通常称为直通式身份验证

更好的是，如果您的应用程序将由与SQL Server位于同一Active Directory域上的用户执行，那么您可以使用更安全的Windows集成安全性（您当前用于本地测试的安全性），并且用户根本不需要登录。连接将仅使用其当前的广告凭据。有关使用Windows域凭据在SQL Server中设置用户帐户的详细信息，请参阅此链接：

---

此外，无论使用哪种选项，您都希望使用受TLS保护的连接（Encrypt=true）来帮助防止通过线路窥探凭据。

直接连接到SQL Server的客户端不安全。如果客户端位于本地硬盘上，则可能被黑客攻击

你找不到你想要做的事情的工具，因为这不是一个好的设计

不要让你的逻辑“因为在DB上运行的操作的性质很简单，我宁愿不在SQL Server上编写后端。”如果这很容易，那么这就是设置后端的原因

---

NET拥有完整的基础设施。Windows通信基金会。

对于一个用户，在Internet上有一个端口1433打开的服务器。两个程序可能被黑客攻击。你的客户端和sql server之间的通信是，对吗？是的，SSL。目前，我正在进行即时通讯测试，因此使用“集成安全性”进行所有本地测试。1）如果我没有明确说明密码检查是在cleint端完成的，那么是的2）访问客户端是一个潜在威胁。3） 代理系统是否会将密码以明文形式留在客户端？（通过SSL）可能，但它们最初不是以这种方式发送的吗？不，用户名以明文形式发送，密码临时存储在客户端上，等待“密码检查”过程的哈希和salt。请注意，这是一个桌面应用程序；然后你避免了发送密码，但是你让客户端告诉服务器：“是的，我有权访问这些东西！”。问题是服务器无法知道这是否正确；从理论上讲，流氓客户可能在撒谎，并假装密码不匹配是有效的。谢谢您抽出时间。似乎应该有.NET包来处理这些东西，这样我就不必用我的（可能是不安全的）实现来重新发明轮子。那么现在用户只需下载SSMS登录并直接访问数据库？对我来说，这听起来不是一个好计划。@狗仔队：你应该确保每个用户帐户都被授予了特定的数据库权限，以限制他们在数据库中的操作。通过数据库级审核，您还可以跟踪每个用户所做的更改。也就是说，当使用这样一个简单的模型时，用户将始终能够直接连接到数据库，其中SQL Server是唯一的服务器端组件。从安全角度来看，任何更高级的功能都需要在服务器端提供一个额外的服务/代理，以实现身份验证层。我用SHA_512和salts等设置了一个登录系统，这有点令人沮丧，但这似乎是为该系统将拥有的2-3个用户设置登录系统的最佳方式。权限包括选择/插入/更新。它们会造成很多伤害。嘿-我知道什么-这已被接受。数据库和客户端将不在同一个本地硬盘驱动器上。这是否减轻了您所说的风险？不，它确实减轻了风险。客户机的概念如此困难的地方是可以被黑客攻击的。客户端中的凭据可能被黑客攻击。仅仅给他们的域登录提供凭证就更糟糕了。现在他们不需要破解任何东西。