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.
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'm new to web development and I'm developing a web app in MVC 5 / C# where I want to access data from the SQL server from multiple devices (laptop, PC, iPad etc).
I've setup a small test website and SQL database on the Azure account and have been able to run CRUD operations from the website from a single device.
The problem I'm facing is when trying to access the data from another device. I'm constantly needing to manually add new IP address to the SQL firewall. To make matters worse my ISP has me on a dynamic IP.
Eventually I'm planning to provide a subscription service where clients can login via the website and access their data. Is there any way to allow multiple connections to an Azure SQL database without having to manually update the firewall?
Would setting up an Azure VPN an a VM running SQL server be the way to go?
Regards,
Marc
Might be worth taking a look at Windows Azure Mobile Services. Mobile Services provides a REST interface over your Windows Azure SQL Database automatically. Could be a good option, especially if looking to access the database from multiple devices.
http://www.windowsazure.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-get-started-data/
In general, under NO circumstances should you ever make your database server directly accessible to the general public. There are far too many security risks associated with doing so- by exploiting vulnerabilities in the SQL capabilities, you (as a hacker) could quite easily take full control of the instance. That's one reason why you have to constantly update your firewall settings.
To solve your issue with the ISP re-assigning IP addresses, I would ask the ISP for a static number. It will probably cost you on the order of $10 per month, but worth the saved headache in my opinion. I am fortunate to have Comcast, and they do not reassign IP addresses randomly, but I know several other ISPs who do.
The generally-accepted way to make your data available is through a REST-based web service.
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.
This topic has been discussed million times before, but let me clarify my needs:
I need a single server which controls a system and includes the necessary functions. Furthermore, there will be "n" Clients which represents only the HI/GUI and call server side functions. The server itself should be able to send data back to the clients and call client-side functions too (like shutdown, exit and so on...)
I have heard about duplex services/contracts (http://msdn.microsoft.com/en-us/library/ms731064.aspx), but I'm not sure how far I'll come with that.
How would you handle this?
I recently made a proof of concept app that made both the server and the client host a WCF service each. The client connects to the server and then in a handshake call, gives the server the connection information to allow the server create a separate connection back to the client. It worked a treat with multiple clients on network links from local lan to 64k line on remote sites at the same time.
You could use WCF, and host the service on the server in IIS, in the application on the client and let the client register it's endpoint on the server.
I need to create a system comprising of 2 components:
A single server that process and stores data. It also periodically sends out updates to the agents
Multiple agents that are installed at remote endpoints. These collect data in (often, but not always) long-running operations, and this data needs to get to the server
I'm using C# .NET, and ideally I want to use a standards compliant communications method (i.e. one that could theoritically work with Java too, as we may well also use Java agents in the future). Are there any alternatives to web services? What are my options?
The way I see it I have 3 options using web services, and have made the following observations:
Client pull
No open port required at the agent, as it acts like a client
Would need to poll the server for updates
Server push
Open port at the agent, as it acts like a server
Server must poll agents for results
Hybrid
Open port at the agent, as it acts like both a client and a server
No polling; server pushes out updates when required, client sends results when they are available
The 'hybrid' (where agents are both client and server seems the obvious choice - but this application will typically be installed in enterprise and government environments, and I'm concerned they may have an issue with opening a port at the agent. Am I dwelling too much on this?
Are there any other pros and cons I've missed out?
Our friends at http://www.infrastructures.org swear by pull-based mechanisms: http://www.infrastructures.org/papers/bootstrap/bootstrap.html
A major reason why they prefer client-pull over server-push is that clients may be down, and clients must (in general) apply all the operations pushed by servers. If this criteria isn't important in your case, perhaps their conclusion won't be your conclusion, but I do think it is worth reading the "Push vs Pull" section of their paper to determine for yourself.
I would say that in this day and age you can seriously consider only pull technologies. The problem with push is that clients often are hidden behind Network Address Traversal devices (NAT) like wireless routers, broadband modems or company firewalls and they are, more often than not, unreachable from the server.
Making outbound connections ('phone-home'), specially on well known ports like HTTP/HTTPS can basically be assumed as 'possible' even under most constricted networks.
If you use some kind of messaging server (JMS for Java, not sure for C#) then your messaging server is the only server that needs to open a port and you can have two way communication from your agent to the messaging server and from the server to the messaging server. This would allow you to accomplish the hybrid model without needing to open a port on the agent server.
IMHO, I find your best option is the pull option.. that can satisfy your main system requirements as follow:
The first part: Data needs to get to the server, that's obviously can be done through invoking a web method that send that data as a parameter
2nd part:(Server periodically sends out updates to the agents): You can still do that that thru client (regular) pulls by some sort of a web service method that "asks" for the updates since its last pull (some sort of s time stamp to get the updates it missed)
The hybrid method seems a bit weird to me given that I think of an agent as a part of the system that probably might go "offline" quite often, what will the server then do if that failed? it's usually a tough question/decision, specially if you're not sure if this an intended "going offline" or a system/network failure.. etc