I have created an SQL database file in Visual Studio for my ASP.NET MVC 3 project. How do i password protect my SQL database file?
Hackers can't get access to the file itself, if your host has any brains whatsoever.
And even if they could, they'd need some way to shut down SQL Server so they could obtain the file directly.
What you need to concern yourself with is:
Setting up a very strong password for your web application user,
giving the web user extremely limited rights (principle of least
privilege),
ensuring that the host places the database on a separate
server that is protected from the outside world, and
making sure your
app isn't lazy about preventing SQL injection (e.g. use parameterized
statements).
Related
I am an Oracle guy who suddenly got SQL Server and SSIS dropped in his lap, so I am probably not using the terminology in the correct manner, but here goes:
There is a SSIS package that pulls data from the Oracle database into our SQL Server 2008 R2 warehouse. If I open this package in SSIS Visual Studio 2008, I get prompted for a password:
The sensitive data in the package 'MyRefresh.dtsx' is encrypted with a password.
for the package itself. I enter the password. I run the package. Works great.
The previous guy had loaded this package into SQL Server with a job to run at 1am every day and it worked great there too.
Recently, there were some database changes. The package, of course, stopped working. I was able to fix it, and, again, it runs great if run through SSIS Visual Studio 2008. However, when I loaded it into SQL Server, and the job runs, it fails with:
0xC001405F Failed to decrypt an encrypted XML node because the password was not specified or not correct.
Where/how to I specify the password so the job can run?
Late answer, but might be helpful to other users/thread visitors
In short, to load the package to SQL Server it must be exported with new credentials specified, and then imported back into specified folder.
Here is the article I found on setting the SSIS package encryption manually in SSMS, that provides a quick tutorial on how to Import/Export an encrypted package.
Please note that the Protection level option regards sensitive data, in one case, or all the data included in particular package in other. Data that is considered sensitive is set by default in Integration Services: variables previously marked as delicate, non-changeable XML tags, which are controlled by the SSIS service, and password, which can be considered sensitive if the ‘Encrypt all data with password’ is chosen.
Package protection levels:
Do not save sensitive data: if sensitive data exists, it will not be included after the exporting of the new package, remaining unavailable;
Encrypt sensitive data with user key: sensitive data will be encrypted with current user credentials, and package still can be used on local server. Which data will be considered as sensitive, depends on the creator/owner of the package;
Encrypt sensitive data with password: with this level, a password must be provided – this kind of encryption is desirable, if user want to keep only sensitive data private.
Encrypt all data with user key: same as the encryption of sensitive data, it can be used on local server, but it regards all the data within the package;
Encrypt all data with password: this level encrypts all data within the package, password is required, and it provides a 100% privacy.
Hope this info is helpful.
If you have the opportunity I suggest you no longer use the EncryptAllWithPassword protection level. Read here for more info about package encryption levels:
http://sqlblog.com/blogs/eric_johnson/archive/2010/01/12/understanding-the-ssis-package-protection-level.aspx
In short the idea of package encryption is to stop people opening up the package XML to extract plain text passwords. But generally this is implemented in a insecure manner which defeats the purpose.
I suggest you use windows authentication throughout instead:
Ensure your Oracle server supports external authentication
Create an externally identified login to Oracle using the SQL Agent windows service account
In your Oracle connection manager, use external authentication (login with user / and no password)
If you have any SQL Server connection managers you need to do the same (in SQL Server this is called windows authentication)
Lastly ensure that all developers are set up with windows authentication in SQL Server and Externally identified authentication in Oracle so they can run the package in BIDS
Now you don't need to encrypt your package anymore (you can use DontSaveSensitive). The authority for all operations are against the SQL Agent service account.
You don't need to remember a package password or an Orace login password any more.
Also for example if you need to rotate the password on your Oracle login, originally you would have to go and change this password in Oracle and in your package. But by using windows authentication this is no longer necessary.
I can give you more info if you are interested.
You can use the /de switch along with the dtexec utility for your password like so:
dtexec /f <filename> /de <password>
I developed an Access 2003 application that is connected to SQL Server.
My problem is that I developed the software on my server, and the application runs on the client network on a different (identical) server.
As a result my executable file (Aka. .ADE) does not open on the client's computer, because of bad SQL Server connection.
My solution so far was to open the application file (.ADP) on the client's computer, changing the connection path from there and then creating there the executable file.
Now my client has only Access runtime environment, so I cannot do such thing.
I wonder if there is a way to determine the connection in an ADE file this way.
(I know I can change it through VBA, but when the connection is initially false, I don't even get to the VBA code stage.)
In the interest of keeping things simple, I'll say you need to set up a testing environment you control that mimics your client's environment. For instance, if they have a sql 2008 server named "SQL1", then you should install sql 2008 express on your machine, and rename your machine to "SQL1" so you can test. You'd also need to copy the schema of their database tables and put that same schema in your own test database, and fill it with test data that is similar to theirs. And you'll want to create duplicate logins as well.
With all that in place, I wouldn't think you'd need to update anything. Just copy the ADE file over to your client when you're done making changes. You could try to code your way though this scenario, but I've been there and done that. Having a test environment that apes your client's takes a lot of headaches out of the equation.
I am developing a win32 windows application with Delphi and MS SQL Server. it works fine in LAN but I am trying to add the support for SQL Server remote connections (= working with a DB that can be accessed with an external IP, as described in this article: http://support.microsoft.com/default.aspx?scid=kb;EN-US;914277).
Basically I have a Table in DB where I keep the DocumentID, the document description and the Document path (like \\FILESERVER\MyApplicationDocuments\45.zip).
Of course \\FILESERVER is a local (LAN) path for the server but not for the client (as I am now trying to add the support for remote connections).
So I need a way to access \\FILESERVER even if of course I cannot see it in LAN.
I found the following T-SQL code snippet that is perfect for the "download trick":
SELECT BulkColumn as MyFile FROM OPENROWSET(BULK '\FILESERVER\MyApplicationDocuments\45.zip' , SINGLE_BLOB) AS X
With the code above I can download a file on the client.
But how to upload it? I need an "Uppload trick" to be able to insert new files, but also to delete or replace existing files.
Can anyone suggest? If a trick is not available could you suggest an alternative? Like an extended stored procedure or calling some .net assembly from the server.
If you have sql 2008, then you can use FILESTREAM, then sql server will automatically throw it out to disk.
If you have sql 2005, I'd consider just moving the data into a varbinary(max) column and deal with it that way (also pretty simple).
If neither of those apply OR you can't shove it into a varbinary column, then I would not use sql server to handle the actual file contents and instead just have a web service which stored the file on the file system or a SAN that the web service can easily access. (same as IMHO)
UPDATE:
One other idea that crossed my mind. If you are using SQL 2005/08 then you can write a CLR Stored procedure in .Net. This could handle transferring the blob data to / from the local file system.
In ideal world I would create simple:
- ASP.NET Web Service
- or .Net Remoting Service (faster than web service)
- or new .Net 4.0 RIA service.
Deploy it to the SQL Server on custom TCP/IP port
This service would listen to the port and client would request the file via the service. The service would get the file via local LAN and communicate with the DB via local OLE DB connection.
I would not use any SQl Server "web service" support - this is security and performance issues.
UPDATE:
Since this is Delphi app - you can do the same using Delphi, even though above solution still valid, but more work to integrate different technologies. Delphi has its own tools to build remote applications
If you are on 2005, you could try to store file in temp blob field of some temp table, and then call stored procedure which should put the file where you want it, and update path field as you want it.
In that stored procedure you must use extended stored procedures (xp_something), which allow access to file system. That means that those should be enabled for sql server.
BTW You are trying to use relational DB as Document database. That will, sooner or later, backfire.
I have SMO code which copies tables from one database to another. It runs fine in a desktop app. The same exact code put in a service, gives an error. The error is really obscure and doesn't hint about permissions.
I was wondering if the SMO objects need any kind of security to be used. Security context? Windows credentials.. etc? I am not talking about SQL Server security but security surrounding the use of the SMO methods.
You need full trust. You may have problems running this on certain hosted ASP.NET accounts, apps downloaded from the internet, or from shared drives, where CAS kicks in and gives the code something less than full trust and certain APIs won't be callable.
Are you using integrated security with your connection? If so, make sure the credentials that the service is running under have necessary access.
Make sure your service account (the account that your windows service is running as) has "Act as Part of Operating System" Policy.
I'm wondering what techniques you use to store the database credentials for your application. I'm specifically concerned with java webapps, but I don't think there's any need to limit the questions to that.
things to consider:
Do you use property files,xml configs, other?
Is it bundled into your application(ie in a jar file) or stored seperately on the file system somewhere?
Is the password encrypted? If so, what encryption scheme do you use?
Since you're leaving the question open to platform, I'll add that database credentials for .NET apps are stored in the web.config file. From version 2.0 and above, there is a specific ConnectionStrings section that allows for easier programmatic access to the connection string.
In addition to having IIS automatically block direct requests to the web.config file by default, you can also use an IIS command to encrypt the ConnectionString section of the web.config file. This encryption is machine specific, adding to its strengths, and the .NET runtime will also decrypt the connection string on the fly when you access it, so there is no need for additional coding in your application to work with it.
With Java, database connection pools should be passed into webapps by the container. This is in the standard declarable in WEB-INF/web.xml as resources. The same applies to mail sessions and other external resources that may vary from installation to installation. Look up JNDI for more information on this)
The nice part with this is that the application doesn't care about how to actually connect to anything outside. It will not see any passwords, because the container itself will use them.
In tomcat this is configured either from context files (e.g.) in conf/Catalina/localhost/ , conf/server.xml or - preferably only for dev environments, from the webapps META-INF/context.xml. Other environments have their own configuration location or application.
The encryption of passwords actually depends on the container. Tomcat stores them in plaintext, but the application itself won't see it. I don't know about the mechanics in other environments.
On the Microsoft stack, things can be very nice.
You create a network user account in Active Directory with almost no permissions. You configure IIS to run your webapp as that user. You grant that user read access to the web folders and files on the disk. You configure SQL Server to grant that user read/write permissions on the tables you want. And in the connection string, you instruct the db client to connect as the user account which the webapp is currently being run as.
There is only one actual user account, although it is visible in multiple places. This user account has extremely limited permissions. There is no storing passwords anywhere, even if encrypted. There is no configuration that has to be done in code for this to work (it's all in setting up the permissions).
Depends on the app server.
I usually use JNDI lookups for the data source, so credentials are stored on the app server that handles the connection pool. No need to put anything other than the JNDI name in configuration that way.
Yes, the password is encrypted on WebLogic.
On Tomcat things can be dicey. Connection info is in META-INF/context.xml, which means plain text for the password. I only do that for development, never in production.
In Django, the credentials are in your settings.py configuration file. Since this is not generally kept in your /var/www/ directory tree, it's very safe.
Also, a single Django application may be used (and reused) for many web sites or web servers on the same host, each with it's own distinct settings. So the settings.py configuration is not bundled with the app, but is part of a single deployment of the app.
For asp.net:
I store global parameters such as the connection string and repository paths in the Registry and then a reference to the registry entry in the web.config.
The main reason being that I often find I have to write a stand alone executable to run background tasks and other automated features that require access to the same parameters. Therefore keeping everything that is truly global in one easily accessible place makes for an easier life.
As stated before, no platform specified, and using some ideas from earlier answers:
I am considering a containerised application. You could store the password for the database in a file in the container. The first step of your application would be to establish the database connection, even before listening on web requests. With a successful db connection the file with the credentials is deleted and the variables containing the these, are removed. So when you start serving requests, the only thing that remains, is an open database handle to use from this moment on. If for any reason the database connection is lost, you simply quit and wait to restart the container, the credentials file will be there again.
Which of these are good places to keep your web app’s database credentials?
In a separate file in your source code
In a separate file on your web server host
In your database
None. The database credentials should never be stored