我正在计划一个将在 C# 4.0 中构建的程序。我正在考虑使用 LINQ to SQL，但这是我的问题。因为这个应用程序是公开的，所以任何人都可以在大约 5 分钟的时间内对其进行去混淆处理并在 .net reflector 中打开它。然后他们可以轻松地进行更改以转储我的表或插入/删除/更新数据。我知道这一点，因为凭借我使用这些程序的基本逆向工程技能，我什至可以做到。
有没有一种方法可以在.net 中执行安全可靠的数据库事务（或至少更安全）。现在我知道你永远不可能 100% 安全，你能做的只有这么多。这是一个非常开放的话题，但我只是在寻找关于你为确保这种类型的安全所做的或知道的人所做的事情的建议事物。
我只是希望它足够安全，以至于有人需要真正尝试造成伤害，而不是仅仅将它开放给全世界看。
谢谢！
如果您正在寻找一种方法使您的代码不可读/无法使用 Reflector 进行检查，那么没有万无一失的方法。您可以使用代码混淆，但它也可以被破坏。它只会让它变得更难一些。（更多在这里。）
但是，有一些方法可以构建一个不允许用户恶意影响您的数据库的安全 .NET 应用程序。几乎每个 .NET 应用程序都以某种方式使用数据库。
你的问题有点笼统。为了有效地保护您的数据库和应用程序，您需要知道危险，知道如何配置您的 SQL Server，知道如何进行防御性编码。你问的很好，但答案不是一个快速而简单的答案。真正的答案是“开始研究和学习”。
听起来您在谈论的是 WinForms 应用程序，而不是 .NET，但您要解决的特定漏洞 - SQL 注入（或者在这种情况下，可能是 SQL 篡改，因为您担心有人反编译应用程序） - 是两者共有。就保护数据库而言，最大的区别在于如何加密 .config 文件。它在 WinForms 中略有不同。 这是一篇文章，展示了如何做到这一点。
防御性编码是一个因素。本文中的课程适用于WinForms 世界，甚至在 .NET 之外，即使它是面向 ASP.NET 的。
在您的情况下，您需要关注的具体做法是最小特权的做法。从我链接到的文章中：
使用最低权限的数据库帐户
您的应用程序应使用最低权限帐户连接到数据库。如果您使用 Windows 身份验证进行连接，则从操作系统的角度来看，Windows 帐户的权限应该是最低的，并且应该具有有限的权限和访问 Windows 资源的能力。此外，无论您使用Windows身份验证还是SQL身份验证，相应的SQL Server登录都应该受到数据库中的权限的限制。
考虑在 Microsoft Windows Server 2003 上运行的 ASP.NET 应用程序的示例，该应用程序访问同一域中不同服务器上的数据库。默认情况下，ASP.NET 应用程序在网络服务帐户下运行的应用程序池中运行。此帐户是最低特权帐户。
因此，您需要以最小权限的原则来设计数据库，这样即使有人反编译了您的应用程序，他们也不会做任何恶意的事情。
创建一个特定的用户（或多个用户）并只为用户提供他们需要的访问权限。需要从表 X 中读取，但不写入？没问题。只授予他们对表的 SELECT 权限。不要授予更改、编辑、插入或查看权限。简而言之，提前计划，知道他们需要什么权限，并相应地设计数据库。
或者（这不是推荐的方法）从没有权限的用户开始并开发应用程序，并在您进行时授予权限。这应该在测试/开发数据库而不是生产数据库上完成，如果您遵循良好的安全实践，则应该记录在案，但这是另一个问题。这种方法会奏效，只是它不是最自律的。
对于 ServerFault.com 来说，如何做到这一点更多的是一个问题，但如果您使用的是 SQL Server，MSDN 会提供大量指导，并且其他数据库系统也同样有充分的文档记录。
其他选项包括不提供对数据库的直接访问。使用Web 服务或WCF在您的服务器上公开服务。客户端只调用暴露的函数，对底层数据库一无所知，因此不存在直接访问的风险。我们之所以选择此选项，是因为它增强了安全性，并且使我们不必在数据库发生更改时重新编译和重新部署客户端代码。假设我们想从 SQL Server 切换到大型机的 DB@ 数据库（反之亦然），我们只需更改 Web 服务中的代码，而不是数百个客户端中的代码。
但是，即使使用这种方法，您仍然需要将服务设计为安全的，因此仍然需要学习。
即使您生成的 .exe 对 Reflector 和类似工具可见，但这并不意味着必须连接到您的数据库。
如果您有 SQL 注入漏洞，那就不同了，应该单独修复 - 但您应该研究加密数据库交互的方法。
这个问题和相关答案应该给你一个很好的概述： 如何安全地配置数据库连接
如果您从应用程序直接连接到数据库，用户可以从 app.config 获取连接字符串并直接连接到数据库，甚至无需反映您的代码。当然，您可以加密您的连接字符串，但是只要稍微使用反射和调试，无论如何都可以提取它。
所以我会说你的数据库无论如何都不会受到保护。
您可以通过以下方式保护数据库：放弃（使其成为应用程序本地），保护数据库，而不是应用程序 DAL，选择服务方法。
这个问题表明你有点忽略了这一点。
如果用户有权访问您的数据库或某些公共 Web 服务或任何公共接口，那么您需要某种方式来验证和授权该访问。
无论攻击者是否知道您的客户端是如何工作的，该接口都可能受到攻击。保护客户只能减慢他们的速度。