I've heard it said many times that the Windows Authentication is preferred over SQL Server authentication when it comes to securing SQL Server, however, this has always struck me as counterintuitive since if a user's Windows Authentication requires them to be able to modify tables, then there's no way to prevent this activity should they log in using SSMS - bypassing the application logic.
I've used server triggers in the past to prevent this but I've also had a couple scenarios where this left us unable to log on to the SQL Server. I also get that many people would argue that, for this reason, all updates to the database should be done via stored procedures - which isn't an option for us since many of our applications are COTS.
How have others handled this? Am I the only one who sees this as a problem?
Related
Before I ask my boss to enable Ad-Hoc queries, I want to know what I'm asking for.
Every once in a while (at least once a year, but not more than once a month), we get an excel sheet that has information that we need to put in the database. I'd like to write a stored procedure that takes the path to the spreadsheet as a parameter and does the necessary processing, but when I try to use OPENROWSET, I get this error:
Ad hoc access to OLE DB provider 'Microsoft.Jet.OLEDB.4.0' has been denied. You must access this provider through a linked server.
I've done some looking, and it seems that I have two choices:
Add a linked server, which is undesirable because it sounds like I would need to put the excel sheet directly on the machine that is running SQL Server. I would like anyone on the team to be able to run this process, but not everyone should necessarily have access to the server machine.
Allow Ad-hoc access to the database. This seems more desirable, but I want to know why Microsoft disables this functionality to begin with before I go asking permission to poke holes in our security.
So, does anyone know what the actual security risk is here, or is it just Microsoft being paranoid?
I have a vb.net windows form application with a database on SQL Server 2008 on the ./SQLEXPRESS instance.
I have created a setup of my project using the link below..
http://msdn.microsoft.com/en-US/library/49b92ztk(v=vs.80).aspx
When a user installs my application, the database will be available for him, and user can just export the SQL Server database.
How can I secure my database so that user shouldn't have a easily available copy of my database?
I thought of creating a new password protected server (as I have created the database in above walkthrough)... while installation of my application on user's pc, other than ./sqlexpress. And a complete copy of database used by my application will not be simply available for user to just export and get a copy of my database.
So could anyone please guide me...
The question is; how far do you want to go to protect your data?
Better protection of your data usually comes at the cost of more development time and likely less user friendliness, for example due to lower performance (encryption is not free). More complex code usually results in more support requests too.
Where the best balance is depends on your business model (if any) and on your user requirements.
Keep in mind that anything you deploy to an end-users machine is in the end vulnerable. If something is valuable enough there will be people trying to steal it.
So, you could argue that the best protection is not to deploy the data at all. You could back your end-user application with a web service and keep the data on your own server, for example in the cloud.
I've found however that you sometimes just need to trust your users. If you build a good product that makes them happy, they have no reason to steal from you. In fact, they are probably glad to pay you.
If you decide that you need to deploy the data and that you need to encrypt it, you should think about why you chose SQL Server.
What database features do you need exactly? Do you need a fullblown database server for that?
Any local admin can gain control over any SQL Server database in seconds so the built-in SQL server authentication will not bring you a lot of benefits.
You could switch to SQLServer CE and keep the database within your application. That would make the database a lot harder to access for a regular user.
If all you're doing is looking up words, you may be better off with a different storage engine like Lucene.
Lucene is actually a search engine, so it's highly optimized for matching words or parts of words.
You can run Lucene inside your .NET application so you don't even need the end-user to install SQL Server. There is a .NET version of Lucene here.
Lucene however doesn't protect your data. There's tooling available that will allow anybody to view and extract the data from the stored index files.
Since Lucene is open source though, you could extend it to support encrypted data storage (see this related question).
When developing an application where users connect with their native database logins, I don't need to care about SQL injection right? The reason being the users can execute any SQL they want anyway. (There are places where admins execute CREATE LOGIN and CREATE USER statements and these have to be dynamically built.) I'm talking about a native Windows application on the LAN.
Well, SQL injection is a possibility to execute SQL, so with the SQL shell access, everything required for "SQL injection" is already authorized. However you still need to care if users run as non administrators, probably being restricted which tables they can access, and your system sends some additional SQL commands while logged in with higher rights (create user, etc). Use prepared statements for such a code.
If you mean that you are building a web application, and using users' database credentials to connect to the database, yes, you do need to worry about SQL injection.
Most databases restrict permissions based on objects - tables, views, stored procedures etc. So, a user logged in as "Bob" might have access to table "sales", but not table "payments".
The database does not restrict access to rows in tables (for instance). So, a user connected as "Bob" who can exploit a SQL injection bug in your code can delete every record in the "sales" table. You probably don't want that.
If user "Bob" also has direct SQL access, they could, of course, simply run that statement at a SQL command line - but usually, web applications are available where direct SQL access is not. Your web app may be put on the intranet to begin with, but you can't guarantee that won't be opened up in the future.
Given how easy it is to prevent SQL injection attacks when you're building the app, and what a pain it is to fix them later on, I see no real reason not to prevent them in the first place.
As a matter of fact, "SQL injection" is a common misconception.
Being unable to properly format their queries, folks invented an "sql injection" thing as an excuse.
While properly formatted query will serve 2 purposes at once:
it will always be syntactically correct, no matter what data sent in.
as a side effect it would be invulnerable to that notorious "SQL injection" thing.
I doubt you want your queries to fail because of some unexpected symbol. So, no matter of some "injection", you have to properly format it. But once formatted, there will be no injection anyway. So, you have to concern about format, not injections.
I also have a feeling that letting users to login with database credentials is not quite a good idea.
There are two AD accounts, admin1 and admin2. Both are logged in to identical machines, both open SQL Server Management Studio and log in as the same SQL user to the same SQL server (using SQL Server Authentication, NOT using Integrated Security), and both run an identical query: "SELECT * FROM View1". However, admin1 receives many results (the correct result set), whereas admin2 receives an empty result set. This happens on every computer in the domain, regardless of windows version, wired/wireless connection, etc.
Why is this happening? Shouldn't SSMS be Windows account agnostic when using SQL Server Authentication? Any help would be appreciated.
The issue I had was a result of Microsoft Dynamics CRM, not SQL Server itself. I was using Filtered views, which return zero results to any user not using Windows authentication. I am not sure how I got the results I mentioned above, but trying again another day, I was never able to get results with SQL authentication, no matter what Windows account I was using. Likewise, I was always able to get results when logged in with Windows authentication.
You can either use the raw tables or hack the underlying view framework by inserting records manually that show the domainname as your SQL Server Authentication login id and granting not the CRMReaderRole but the standard DQL Role. Take a peek at the wonderful fn_FindUserGuid function which looks up the SystemGuid which the views all inner join to. Just fabricate this record and a few others and your good. If you reverse engineer their system you will see there is a way to trick the system.
Its essentially just the SystemUserBase, SystemUserPrincipals, UserSettingsBase.
Obviously this is not Microsoft recommended. ¯(°_°)/¯ But when you need an ODBC connection on a shared server which provides generic reports to many users outside of the wonderful CRM world you need to do this. You will NOT find another way outside of replicating data to another database but of course keep in mind dynamics is wonderfully dynamic and changes often. Good luck syncronizing environments.
In my opinion this system was obviously designed this way to sway users towards Microsoft products. Not saying I wouldn't do the same if I owned Microsoft. When you're forced to hack your forced to hack.
I want to install an application (ASP.Net + SQL server 2005 express) in local network of some small company for demoing it for a period of time, but I also want nobody even sysadmin have no permission on this database and any permission granting wants a secure pass that I have .
I just want my tables structure and relations and functions be hidden and encrypting the data have no advantage
I need to spend more time on this article Database Encryption in SQL Server 2008 Enterprise Edition that i found from this answer is-it-possible-to-password-protect-an-sql-server-database
but
1.I like to be sure and more clear on this because the other answer in this page says :
Yes. you can protect it from everyone
except the administrators of the
server.
2.if this is possible, the db have to be enterprise edition ?
3.is there any other possible solutions and workaround for this?
4.if I install a new instance with my own sa password , can i restrict other instances admins from attaching the mdf to their own ?
thanks in advance
These people can access your server or the SQL Server instance no matter what you do
anyone with physical access to the server
domain admins of the network
anyone with the sa password
a windows group with local admin and/or sa rights (which implies group policy etc)
You have to host your server offsite if you want no-one to get to log onto it.
It is that simple
In SQL Server, you cannot "password-protect" a database - what you can do is limit the permissions a given user or role has in your database.
You can DENY anyone access to your database - but that's a bit odd, since no one will be able to use it....
You can do all sorts of stuff to your database tables and logins - but a sysadmin will always be able to get around those things and get access to the database. As long as the sysadmin can get his hands physically on the server, I don't think there's any way to totally shut them out.
If you don't trust even your sysadmins, you have bigger problems.....
There's several different ways you could solve this problem.
Host it offsite - I think the easiest solution would just be to host it offsite. There's loads of cheap shared hosting out there which you could use.
Lock out the sysadmins from that server. Assuming you have root access and only you use/need that server you could change the root password and any other passwords on the server.
Do what you're currently doing and try to make something secure even when someone who shouldn't have access has root access to the server. This way sounds tricky and insecure even at best.
I have a contribution for (3):
I'm guessing (I might be wrong) you don't actually have sensitive information in your database, you just want to make it unfeasible for someone in the local network to use any of your stuff.
If that's the case, you could just make it harder for them to read your data by encrypting the data in the database and having your (compiled) code decrypt it before using it.
This way, any sysadmin who is just curious about the data or wants to change his hiscore to 13371337 will not want to go through the trouble of decompiling your code and/or cracking your encryption (for the duration of your demo) and your (assumed) problem will be solved.
I have no idea if this helps you at all, I guess I just want to say you might want to take a look at your problem again. Since you can't keep the sysadmins away from your stuff, you may want to take a different approach like making it less useful to them.
As discussed by the various other posters, you can't password protect a database - deny permissions - to the sysadmin. One alternative that hasn't been discussed is hosting it on a Laptop. Since this is a demo, you can host the Database and ASP.Net site on a laptop and hook that up to their Network - after Sysadmin permission of course - and have the clients test the application from your laptop.
This will allow you to protect the database from Sysadmins and provide the added benefit that if you want to allow them to see the database you can let them use your laptop and you will be there watching their actions on your database. This last benefit is something that you can't do easily with a hosted solution.
The above answers point 3. As for point 2, you will need the Enterprise Edition of SQL Server to take advantage of Transparent Data Encryption (TDE) as per the comparison link on MSDN. If you click on the Enterprise Security link at the top it will show a table explaining the different security capabilities of the different SQL Server versions and it shows that TDE is only for the Enterprise Edition.