.NET incorporates this configuration file that is capable of doing a great deal when it comes to security, among other things. For starters, it's the perfect place to store all your appsettings or database connection strings that'll be accessed in your application. Furthermore, everything regarding your application's security can be stored here within its perspective nodes, from allowing specific users and groups access to a particular file location path or multiple location paths to storing account credentials, examine specific HTTP access, and standard Authentication.
A typical web.config configuration file
<configuration>
<appSettings>
<add key="myDataBase" value="User ID=id; _
Password=pw; Data Source=myDS; _
Initial Catalog=myCat; Enlist=false;" />
</appSettings>
<location path="securePage.aspx">
<system.web>
<authentication mode="None | Windows | Forms | Passport"/>
<forms forms="securepage" loginUrl="login.aspx" />
<credentials passwordFormat="Clear | MD5 | SHA1">
<user name="Jimmy" password="hashed Password"/>
</credentials>
</authentication>
<authorization>
<!-- General application authorization -->
<allow verbs="POST" users="Jimmy" roles="Administrators" />
<allow verbs="GET" users="Peter" roles="Debugger Users" />
<!-- URL Authorization -->
<allow users="domain1\user, domain2\group" />
<!--Deny anonymous or All Users-->
<deny users="? | *" />
</authorization>
</system.web>
</location>
<!--For a second secure page-->
<location path="securePage2.aspx">
<!-- Other configuration settings-->
</location>
<configuration>
As seen, the web.config file is capable of many security measures, from public access to Passport authentication. We'll now discuss them in turn:
<authentication mode="None | Passport | Windows | Forms "/>
Impersonation
.NET allows general, public access through impersonation, where IIS uses its own IUSR_computername account process token to control authentication and authorization. As far as strict security is concerned, this is not really it. That is why it best serves all public sites, and is set in the web.config file like so:
<system.web>
<identity impersonate="true" />
</system.web>
The identity key element holding the attribute impersonate, set to true is the equivalent of IIS's Anonymous access, but directly affects your .NET application here more, since it helps overcome any " Access Is Denied " problems with .NET on a public site.
And due to this, your SQL connection string would be this below, providing both your application and SQL Server share the same domain or trusted domains. Otherwise you'll receive the Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error.
"Data Source=myDS; Initial Catalog=myCat; Enlist=false; Trusted_Connection=yes"
For more info on .NET Impersonation, readImplementing Impersonation in an ASP.NET Application.
Default/None (Custom) Authentication (IIS's Anonymous Authentication)
The default setting of no authentication or None mode , is typically for public sites (impersonation). When included for this purpose in your configuration file, does two things, helps performance since no extra runtime processing is needed and could allow customized authentication to take effect, whether application wide via the global.asax or HTTP modules, working with the AuthenticateRequest event.
Passport Authentication
As noticed in the authentication key element above, one such technique, different among the others as I'm sure most have seen is .NET Passport authentication mode . This service offered by Microsoft, is a somewhat of a one-stop shopping methodology, enabling you a unified access across many applications.
Windows Authentication (IIS's Integrated Windows / Digest Authentication)
Next, as aforementioned in the IIS section above, is Windows Mode , the default security method, as it indeed relies on Windows Authentication in IIS for its authentication, prior to .NET gaining control. Furthermore, because of its nature it is best suited for Intranet sites.
In the web.config file, the authentication node is set for ACL Windows authorization, and is also based on the elements contained within the authorization nodes for which users, roles or groups are allowed or denied access, or URL authorization. Additionally, within these nodes you may even specify what type of HTTP action is allowed, using the verbs key, and setting it for either POST, GET, HEAD, or DEBUG.
Here we've set Role-Based Security within the following web.config's <allow> element key setting, and in this instance it'll allow only Admins and Debuggers access, and deny everyone else:
<configuration>
<system.web>
<authentication mode="Windows" />
<authorization>
<allow roles="Administrators, Debugger Users"/>
<deny users="*"/>
</authorization>
</system.web>
</configuration>
Forms Authentication
And finally, there is Forms (Cookie based) Authentication Mode , where your dealing with security based upon criteria captured through a form on your web page. This could be Forms-based (using configuration credentials) or Windows/Role-Based, with account credentials set in place and stored in a database, XML file, text file, or even a remote Web Service, rather than solely in an ACL list. Incidentally, this mode enables good flexibility for creating more personalized sites.
Forms Authentication is your best bet for Internet security-based applications such as an E-Commerce site, since it supports all browsers, is fully customizable, and works well with other security additions such as SSL. Incidentally, cookie size limit with IE5 and higher browsers, has no limit.
Here is an example of Forms-Based Authentication using the FormsAuthentication Class ,
if (FormsAuthentication.Authenticate (userName, userPassword)) {
//Redirect user back to original URL once logged in or do whatever
FormsAuthentication.RedirectFromLoginPage (userName, boolean);
} else {
Response.Redirect ("login.aspx");
}
with the web.config file holding the user's credentials and authorization:
<authentication mode="Forms">
<forms name=".ASPXAUTH" loginUrl="/login.aspx">
<credentials passwordFormat = "SHA1">
<user name="userName" password="encryptedPassword"/>
</credentials>
</forms>
</authentication>
<authorization>
<!--Deny all unauthenticated users-->
<deny users="?"/>
</authorization>
Forms authorization as seen, is controlled via cookies (name attribute) that you name within the forms element key, and the loginUrl or login page to use. This is useful for any pages requiring strict security measures, whereby all unauthorized users get sent to your login page to enter their credentials in a form, and must match the Forms Authentication Credentials before access is granted.
Alternatively, you can utilize the same FormsAuthentication class technique above using a database housing users and roles, as well as utilizing the FormsAuthenticationTicket Class. This method of course has its advantages since a database could store as many credentials as you need. Additionally, if you so choose, you could even store credentials within an XML file, providing you set ACL permissions on its location.
Now, as far as encrypting passwords is concerned, its significance cannot be really stressed enough. It's fortunate however, that it is incredibly easy to do for the above credentials using the (get ready for a long one) FormsAuthentication.HashPasswordForStoringInConfigFile Method. This method uses two parameters, one for the password itself, and the other for the type of hash algorithm you require, SHA1 or MD5:
string encyptedPassword = FormsAuthentication.HashPasswordForStoringInConfigFile(password.Text, "encryptionMethod");
Furthermore, within the web.config file you could add any specific authenticated page and allow certain user's access, based on specific HTTP method and deny access to all all or specific non-authenticated user's. Subsequently, by choosing Forms Authentication as a custom security measure, then bear in mind that Anonymous Authentication should be enabled in IIS.
Read Forms Authentication in .NET's documentation for more info.
Miscellaneous
Now aside from these aforementioned security measures, I'll discuss a few miscellaneous encryption-enabling configuration settings helpful in further securing your application.
If you're concerned about the security of any viewstate data being examined or manipulated in any way, then set enableViewStateMac (MAC stands for message authentication code) property to true, as demonstrated below, and individually within each .aspx page's @Page Directive - EnableViewStateMac="true" as well. This property hash encrypts the viewstate and ensures that it has not been altered in any way. It stores this information in the machine.config file's <machineKey> node element. Luckily, this is already the default in .NET, phew!
Further encryption of any viewstate, or forms authentication cookie data could be physically set within the web.config by adding - <machineKey validation="3DES" /> , .NET's Triple-DES (3DES) encryption or any other encryption method you prefer.
As for sites dealing with file uploading, we both know limits have to be set. Users obviously can't upload to their hearts content, and bog down the server. So setting .NET's HTTP runtime maxRequestLength parameter, for 2 megabytes as demonstrated below, ensures that any larger files are declined.
<system.web>
<pages buffer ="true" enableViewStateMac ="true" />
<machineKey validationKey="autogenerate | value" decryptionKey="autogenerate | value"
validation ="SHA1 | MD5 | 3DES" />
<httpRuntime maxRequestLength ="2048" />
</system.web>
Comments