I'm new at Visual C# and the .NET framework but have a fair amount of experience in LAMP development. I was wondering about the security of linq to sql communication.
Usually when doing it the LAMP way, measures such as using a service layer were used partially to increase the security of the system not exposing the database authentication details over http.
Having gone through a few recommended (by microsoft) linq->sql tutorials, it seems as if the client-side application (through a web application) is interacting directly with the database. This doesn't seem very efficient or secure....
I would like to know the following hings:
1) What measures exist in .NET to allow for secure communication between client-side and server side apps?
2) Are there any preinstalled service-layer frameworks to work with in .NET?
3) Is it possible to manually use http request methods (POST/GET) in order to send data from a c# web application to a remote SQL Server database?
In an ASP.NET application all the C# code you write is executed on the server(server-side), and after it is executed the page is sent to the client(browser). Client-side code refers to javascript. Database details are not sent to the client.
You could refer to a LINQ system as a "client" in relation to the database, but that would be like referring to the PHP part of a LAMP application as the "client" in relation to the database - completely true but slightly misleading. In terms of the overall client - the browser - LINQ no more exposes authentication details than LAMP does.
Which "client" do you mean here. In terms of the browser the main mechanism is that the browser doesn't know what on earth you are doing. It won't even know it is LINQ unless you're the sort of person who likes putting "Powered by..." images on your webpage. In terms of the client to the database, there are several authentication models (user/pass, NTLM, Kerberos and I think some more) and you can use SSL and IPSec on the connection between the webserver and the database server.
You mean like MVC and WCF?
Yes, there has been since SQL2000, see http://msdn.microsoft.com/en-us/library/aa226553%28v=sql.80%29.aspx though I don't think it's very popular. This has nothing to do with LINQ which would connect to SQL through 1433 using its native protocol, and perhaps be used to build a website that allowed restricted operations rather than manual manipulation of server over HTTP.
Related
I am currently developing a C#/WPF/MVVM/EF6 application that allows multiple users in different physical locations to send and receive SMS messages to mobile phones using a third party API.
The database stores all messages, sent and received, and is either updated directly by the user (sending a message) or by a ASP.NET web hook (receiving a message). Users are using SQL authentication and dynamically created connection strings to connect to the database (i.e. pass in a connection string whenever a new DbContext is created). EF is used to query against and display the data.
I'm now encountering what I believe may be a fundamental security issue with my design. The users all need direct access to the SQL database to use Entity Framework methods. After some research, it appears to be very risky to simply expose the SQL Server to the internet. Most suggestions have been to use a VPN or IP White Listing, but unfortunately, neither of those are options. We will have the SQL Server hosted by a third party that will not provide a VPN, and the users will be in different locations frequently so their IPs will not be static.
Are there any additional options to maintain direct SQL Server access with additional security? The only option I am able to think of is to completely change the architecture by creating an API for the application to query against and refactor the code to pull data using the API instead of Entity Framework. Any input would be highly appreciated.
You could create an API that access directly to the database, the api will be exposed over the internet, and you will only define the methods you want to perform on the database (eg CRUD Operations).
The wpf application will no longer be comunicating directly with the database but it will be communicating to the api instead. The api is the one that holds the connection string and is the only one who will have direct access to the db. That way you're not exposing your entire database over the internet.
You could also add Authentication, that way only logged in user could get/insert/modify data from the database, and could also add Authorization for handling user permissions.
Now you should refactor your application to work with the API. Although if you used something like Repository Pattern it will only require a few changes in the repository itself to work properly.
Now your application design has another layer of abstraction which is the API
WPF application → API → Database
The way I consume APIs in my applications is using the HttpWebRequest class . However there are other ways to handle that and this article explains it really well: A Few Great Ways to Consume RESTful API in C#
I agree with you to create API and act like database adapter with 2 reasons.
Letting all client store connection string is too risk and difficult in case you want to scale your project.
especially Windows application like WPF in your case. So having adapter gain you capability to update and maintain seamlessly.
If clients contact to database directly without IP whitelist meaning you are exposing database to public
An idea that I could imagine is creating a WebAPI and let it dynamically creates SQL user for each clients with limited permissions. Then periodically revoke SQL User every given time (Maybe with Webjob). So client won't have long-lived connection string. And you will need only single endpoint.
What client have to do is asking WebAPI for temporaly connection string. With this solution you will be at least have a chance to validate client's credential, role, ip, version number and etc before give them connection string whenever its connection string was revoked. It still requires API. But client will communicates with database directly with better security in my opinion.
NOTE: Since you are letting clients play with database. Make sure client is always the latest version. I think you can check when client asking for connection string.
I've inherited a relatively low traffic web application in which the main website is accessible on intranet, however it gets its data from a wcf service that runs on the same server which is only accessible via localhost. It was explained to me that this design was implemented as a security measure - essentially to ensure that no entity external to the server could potentially have access to our service and hence our data. The database however, is usually located on a different server.
It's been ok for a while but I am looking at ways to improve performance and it seems that running queries against the wcf service and having to serialize the response for transmission etc. is a waste of time - I'd like to just access the db directly from my web app.
Is this current design logical? Wouldn't it be better overall (for security, and performance) to have my site access db directly, and beef up the security between the app and the db?
Thanks in advance.
Rusty
I'm not sure if I have the big picture from your description. However, it is a common practise to have web-applications consuming content from more than a service to form a graphical interface to end-user. With the grow of SOA, this allows for fast integration to combine sources (from services) and producing rich output. This is called Mashup
This also, amongst other things, enhances the security of the backend services as they are only accessed by the backend application server, and not directly from front-end client
So, from an architectural perspective, it seems your application is trying to do this.
Having the services on the same server, and only consumed by the local server (localhost) is a choice taken to prevent but the application server running on the same machine from having access. This could be due to lack of better control on network access and network zoning
Your database lives on a different server, where there could be another measure implemented to secure the traffic and access
In general, implementation of security requires a budget, as any other functional and non-functional requirement. This is usually associated with the risk you're exposed to, and the sensitivity of the information. The earlier the security is built into the overall architecture the better.
Accessing the database from your web-application requires best practices to protect against the many risks of intrusions and vulnerabilities. In general, your web-client should NOT access the DB directly, and should always use server-side services and validation to do so, be it through wcf or other means
I have created an SQL Server and a Client (c#) that directly queries the server. The problem is that I feel this is not secure, because every client (say 5 different clients in total) now has the connection string and i believe this is a crucial vulnerability.
What is the best way to create a back-end for an SQL Server running on my machine. This SQL Server will have to be accessible over the internet from various clients. Is the best option some C# application running with some library to interpret calls from the client?
It will be never secure if you allow your clients to CRUD without login, it is also unsecure if you pass your connection string to your client, if it is not necessary.
The better practice to implement a more secure backend application is you wrap actions into API (let's say UpdateClientInfo()), all database accesses go into the APIs and only allow your client to make use of the API. In this case your connection string will not be transferred via internet.
When the existing APIs are not suitable for your clients, kindly ask them to pull a request and implement the request, instead of providing the connection string to them.
It is also necessary to require the clients to provide user + password when they would like to access to your service.
There are many possible solutions. Exposing the database server is always a security risk. As you're obviously running on a Windows server I'd use a WCF service to handle the communication between the clients and the database.
It is also be possible to implement REST services in C#, which allows you to communication via ports 80 or (preferably) 443. That, depending on the firewall configuration, may be a good idea anyway, as it is a standard port which in most cases will be open for outgoing communication from the client side and can be enabled on the server side.
Look at existing APIs (for example for online shops, etc) to see how they group resources. This will help you design better APIs yourself.
I'm newbie in Silverlight world. I read number of articles to establish connection with SQL Server using Silverlight but sorry to say no one give me concrete results. I want to first make a connection with SQL Server database and then simply load data in combo box. Can anyone give any sound step wise example to make connection with Silverlight project. I found WCF service which is quite helpful to establish connection but feel difficulty to map this service. Please also suggest any other web service with WCF, thanks.
When you look at the Silverlight architecture, you'll see that the ".NET for Silverlight" runtime doesn't include any classes to directly access databases:
http://msdn.microsoft.com/en-us/library/bb404713%28v=vs.95%29.aspx
It contains service client classes, however - so you can use WCF (and WCF RIA Services) to fetch data from a remote server.
That approach makes a lot of sense, too - your Silverlight app will after all run on the client PC, typically in a browser - and you don't really want hundreds or thousands of client PC's anywhere over the planet to have direct access to your SQL Server database. Channelling these data requests through services makes a lot of sense in that way.
This is in contrast to ASP.NET where your code typically runs on the backend server infrastructure, so it's a lot "closer" to your database servers and can make direct calls to SQL Server - it then just returns HTML to the caller (the client's PC and browser).
I found this article here very informative and enlightening:
Getting started with Silverlight - part 3 - accessing data
I am just learning c#, and am programming a Windows client that collects temperature data from the computer and needs to send it to a remote linux mySQL Database.
I was going to program it directly in the c# client, but I want to learn more ways to do this and gain experience. And programming it directly would be less secure and most likely require an extra connector.
Can any of you advise me of other ways, or ways you would do this?
Any way to program a C# program that acts as a web-service on my linux mySQL Server? Where should I look/search to learn more about this. Is it called something special? Or maybe its not done in C#?
Should I program a php script that accepts HTTP SEND/GET requests from my C# Desktop client?
Any other way?
What way is most 'professional' in the real world? Trying to learn on my own! :D
FORMAT:
Windows Desktop: client programmed in C# That retrieves temp data and needs to send to server
Linux Server: Runs Apache and mySQL Server with a database already setup. Closed to outside Connections
My advice is to set up a web service to communicate with your windows client. Directly connecting to mysql server is ok if they both resident in a same lan, but if not, for example your windows client is running on some laptop travelling everywhere or even the mysql server permits local incoming connection only, your should set up a web service. Also the http connection can usually go through firewalls while connections over other ports are blocked.
php is a good way to do this. Since you are learning c#, you may want to use c# to do the server side programming as well, so why not give a try of mono?
Directly exposing a MySQL Server to the internet is strongly dicouraged, Additionally this gives you a rather coarse-grained set of access rights, that might not be enough for your application, so running some sort of server app is the right way to go.
With mono you can run a lot of .Net (and thus C#) based code on a Linux server just fine. Rule of thumb is: If it doesn't have a Winforms GUI and no P/Invoke it will work just fine. Ofcourse this needs mono on the server, which is not given on most commercial hosts.
Running the server in PHP makes it a lot more portable, but has a performance overhead. Additionally it doesn't allow for some of your busines logic objects to be implemented in a DLL assembly and used on both sides.
As for the protocol: Chose your poison. Rule of thumb again is, that predefined protocols such as SOAP tend to need a bit more work (and more learning in the first go), but on the long term tend to be more robust.
For your special use-case I'd personally go with a quick PHP based solution where the protocol is just a simple GET with a few parameters, one being the temperature(s) and the others authenticating the client.
If the temperature sensor generates events, then I would 'push' the data from the Windows box to the Linux box - this will save the latter checking often and finding no updates. However if you are just taking temperature samples, I would 'pull' the data from the Linux machine. Either way, if you want to use HTTP you will need a web service on either side.
Alternatively, you could just connect to your MySQL database remotely from C#, and write the data directly (no web service would then be required). That might be the quickest way to get this working.
The 'which is professional' question is subjective - all three options above are fine. Just make the code clear and concise :)