c# 在设置中保护数据库连接字符串防止反编译?

发布于 12-24 19:10 字数 308 浏览 6 评论 0原文

有没有办法阻止人们使用 Reflector.net 反编译我的 .exe c# 应用程序?我知道有很多关于此的帖子,但我并不关心人们是否可以看到我的代码,我唯一想“隐藏”的是我的数据库连接字符串。

我目前正在 C# 中使用“设置”来保留数据库连接的信息。 我想知道在我的项目设置中使用这些字符串是否会阻止人们看到它?

我在 Visual Studio 2008 中使用 DotFuscator,但我听说它并不能阻止人们反编译我的程序。

我知道我可以使用 Web 服务,但我的服务器将在 Linux 上,所以我想我无法在 Linux 上存储 Web 服务。

Is there anyway to prevent people from using Reflector.net to decompile my .exe c# application? I know there is a tons of post about this but I don't really care if people can see my code the only thing I want to "hide" is my database connection string.

I am currently using "Settings" in my c# to keep the database connection's info.
I wanted to know if using those string in my project's Settings would prevent people from seeing it ?

I am using DotFuscator in visual studio 2008 but I heard it wasn't preventing people from decompiling my program.

I know I could use a Web Services but my server will be on linux so I guess I can't store web services on Linux.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

聆听风音2024-12-31 19:10:46

不。即使您在程序代码或设置文件中加密连接字符串,您也需要对其进行解密,并且程序必须在某处包含解密密钥,这意味着有足够兴趣的人可以找到它将会找到它,无论您在隐藏它方面多么有创意。为什么需要隐藏连接字符串?如果您担心拥有您的程序的人可能会直接调用 Web 服务并触发意外操作,您应该研究 Web 服务的结构、它们允许客户端执行的操作以及授权的工作原理,并在那里进行安全改进反而。

No. Even if you encrypt the connection string in the program code or in a settings file, you will need to decrypt it, and the program must necessarily contain the decryption key somewhere, which means that someone who is interested enough in finding it will find it, no matter how creative you are in hiding it. Why do you need to hide the connection string? If you are afraid that someone who has your program might call the web services directly and trigger unintended actions, you should look into how the web services are structured, what they allow clients to do, and how the authorization works, and make security improvements there instead.

无所谓啦2024-12-31 19:10:46

如果您的程序中有连接字符串,您的程序的用户可以将其取回。即使您对其进行了加密,当您的程序连接到数据库服务器时,他们也可以嗅探到它。

如果您不希望用户知道您的数据库登录凭据,请不要将您的数据库登录凭据提供给用户。这是唯一的办法。

您可以通过为每个用户提供自己的凭据,并使用数据库服务器中的权限系统来控制他们可以做什么或不能做什么来做到这一点。

If your program has the connection string in it, users of your program can get it back out. Even if you encrypt it, they can sniff it when your program connects to the DB server.

If you don't want your users to know your DB login credentials, don't give your DB login credentials to the users. That's the only way.

You could do this by instead giving each user their own credentials, and using the permissions system in the DB server to control what they can or can not do.

扎心2024-12-31 19:10:46

正如其他人所说,混淆对于存储在用户可以访问二进制文件的客户端应用程序中的连接字符串来说并没有真正的保护。

不要使用程序中的直接数据库连接,除非信任用户能够以相同的权限直接使用数据库。在您自己的服务器上托管一个服务(Web 服务、REST 服务等)。 Linux 可以托管我提到的任何类型的服务(如果您希望它们位于 Linux 上的 .NET 中,请使用 Mono

为了通过 Web 服务公开您的数据库使用 Mono 或任何其他语言/框架,您可以在 Linux 主机上您将创建一个 Web 服务您要对数据库执行的每个原子操作的方法。

与让客户端应用程序直接访问数据库相比,另一个优点是,当客户端应用程序在其自身和数据库之间使用服务时,您可以自由更改数据存储,而不会影响客户端。您可以决定更改数据库中的数据库架构,或者使用 NOSQL 解决方案甚至平面文件替换数据库。

使用服务而不是直接与数据库通信将身份验证/授权要求向前推进了一步,因此现在您需要在服务中实现它。幸运的是,Web 服务对身份验证提供了丰富的支持。

As others have stated obfuscation is no real protection for a connection string stored in a client application where the user have access to the binaries.

Don't use a direct database connection from your program unless the user is trusted to use the database directly with the same privileges. Have a service (web service, REST-service, etc) in between that you host on your own server. Linux can host services of any of those types I mentioned (use Mono if you want them in .NET on Linux)

In order to expose your database via a web service using Mono or any other language/framework you can host on Linux you would create a web service method for each atomic operation you want to perform against the database.

An additional advantage over letting the client application access the database directly is that when the client application is using a service between itself and the database you are free to change your data store without affecting the client. You can decide to change the database schema in your database or replace the database with a NOSQL solution or even a flat file.

Having a service instead of communicating directly with the database moves the authentication/authorization requirement one step, so now you need to implement it in the service. Fortunately there is rich support for authentication in a web service.

赠我空喜2024-12-31 19:10:46

请参阅 MSDN 中有关此特定主题的本指南。但请记住,这只会转移安全问题。现在您需要管理密钥的安全性

Take a look at this guide on this specific topic from MSDN. Keep in mind, however that this only shifts the security burned. Now you need to manage the security of the key

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文