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
Related
PROBLEM:
We have multiple ASP.net websites & WCF services. Each of the service stores the SQL server passwords in its own config file. However as part of the annual review process the passwords are required to be updated. This adds pain for the team as there are around 15+ code bases which require config update, build & deployment.
PROBABLE SOLUTION:
We are looking to store passwords in encrypted format for all the applications in a single configuration file which would help us to change the passwords by modifying a single config file. This would save a lot of dev, build & testing efforts.
QUESTION:
Is it good practice to store passwords for all the apps in a single config file? In other words what are the pros n cons of this approach. If not is there any other way suggested to address the problem?
I'm just putting together an internal data system for a client, which is ASP.NET VB, backed by an SQL database, on an in-house IIS7.5 dedicated server.
I want to store certain global settings, such as the age limit for news articles, admin contacts etc, in a file NOT within the database (i.e. to avoid unnecessary database query's)
Where would the best place to store this be? global.asax? app.config? or a custom XML file? how would i import these at runtime? (probably to session variables)
ETA:
Also - the settings must be editable from within the site, i.e. an admin section i'm yet to build
If you need these settings to be editable, then the simplest place to store them would be in a database table. You're already building a layer to get in and out with CRUD operations, so adding this little extra won't hamper you. This will also help you keep your web.config clean and your supporting libraries will not need an extra app.config built into them.
Resource files and embedded app.config files are not editable so those preferred methods don't meet your requirements. You don't want people accessing the web.config directly (even through an interface) because changes to the web.config cause the application pool to recycle. A custom XML file would work, but you would have to build a separate parsing engine to get in and out of it. While this is simple, it would be unnecessary since you're already building an access interface for the rest of your database.
If you're really hating yourself though, you could combine the two into a custom xml file stored in the database as an XElement.
Thanks for your suggestions.
I decided the easiest method, given that the details may only need altering a couple of times a year, was to set session variables in global.asax
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.
Disclaimer, I am technical support and sysadmin for my company, not a developer. I'm not after the specifics, simply an idea if what I'd like to acheive is possible or not.
We host hundreds of instances of our in-house classic ASP legacy ecommerce software application and due to countless customisations by clients and ourselves, version management is nightmarish, custom code can't be managed and we've given up releasing new features and mass deploying bug fixes due to the inability to track who needs what patches where.
Parellel to this question I am making management scripts to better automate this though.
What however I'd really like to do is using the miniumum possible effort, port the application code (not the database) to a single code base. Questions I have:
Can ASP relatively effeciently handle connecting to different databases depending on the host header being called? I plan some basic extension to the routine, get hostheader
lookup up db credentials in metadb, set application connection string accordingly logic.
The application writes a few files to the webserver from the database for caching purposes, I'd like to handle this by emulating this behaviour by writing it to something like /masterapp/customer1/specificfile.htm then changing the references to /specificfile.htm in the code to more like /masterapp/shop name/specificfile.htm. Obviously the routines that write specificfile.htm would write to the new location accordingly. Does this seem reasonable?
Other webserver-bound store specific contents like images and csv files I need to keep working without URLs changing ideally, can ASP employ logic to redirect get requests for /images/example.jpg to either /masterapp/shop name/images/example.jpg or /shopname/images/example.jpg depending again on host header? Or could that be done via isapirewrite? (which we already use)
I think these are the biggest challenges. I don't need a complete project plan of how to implement each of these things, I just want to know if it's possible. If the answer is 'yes' I should be able to sell my bosses on the development due to saving support time and our in-house developers could hopefully manage this.
This should be possible and I have achieved similar outcomes with code developed that way from the start. As you are retrofitting this in it's going to be a lot harder, but that's separate to your actual question.
To answer your actual points:
Presumably your DB connection string is already in a application variable or settings file? If so, you just need some logic in your global.asa Session_OnStart that reads the host header and selects the appropriate DB string. This could be hard coded or you could have a "control" DB that stores sites, their DB strings file paths etc and pulls the details into the session object.
This is related to the above, pull your cache storage locations from the DB, or have a "directory name friendly" base name for each site, so you can have "/masterapp/" & Session("strSiteBaseName") & "/cache/somefile.htm"
If you're on IIS7 then you can use the URL rewrite module to handle this, if you're on IIS6 there are 3rd party tools you can get to do URL rewriting for you. Again I have done this so can vouch for it working. If you want to get really clever, you can have your master app create the rewrite files for you and "touch" web.config to get them loaded into IIS.
One "gotcha" you'll have with host headers is remember to handle www and no-www records!
You mentioned custom code as well for each site, I haven't done this in production but have tested outside an app and you can rewrite functions after they've already been declared. You can't have includes with variable names, but you can load in a text file and execute it, so there is a way to have custom functions, or changed core functions specific to an individual instance of your over-arching app.
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.