We're migrating one of our sites to ASP.Net. We do not want to use integrated security, which uses the windows account to connect to sql server (not going to get into why, its just out of the question). We created a username and password to connect to SQL Server, and would like to use that username and password, however, we also do not want other developers to see this information (easily read from the web.config).... I know it can be encrypted, but it can just as easily be decrypted by the developers - plus encryption has a performance hit.
Is there any solution to this problem?
here's a good tutorial on Encrypting Configuration Information in ASP.NET 2.0 Applications
Just don't give the other developers the key
Alternatively, you can lock down the authentication for SQL via installed certificates. This way you are setting security based on the client not the user. http://msdn.microsoft.com/en-us/library/ff649255.aspx
Our standard practice is to have one "Developer Login" used in the development database that has limited access and have a different username/password for the production box. Developers do not have access to the production box, only the lead developers, and then the production web.config is copied over via the deployment script.
Do the developers need access to the web.config file? If so, I think you may be out of luck. If not, meaning that they do not ever need to change the web.config file, change the permissions on it so that only admins and the asp.net process can read the file.
In my experience, it tends to be difficult to hide that kind of thing from your internal devs. Even encrypting the config infroamtion in the webconfig would still show if your developers just stepped through the code...
I would guess that, if you HAD to do this, you could create a private constant string in the code for your DB string and then use Dotfuscator or similar on the compiled application. Obviously, the source code itself would also have to be encrypted or your developers otherwise prevented from accessing it.
You can't really protect the password from developers - besides, what sense does it make?
What you can do is to have separate development server to which developers have access and production environment, to which they don't.
Don't developers ever need to log on directly to database to run some tests or something? if they do, it would make sense to do the test using the same account that is used by the application, otherwise the test results may not reflect reality.
prompt for the password, when you connect for the first time and track the passowrd in session. Now only you'll be able to connect the database from anywhere. Redirect all those to application-unavailable page to rest of the users that they don't have the password.
Related
We have ColdFusion and Active Directory running within the same domain. I'm trying to write a script that ColdFusion can run to get the sizes of client directories within the file system. However, each directory requires different windows authentication.
ColdFusion <cfdirectory> doesn't have a means to impersonate the user for each directory. Using the JavaIO is also apparently not useful as Java apparently doesn't know anything about the Windows authentication.
I found a suggestion for using APS.NET to write a COM or .NET component, but the article didn't go any further. I have since googled my heart out and not found anything more useful.
If anyone has any information or assistance to offer, you can't imagine my gratitude.
ColdFusion will, by default, run as the Local System account. This account will not have access to the network.
I would suggest running the ColdFusion service with a domain account that has read access to the client directories and you should then be able to use cfdirectory.
You may find this blogpost helpful.
It seems the problem is that each directory in question requires a different set of user permissions. So he's right I think. CF can't "impersonate" each user - though I'm not sure that I know of a system that can do that. would you have to store separate permissions for each directory? Ask for a password for each one?
I don't think you can "impersonate" an AD account without creating appropriate tokens using the key infrastructure right? So that means you have to store username and passwords to "authenticate" with. I think storing and using such "impersonate" information would certainly negates any security enhancements you hoped to gain from using a different user for each directory.
Architecturally you are better off running CF as an AD user with "read" permissions to the directories in question - then you can access the size information you are looking for but would still not be able to modify the files within the directory. That's my take.
We decided to build an ASP.net application which will access the individual client directories using in-built windows authentication to return file sizes and other data and dump them into a database. We will use windows scheduler to schedule the running of this application. ColdFUsion will be used merely to manipulate the data into reports.
I seen some asp.net developers encrypt ConnectionStrings that was included in separate config file. Why they did that ? I know that config files are unreadable from the client side/browser! Is it possible to access to this kind of files ?
You can't rule out that the web box is compromised.
Also, you don't want the web admins to know passwords to databases.
You need to remember that config files cannot be obtained by the browser just because .config extension is in the list of restrictions in IIS metadata. It may be possible to get them from the server in other way or some misconfiguration problem may allow them to be downloaded.
They can be accessed by maintenance personnel, backup operators or others that have access to the disk without going through the website. That´s one example.
If you upload your web.config file with custom errors set to "off", any errors produced by your web application will display your code. This could even include lines from your config files and this could include the "ConnectionStrings" making them visible to the public.
To every organization the most important thing to them is their data
This is done where there are multiple developers working on the same
application
Sometimes, new developers are also enrolled in the team. Exposing each & every aspect of your database, system, login name, machine name is never a good approach
There is chance of information leak in production, testing Q/A phase etc.
This comes really handy when there is a code theft within an organization, atleaset your data is safe from an outside intrusion as the connection strings were encrypted
Can you bear the risk if someone has access to your database & perform a table/schema drop or a delete all from your tables?
MSDN: How to secure connection strings when using a datasource
I came across a case study few days early. It is related to a web application architecture.
Here is the scenario,
There is a single web service used by say 1000 web applications. This web service is hosted on a particular server. If web service hosting location is changed, how the other applications come to know about this change ?
Keeping it in web.config doesn't seems to be a feasible solution as we need to modify web.config files for all the applications.
Keeping these settings in a common repository and let all the applications use it for web-service address was came in my mind, but again there is a question of storing this common repository.
I am just curious to know about how this could be achieved with better performance.
Thanks in advance for any kind of suggestions.
do you have full access or control over all those web applications consuming that web service? if so, you could have a script or some custom code which updates all their web.config(s) at once. it seems too much work but in fact in this way you have more control and you could also, eventually, point to the new url only some applications and leave some others on another url.
the idea with the setting in a centralized database gives you faster update propagation which could also be bad in case of errors and then you have all applications referring to the same place and no way to split this. Then you have anyway to connect to a centralized database from all of them and maybe you should add a key to their web.config(s) with the connection string to that database, then, in case that database is not reachable or is down, the web applications will not be able to consume the web service simply because they cannot get the url of it.
I would go for the web config, eventually you could have a settings helper class that abstract the retrieval of that url so the UI or front end does not know from where that url comes from.
anyway, do you plan to change the url of a web service often? wouldn't be better to copy it to a new url but to also keep it available on the current url for a while?
another advantage of web.config approach is that everytime you update and save it the application is restarted while a change in a database might take a while to be detected in case you have some caching mechanism,
hope this helps.
Davide.
I have a website about to go live. I'm wondering what I should be doing about the connectionstring in the web.config. Do I obfuscate it and it so how?
Thanks!
The standard method is to encrypt it. http://ondotnet.com/pub/a/dotnet/2005/02/15/encryptingconnstring.html
However, another good option is to store it in the registry and set the permissions so that only the asp.net runtime can access it.
See this article: http://msdn.microsoft.com/en-us/library/ff649224.aspx and this KB: http://support.microsoft.com/kb/821616
Although I do have to say that using the registry does tend to complicate deployment and using text/staging servers a bit. We did it... ONCE and then went back to encrypting.
You can encrypt the <connectionStrings> section in your web.config - see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI
Here is an example for the same;
http://whatilearnttuday.blogspot.in/2012/02/use-of-configurationproviders-to.html
Since you didn't provide any information about this in your question I will assume you have credentials in your connection string.
From a security perspective you should try to avoid this, use Windows Authentication if possible. Obviously this requires that you have access to an Active Directory environment and all the servers are deployed in it.
If not, it's always better to lock down the web-server instead of trying to make sure that files on disk are secure from tampering by different users.
If even this is not possible then I would follow the approach given by the other replies, encrypting the sensitive content with DPAPI.
You could simply encrypt your entire web.config file:
See the steps here:
http://www.proworks.com/blog/archive/encrypting-your-webconfig/
I'd like to know which are the security risks of running an asp net application with an administrator account.
I might end up doing this and I'd like to be aware of the known security wholes I would have.
I'm connecting to a sql server using sql authentication so excessive privileges to execute queries is out of the list.
I am having trouble coming up with a scenario where this would actually make sense -- you can always delegate specific permissions to a named user to get them the specific admin-style rights they need.
As for the question at hand, direct risk isn't any greater than any other web application inasmuch as a web app is a big honking hole through your firewall. The indirect risk is very, very scary. You are trying to turn the clock back to 2000 when IIS5 was setup to run as local system making every single case of "IIS can be made to run arbitrary commands" into "anyone can own your box over port 80."
If you do have to do this, I'd consider putting firewalls behind the server too. That way, when it does get rooted, you've got some defenses. I'd also use unique accounts, etc.
You should rarely need to run IIS under an administrative account. It's usually a sign of poorly written code. For example, I have seen it done when an app needs to shell out a batch job or executable, and needs to run those files under admin context to work (ie. very poorly coded applications).
You don't want to run any services under admin context. Not your IIS service, and especially not your database service. Any exploit triggered on your system will take on admin privileges, leading to a complete box compromise. Notice that in newer versions of Windows, both client and server, there are much fewer services running as either admin or system. This is due to Microsoft's own learnings that running apps under excessive privileges is a very bad idea.
The risk is completely endless; a single mistake in your code, or an as-yet-undiscovered IIS/ASP.NET security vulnerability and you would be giving potential crackers complete, unfettered access to the server.
Compared to running it under the default account(s), where access would be pretty restricted.
There's really no reason to need to do this anymore, especially with the newer Windows servers, ASP.NET versions and IIS.