Securing your Data Layer in a C# Application

Question

I was thinking about how to secure the Data Layer in a C# Application, the layer could in this case be either a LINQ to SQL Model Diagram stored with the Application itself

Answer 1

I am not completely clear here. If the winforms application calls webservice then use a appropriate model for mutually trusted authentication. This can be based on client and server certificates or SSL with client certs or even Net.Tcp if you are all .Net. Then however the webservice is exposed only trusted clients can communicate. The webservice can then stay behind a DMZ and the DB behind another DMZ. Use appropriate firewall rules and IPSec connection between webservice and SQL is an option.

For direct connection to SQL server to many winforms application the challenges are many.The connection to your DB has to authenticated and encrypted. In any case your SQL server will be exposed and I would not recommend such a model.

Answer 2

You don't secure it because you can't secure it. First you can't properly hide credentials, even though you figure out how to do that then an attacker can sniff (yes even if it's encrypted you can locally sniff) or do SQL Injection directly on the wire.

You need to write all of you webservice calls in a secure manner which doesn't require to transfer raw SQL Query or direct SQL Server connection.

Also it doesn't matter how much obfuscate or encrypt it if the code is not running your system it's not your code any more. By reverse engineering, debugging, modifying the code a potential attacker can change your application into something else and do whatever they want.

Also as someone else wrote your webservice will be open to direct access. Someone can make a call directly to your web service and ignore the GUI at all.

Answer 3

One of the more common approaches with web services is to pass an encrypted username and password via the web method signature in order to validate that the user attempting to invoke the web method indeed has rights to do so.

In terms of the configuration file it is possible to encrypt the file itself or use integrated security as another poster mentioned.

Answer 4

If I understand the OP correctly, the immutable design characteristics are a WinForms client connecting directly to a publicly accessible SQL Server?

Almost everyone who responded has basically said 'don't do this, use a web service instead'. This is good advice. Even if the ws is hacked, it can only do things it was designed to do. So an RPC WS can only execute methods already written whereas hacking a SQL Server connection would allow arbitrary SQL Execution. Also, I think you would find that a well designed web service would be more performant.

However, if you are going to do this then you must secure your SQL connection over SSL (see technet) as a start. As with secure web services (which also would use SSL) this will hide the contents of the traffic from the men in the middle.

You can't rely on the authentication of the connection string (but using it adds another layer for a hacker to get through), so you must have an application level authentication layer that you most likely would roll yourself.

Don't allow the WinForms application to connect to your operational database. Create another database instead and allow the connection string based auth to connect to it. Do not do dynamic SQL with this design, use stored procedures instead. Create stored procedures in your public database that would act as your "rpc web service" to hide the real SQL (which would query your operational database and return the results). This will hide the operational details of your schema and reduce the surface area of attack.

If procedures are out of the question because you must use dynamic SQL, still keep the public/operational database structure and use views to expose as little of the data as possible. Leverage user id and any multi-tenancy features you have in the database to pre-filter data in the view. If you can do that you reduce the surface area of attack to the connected user's data.

Without understanding why you must allow a direct sql connection, I can only say again that you shouldn't do it. What you are gaining by doing so in the short term is at the cost of your system's long term security.

Answer 5

In your case there are two main attack possibilities:

• Steal the connection string and then access the database directly
• Call methods in your C# code directly without using the UI

For the connection string you need to store it in an encrypted form in a config file. Problem is that there need to be enough information in the winforms app so that it can decrypt and use it.

For accessing the code directly you can use code access security and obfuscation.

In your case I would not give the windows app direct access to the database. Let the windows app call a WCF service, the the WCF service would access the database.

The user's user account is allowed to call the WCF service, the WCF service is running under an account that is allowed to access the database, the user's user account has no rights to the database.

Windows App with 3 Layers:

• UI
• Business (Security check what UI should be shown to the user)
• Proxy

WCF Service with 2 Layers:

• Facade / Business Layer (Security check is user allowed to call this method with this data)
• Entity Framework datamodel

Common dll's to both Layers

• Contracts / WCF Interfaces
• Data Transfer Objects

For info on proxy, contracts and DTO's see this video:

http://www.dnrtv.com/default.aspx?showNum=103

Answer 6

It's difficult to provide a precise answer because I'm not sure what specific issues you are trying to solve and which is the key driver for securing the system.
However, in the past I have used WinForms -> WebService secure communication by utilising WSE
We used X509 certificates and WS-Security. This has the distinct advantage of providing End To End Security rather than relying on standard SSL transport.
However this in of itself doesn't solve issues like user authentication per se, in that case Mitch Wheat's answer seems a good solution.
However, your user authentication model will depend on whether this is a public distributed app, whether the number of users of the tool is large or small etc.
For small numbers of users, or where cost is not an issue, you could implement RSA SecurID authentication by setting up a RADIUS server or such like. This has the advantage in that each RSA key is unique and tied to that user ( though you can never stop a user giving out their credentials and PIN )

HTH