Home/ Questions/Q 7948905
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T01:51:19+00:00

I am planning out a program that will be build in C# 4.0. I

  • 0

I am planning out a program that will be build in C# 4.0. I was thinking of using LINQ to SQL, but here is my problem. Because this application is public anyone can de-obfuscate it and open it up in .net reflector in about 5 minutes of time. They then can easily make changes to dump my tables or insert / remove /update data. I know this because with my basic reverse engineering skills using those programs even I can even do it.

Is there a way to to perform DB transactions in .net that is safe and secure from something like above (or at least more secure). Now I know you can never be 100% safe, and there is only so much you can do .This is a pretty open topic, but I am just looking for advice on what you have done or know of people doing to secure this type of thing.

I just want it to be safe enough that someone would need to actually try to do damage than just open it up for all the world to see.

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If you’re looking for a way to make your code unreadable/not able to be examined using Reflector, there are no fool-proof ways. You can use code obfuscation but that can be broken as well. It just makes it a bit harder. (More here.)

    However, there are ways to build a secure .NET application that will not allow users to maliciously affect your database. Almost every .NET app uses a database in some way or another.

    Your question is a bit broad. In order to effectively protect your database and application, you need to know the dangers, know how to configure your SQL Server, know how to code defensively. It’s good that you’re asking, but the answer isn’t a quick and simple one. The real answer is “Start researching and learning”.

    It sounds like you’re talking about a WinForms application, rather than .NET but the specific vulnerability you’re addressing – SQL Injection (or maybe in this case, SQL tampering, since you’re worried about someone decompiling the app) – is common to both. The biggest difference as far as securing the database is in how to encrypt the .config file. It’s slightly different in WinForms. Here’s an article showing how to do it.

    Coding defensively is one factor. The lessons in this article carry over into the WinForms world, and even outside of .NET, even though it’s geared to ASP.NET.

    In your case, the specific practice you need to focus on is the practice of least privilege. From the article I linked to:

    Use a Least-Privileged Database Account

    Your application should connect to the database by using a
    least-privileged account. If you use Windows authentication to
    connect, the Windows account should be least-privileged from an
    operating system perspective and should have limited privileges and
    limited ability to access Windows resources. Additionally, whether or
    not you use Windows authentication or SQL authentication, the
    corresponding SQL Server login should be restricted by permissions in
    the database.

    Consider the example of an ASP.NET application running on Microsoft
    Windows Server 2003 that accesses a database on a different server in
    the same domain. By default, the ASP.NET application runs in an
    application pool that runs under the Network Service account. This
    account is a least privileged account.

    Therefore, you need to design the database with the principle of least privilege, so that even if someone does decompile your application, they can’t do anything malicious.

    Create a specific user (or users) and give the user ONLY the access that they need. The need to read from table X, but not write to it? No problem. Only grant them SELECT rights to the table. Don’t grant Alter, Edit, Insert, or View. In short, plan ahead, know what rights they will need, and design the database accordingly.

    Alternatively (and this is not the recommended approach) start out with a user that has no rights and develop the app, granting rights as you go along. This should be done on a test/development DB, not production, and if you’re following good security practices, should be documented but that’s a whole other issue. The approach will work, it’s just not the most disciplined.

    How to do that is more of a question for ServerFault.com, but MSDN provides plenty of guidance if you’re using SQL Server, and other Database systems are equally well-documented.

    Other options include not providing direct access to the database. Use Web Services or WCF to expose services on your server. The client just calls the functions exposed, and has no knowledge of the underlying database, so there’s no risk of direct access. This option is the one we take because it enhances security AND insulates us from having to recompile and redeploy client code when something changes on the database. Say we want to switch from SQL Server to our mainframe’s DB@ database (or vice-versa) We would just change the code in the web service, rather than in hundreds of clients.

    However, even using this approach, you still need to design your service to be secure, so the learning still needs to be done.

    • 0