Microsoft recommends using Windows authentication when connecting a Windows application to an SQL server database.
http://msdn.microsoft.com/en-us/library/89211k9b.aspx
I understand this to mean that the database must have a user with enough permissions to manipulate data and that user links to the currently logged in Windows user. If this is true, how do I prevent the user from bypassing the application and simply modifying data directly in the database?
It seems like I am stuck between using Windows Authentication and potentially allowing users to modify data directly in the database, or attempting to hide the connection string password somewhere so only the app can modify this data.
If you're that concerned about it, you can implement a logon trigger on the server that for certain people (e.g. members of a certain Windows group), they can't log in unless the application name has a certain value. Note that this is weak security since it's pretty easy to set the application name (even in SSMS). It can/will slow down the logon process, though. So keep that in mind if that's a concern for you.
Alternatively, you can have your application authenticate to and interact with an application server, after which the application server connects to and interacts with the database. The application server can run as a service account, to which you'd grant the permissions you need. This way, the end users' accounts aren't in the database to do raw DML against the db.
But I agree with the other answer here: stored procedures are the classic answer to this question.
It is possible to create stored procedures / views etc and only allow the user permission on those. This prevents the user from accessing the database structure directly, and you maintain control over what the user can do (via creating the functionality in the stored procedures / views). If using windows credentials, I think that this would be the best solution.
This site explains how to grant there permission on stored procedures.
http://msdn.microsoft.com/en-us/library/ms345484.aspx
Here is the list of options, for posterity:
Windows authentication only
Pros: simple, No secret to hide.
Cons: user can easily modify data bypassing your app
Password in connection string
Pros: simple, prevents user meddling in your db's.
Cons: have to hide a password yourself, which is always the worst option.
Sprocs access
Create sprocs to access your data, grant access only to those sprocs. No one but the dbo can alter tables.
Pros: Tightest control over what both the user and the application can do to the data
Cons: Higher coupling of database and application; more expensive than the first 2 options.
Proxy
Create a second executable, whether a web or a windows service, with which your GUI application communicates. The 2nd executable can run with different, securely hidden credentials (IIS, Windows Services).
Pros: Decoupled database and executable, securely hidden secrets.
Cons: By far the most expensive solution.
Related
Good day all,
I am studing the following case:
Scenario: An application connects to the production database(SQL server 2008) using a generic "SA" user instead of the domain user. This is making traces\logs\organization harder, because everything is flagged as done by SA user!
NOTE: In the application the domain user/password is used, the generic account is only regarding to the database.
Questions: What would be the best pratice in this case? every user should have an account to log in the database? (sql using windows authentication) there are +- 500 users is that an issue regarding to database performance? or a generic account is indicated?
Many thanks!
As others have mentioned, Active Directory and Windows Authentication might be more appropriate if that's an option. But if not...
If the application has a central place that creates the connection & transaction prior to update, you may be able to use SET CONTEXT_INFO to pass along the "real" application user while still using a shared SQL account for the login.
Then in your auditing triggers you can pull the information back out again using the CONTEXT_INFO() function
This is the approach used by at least one commercial auditing tool
See also similar SO questions here and here which reference context_info and a blog post Exploiting Context_Info for Fun and Audit which gives an NHibernate example.
Nitpick on something else in your question: you said it's using sa user. Maybe that was just an example, but probably the application should not have so many rights on the server. Create a user with only the rights needed for the particular database(s) that application uses. This limits the impact of any future security vulnerability (e.g. SQL Injection) in your application. And to take it one step further, you might have one connection string with a read-only user account, and then at the point where you create a transaction to update data, switch to a connection string with the read/write user account. You still get most of the benefits of connection pooling, but you limit even further the impact of any application-tier bugs.
I have a rich client program installed on users PCs where I want to start storing some user created data on SQL Azure/SQL Server. The potential anonymous-to-me users would key in their name, email account and a password which would get stored on SQL Azure/SQL Server. Then they would start generating their own data. I'm anticipating volumes of maybe 1000 users.
There are times when those users would like to run their own queries against their own data but, obviously, I must ensure that they can never view other users data.
I'm thinking the best way to ensure security of data is for each user to be issued their own SQL Azure account and password. I will setup a SQL Azure user and long password, known only to me, which only has permissions to execute several stored procedures with appropriate parameters being passed to those SPs which will create the SQL Server accounts, logins and add the users to a role which I have created.
Obviously someone running debugging tools could figure out the user name and password but I'm thinking this isn't a big deal. If all that particular SQL Azure account can do is execute a few SPs so what if a malicious individual starts doing that. I will only allow a very limited amount of data to be uploaded before I require payment.
The users can only insert records using stored procedures which use the following:
SELECT #uName=SYSTEM_USER
and only select appropriate parent records. All stored procedures which users can execute would have the above as required to ensure they can only work with their own records.
All views will have embedded with them WHERE clauses such as
WHERE tbLoginName = SYSTEM_USER.
I'm new to SQL Server so I may be missing some fundamental concepts so I'd appreciate any and all comments.
The issue is, as pointed out on http://msdn.microsoft.com/en-us/library/ms189751.aspx:
In SQL Azure, only the server-level principal login (created by the provisioning process) or members of the loginmanager database role in the master database can create new logins.
Those accounts are also capable of alter and drop logins. So if you embed those accounts in the client application, you’re essentially granting every user permission to alter/drop other users accounts. While an average user won’t do that, a hacker will. So you cannot let a client application manage SQL Azure logins, unless only trusted users (such as your IT administrator) are permitted to use the app.
Best Regards,
Ming Xu.
I would like to point out a potential issue in the approach you mentioned: Your master SQL Azure account need to have privilege to create new accounts and grant them access to particular tables. This means your master account itself need to also have access to all those tables. If you store the master account on the client side, a clever user will get access to all users data.
From my experience, connecting to a database directly from a client side application will almost always make your solution less secure. You can do that for testing purposes, but in a real world solution, I would like to suggest you to use a service. You can host the service in Windows Azure. Then the service will access the database, and client application can only access the service. In this way, you can authenticate clients using any mechanisms you like, such as ASP.NET membership.
Best Regards,
Ming Xu.
You are essentially creating a physical two-tier database connection, allowing a client application to connect directly to the database. This is a problem in many ways, including security and performance. From a security standpoint, not controlling from where your customers will connect, you will need to keep your firewall rule wide open for anyone in the world to try to hack every customer uid/pwd. And instead of having only 1 user id to play with, hackers will have up to 1,000...
The second issue is performance. You applications will be unable to leverage connection pooling, creating undue stress on your database server and possibly hitting throttling issues at some point. Using a web service, with ASP.NET membership to manage logins, and using a service account (i.e. the same uid/pwd) to get data will ensure you will leverage connection pooling correctly if you keep the connection string the same for all your requests.
With a web service layer you also have a whole slew of new options at your fingertips that a two-tier architecture can't offer. This includes centralizing your business and data access logic, adding caching for improved performance, adding auditing in a centralized location, allowing to make updates to parts of your applications without redeploying anything at your customer locations and so much more...
In the cloud, you are much better off leveraging web services.
My 2 cents.
I have a question that really feels like I should have an easy answer to, but for one reason or another I haven't been able to totally reason around it.
I'm embarking on development of an ASP.NET MVC3 intranet application, and I'm currently working on designing authentication & authorization. We're forced to use basic authentication in our environment, and we use Active Directory, so the authorization part is generally taken care of. Unfortunately our role/user hierarchy in active directory doesn't mirror what I need for the roles in the application, so I'm going to have to define my own.
I'm using SQL Server, so I was originally thinking of using stored procedures for all DML, and then creating roles and adding users in roles in SQL Server, and then controlling access to the stored procedures via those roles. I was also thinking I could query for those SQL Server database-level users & roles in order to use that as the source of authorization info in the application itself. That originally seemed like a great idea, but it doesn't seem like a popular one (for one, it seems the queries for that are a little long and messy for what they produce). Alternatively, would it be better to have the web app impersonate a user for all queries to the server, and then implement a user/role database with my own schema, and only authorize on the application side?
It originally seemed that authorizing on both the application and database side would be a good thing for security, and using the SQL Server user/role objects means that the user and role data wouldn't need to be stored in two places.
I did see some potentially relevant discussion at Best practice on users/roles on SQL Server for a web application, but I think this is a different question overall.
Thanks!
I recommend creating a sql login that the web application will use to connect to sql server. This way you are not impersonating any specific AD account which may get deleted, disabled in the future and can control the user strickly in SQL Server.
I would then recommend implementing roles based authentication in your application. This will enable you to create users and roles that are custom to your application and then assign users to them. This way if a user tries to access a resource that their role is not allowed it will not do any work. Here is a demo app based on this principle http://www.codeproject.com/KB/web-security/rolesbasedauthentication.aspx.
We have some corporate intranet users using a WinForms app to work on a system with SQL server behind. Integrated Security is setup, allowing all users update and delete permissions, where application security limits how and where table updates take place.
However, some users are power users with SQL query tools at their disposal, and access the DB directly for building reports. However, with integrated security, they have default update rights on tables where they should not have, as the application apply rules to the updates.
Is this an example of where it's more appropriate providing the app with a central SQL authenticated login, whilst users get read only rights for integrated security?
As Jon mentioned stored procedures would give you the protection over direct table modifications. There are other options too. You can use SQL Server's "Application Role" (via sp_setapprole proc). This enables you to continue to use a separate ID for everyone but only at application connection time (through the front-end) are the user's rights elevated.
A major downside to using a shared ID is you lose track of who is submitting SQL to the server though if they're all internal you can get to the machine name.
Something else is concerning though. It sounds as if your users can connect to the database and run queries at will. You run a major risk of downtime in the application due to user behavior in the directly connected SQL sessions. If you can pull it off you may want to try to have a reporting database created that is updated at intervals that your business can tolerate, i.e., daily. HTH
I presume from the way that you've worded your question that your app executes sql statements directly. If you could refactor it so that it executes stored procedures, you could grant exec rights on the procedures and deny direct updating of the tables. This might not be possible though, depending on what your app does.
sql authentication is one option. Stored procedures are another. However, building more granular roles for assigning just the appropriate permissions to just the appropriate user types is where you should really be looking.
Additionally, I would really avoid giving these users direct access to the DB at all. Security reasons aside, it doesn't take much for a user who isn't proficient in SQL to accidentally execute a query that will swamp your database server and create an effective denial of service. Even pros can do this accidentally from time to time.
Instead, give them access to a reporting services or analysis services type solution, or use replication to give them access to a clone of the data. This way your production system is protected.
Personally I would do all application data access through stored procedures. I would set Integrated security to only allow users to run the SP's and not manipulate the data directly.
Advanced access can be given to DB admins to manipulate the data directly when needed.
Group based permissions will provide you with much more flexibility for access rights, and less administrative burden when controlling these with integrated security.
What is the best option for a windows application that uses SQL server authentication? Should I create a single SQL account and manage the users inside the application (using a users table). Or should I create a SQL server account for each user. What is your experience? Thank you!
Depends on whether the username/password for the SQL server would be exposed to the user, and whether that would be a problem. Generally for internal apps (in smaller organisations), one would trust the users not too log in directly to the sql server. If you have a middleware layer (ie webservices) the password can be hidden from user.
I prefer to use a general login for the DB and manage users in the application. Even if you do create a login to sql for each application user, they could still connect directly, so why not just use a generic sql login that is easier to manage. This is of course assuming all users have the same accesses.
One good practice, if the users potentially can get direct access to the db, would be to grant access only through Stored Procedures and not directly to tables, so that only certain actions can be performed. Steer away from writing business logic or security checks (except basic ones) within the stored procs.
One way I would solve your problem is to write some webservices that check security and does your CRUD (via datasets, etc), but again it depends on the app and environment.
In summary if you have a middle layer or all users have the same access manage the user within the application and use a single user login. Otherwise use a login per user or role.
One option that I have used in the past is to use the ASP.NET Membership Provider. It makes authentication a breeze to use. The only drawback that I saw was that it added a bunch of tables to your database.
The code for using it is very straight-forward.
Here's a blog post about using this in a Windows app. http://msmvps.com/blogs/theproblemsolver/archive/2006/01/12/80905.aspx Here's another article with more details. http://www.c-sharpcorner.com/UploadFile/jmcfet/Provider-basedASP.NET10162006104542AM/Provider-basedASP.NET.aspx
Here's another article that talks about using it with Windows applications: http://www.theproblemsolver.nl/usingthemembershipproviderinwinforms.htm
Google for "ASP.NET 2.0 Membership Provider", and you will get plenty of hits.
What about having SQL accounts based on the level of permissions needed for the task. For example you could have a read only account just used for reporting if your system has a lot of reporting. You would also need an account what has write access for people to change their passwords and other user admin tasks.
If you have situations where certain users are only going to have access to certain data I would have separate accounts for that data. The problem with using 1 account is you are saying that there is no SQL injection anywhere in your application. That is something everyone would strive for but sometimes perfect security is not possible, hence the multi-pronged approach.