Redacting ASP.net web.config File Contents - asp.net

Other than database connection strings, by default are there any sensitive values populated in web.config by Visual Studio 2008? What are PublicKeyToken values are these sensitive values? Would it be bad security practice to publish web.config files with connection strings redacted?

PublicKeyToken are not sensitive.
As to redacting connection strings, who are you afraid of? Who's going to get hold of your web.config?

Public key tokens are used in association with private key tokens to sign .NET assemblies. The public key tokens are not sensitive. As for connection strings, it is common practice to encrypt the connection string and keep them in the web.config.

Related

Using connection string login and not Application Pool Identity

The Question:
How do I get my Web Application to use my connection string login and not the Application Pool Identity?
The Background:
I have started up a .net mvc project and currently use Arvixe for hosting. I made a simple page using a form to communicate with the SQL database. Here is the site.
Just type anything into the text boxes and hit the button. If the communication is successful, it should just return a message.
The error:
Cannot open database "jfphotography" requested by the login. The login failed.
Login failed for user 'SEAWEED\photosbyjoefor_web6'.
My database user is jfphoto_dbadmin. I have tried making it photosbyjoefor_web6, but with no luck. No where in my code do I use, or set anything to, photosbyjoefor_web6. I have tried using photosbyjoefor_web6 in my connection string.
My connection string is correct, and I have been chatting with support for a week now. We believe that the application is using the Application Pool identity, and, using basic services, I am not allowed/Arvixe will not make any custom Application Pool Identities (which makes sense for shared hosting). Unfortunately, I do not want to be paying 40 bucks a month for their private hosting to be able to edit the Application Pools.
My project is using a Code-First approach, data service layers, context layer, all the fun stuff. I have never encountered this type of error before, and I am unsure of how to approach it. I really do not want to re-build my project in a different manner, but if I have to so-be-it.
Connection string:
add name="PhotographyContext" connectionString="Data Source=seaweed.arvixe.com;Initial Catalog=jfphotography;Integrated Security=True;user id=jfphoto_dbadmin;password=**" providerName="System.Data.SqlClient"

Database mirroring with sql server does not work with my asp.net application using EF

I have database mirroring setup to work with the production database for my asp.net application. When the system fails over to the mirrored database, the application crashes because the connection string is invalid.
If the failover is dependent on a connection string, what kinds of changes do I need to make to my application in order to ensure that it can fail over without my manually changing the connection string?
Do I put exception handling behavior around the EF code where it automatically changes its connection string?
Depending on the type of failover you have set up, I believe there is a connection string property that you can specify the failover DB.
Data Source=myServerAddress;Failover Partner=myMirrorServerAddress;Initial Catalog=myDataBase;Integrated Security=True;
From here: http://www.connectionstrings.com/sql-server-2008

User Input Security .net

I have clientside user-settings manager. the settings are saved through a webservice. I´m serializing them into json. Since the json can be manipulated before sending, I want to validate it on server then.
What are the best practices, what have i to look for?
Validating before deserialization? What kind of malicious input can the user use? Can he manipulate the json so that it harms me somehow on deserialization using default asp net javascript deserialization?
var userinput = { param1 : "test", categories : ["2312", "4324", "2122"] }
this one is sent to the server, serialized.
Deserialized on server into an object graph.
public class usersettings
public property param1 as string
public property categories as string()
end class
param1 is regex checked, maybe only letters and digits, start with letter, maximum 10 signs, for example.
categories must be distinct, not more than 10...
the usersettingsclass is a linq to sql genereted object, that can be directly pushed to the sqlserver.
this is all a very simple sample. in the userinput can be anything.
Are these settings security sensitive? What happens if the user messes with them?
If the only thing that happens is you can an exception, then don't bother.
If these settings can somehow compromise security, then they shouldn't be client side unless they're encrypted by the server before they're sent down to the client. In other words, they're "on the client" for scalability reasons only, not because they're manipulated in any way by the client.
If these settings are security sensitive, and they must be modifiable by the client, they you have an untenable situation. If javascript can modify them, so can the user.
Lastly, if all your'e worried about is that the client somehow manipulates the json data so that it causes a deserialization exception, you should research if there are any vulnerabilities in your json library. If not, don't worry about it until they're are.
Since you mentioned you're using built-in ASP.NET libraries, I can say that I'm unaware of any known vulernability in these libs.

ASP.NET Impersonation by Role

I modified the ASP.NET login control to also allow specifying UserRole ('Employee' or 'Volunteer'). Users are authenticated via a call to a webservice written by our client, which accepts username/password/role and returns true or false.
If role is 'Employee' it represents an active directory user. The application should impersonate the user with the given username/password.
If role is 'Volunteer' the application should run under a set Windows account whose username/password are known in advance (i.e. hard-coded in web.config file).
The server runs on Windows Server 2003. I am confused by the myriad of configuration choices and trying to understand my options;
Is it possible to have multiple scenarios as described?
Should I specify the impersonation programmatically or can it be done through the config file? If so, is it required to use LogonUser or WindowsIdentity?
What config file setup should I use? (i.e. Forms authentication, impersonate=true, etc..)
Thank you in advance.
Because the decision about which identity to impersonate is based on run-time data, you'll likely have to deal with impersonation programmatically.
I use a combination of interop and WindowsIdentity to handle impersonation. The steps I follow are:
Log on using the interop LogonUserA(), which fills a handle to an IntPtr (token).
Duplicate the token with the interop DuplicateToken().
Create a new windows identity, a la: var identity = new WindowsIdentity(tokenDuplicate);.
Create an impersonation context via: var context = identity.Impersonate();
Close both tokens with the interop CloseHandle()
When finished impersonating, undo the impersonation context via: context.Undo();
I keep a disposable class around to handle the details. Steps 1-5 occur in a constructor, and step 6 occurs in the dispose routine. This helps ensure that I properly revert even in the face of an exception.
With this approach, since you are passing credentials via a service method, the web.config authentication scheme is not entirely forced. If, however, you are using integrated Windows auth, you could programmatically impersonate the current user from HttpContext.Current.User.Identity.Impersonate(), without passing credentials in a service method.
On an aside, and you may already know, PInvoke.net is a valuable resource for configuring signatures for interop methods.

Encrypting connection string in classic asp

Is it possible to store encrypted connection string so it can be used from server-side vbscript?
Was there an equivalent of web.config in 'the good old days'?
As I dust off the ol' memory banks...
I recall that in classic ASP systems, we would put the connection string (and most other config settings) in the Windows registry, in a custom registry key for the web app. We'd use a COM DLL to read the settings.
You can encrypt the connection string that is stored in the registry, but you will have to roll your own encryption/decryption.
So the answer is yes, it is definitely possible, but there is no easy tooling built into the framework to encrypt/decrypt on the fly, you have to do it yourself.
.Net has all the encryption and decryption code built in so the easiest way to encrypt the string is to use the .Net encryption/decryption functions. Create a .Net component that does the decription and a COM callable wrapper for it which should register it. Then call it from your ASP page.

Resources