Security Patterns in ASP.NET Forms Authentication

Sudhakarj21
Posted by in Design Pattern & Practices category on for Intermediate level | Views : 12722 red flag

This article helps you to configure ASP.NET Application with better security. Even though ASP.NET comes with default security options there are many other options which requires configuration from our end.
Introduction

Weak authentication increases the risk of loosing sensitive information like SSID, Bank Account Numbers and author personal identity details. Failing to protect authentication tickets is a common vulnerability that can lead to unauthorized spoofing and impersonation, session hijacking, and elevation of privilege. This document will help you to know the available patterns that can be use to solve these issues.

Most of the ASP.NET internet applications uses Forms Authentication and we are going to discuss about the best practices in Forms Authentication which can help Developers and Designers to make the application Stable and avoid all risks under vulnerabilities.

Overview

Forms authentication uses cookies or URL to store sate of the session user identity. Below are some of the issues with this scenario.

1. Cookie is on client system. So any one who can access the client system can see this cookie

2.   Cookie is transferred through wire and if the site is http site the data can be seen by the in between blocks like proxy servers

3.   URL hold the details in cookie less mode but still it is not strong enough as the same URL can be used by the hackers

The authentication ticket is generated when the user first logs on and it is subsequently used to represent the authenticated user. It contains a user identifier and often a set of roles to which the user belongs. The browser passes the authentication ticket on all subsequent requests that are part of the same session to the Web server. Along with the user identity store, you must protect this ticket to prevent compromise of your authentication mechanism

Failing to properly protect forms authentication is a common vulnerability that can lead to the following

1.   Elevation of privileges

An attacker could elevate privileges within your application by updating the user name or the list of roles contained in the ticket, prior to posting it back to the server. An attacker who can upload malicious code to your application, perhaps in a new ASPX page, can also successfully create and modify the forms authentication tickets

2.   Session hijacking

An attacker could capture another user's authentication ticket and use it to access your application. There are a number of ways that this could happen:

                  i.    As a result of a cross-site scripting vulnerability

                  ii.    If the transport is not being protected using a security mechanism such as Secure Sockets Layer (SSL).

                   iii.    If the ticket is stored in the browser cache

3.   Session usage after sign-out

Even after the user has logged out of the application and the developer has called FormsAuthentication.SignOut, the authentication ticket remains valid until its time-to-live (TTL) expires, so it can be used by an attacker to impersonate another user

4.   Eavesdropping

An attacker could look inside a forms authentication ticket to obtain any sensitive information it contains and use this information to compromise your application

5.   Compromise of the user identity store

An attacker with access to the user identity store may obtain access to user names and passwords, either directly from the data store or by using a SQL injection attack

Configuration

1.   Partition your web site into role levels like

a.    webApp/Secure --- Holds security related page

b.    webApp/Admin  --- Holds administrator role level page

 

Use URL level authorization

 <location path="Secure" ><system.web><authorization>

<deny users="?" />

</authorization></system.web>

</location>

 

2.   Validate for Strong Password and Enforce Password Complexity Rules

a.    ^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,10}$

3.   Perform Effective Data Validation

4.   Prefer SSL

5.   Use aggressive time outs. So that the cookie will expire in less time

6.   Don’t persist authentication cookies

7.   Keep authentication and personalization cookies separate

8.   Don’t use Server.Transfer. In .NET 1.1 this will by pass the security module. Use Absolute URLs for Navigation.

9.   Encrypt Cookie

a.    Use an HMAC to make the ticket tamper proof

b.   Use encryption to turn the ticket contents into unintelligible cipher text. This ensures that the data stored in the ticket, such as user names, cannot be viewed on the client or between the browser and server if the ticket is sent in a cookie

c.    To ensure that forms authentication tickets are encrypted and protected against tampering, set the protection attribute of the <forms> element to All

d.   <machineKey> The validation attribute specifies the hashing algorithm used by the HMAC algorithm used to tamper proof the forms authentication ticket

e.    <machineKey> The AutoGenerate setting instructs ASP.NET to generate a random key. The IsolateApps modifier causes ASP.NET to generate a unique key for each application on your server by using the application ID of each application

f.     Finally the <machineKey> element looks like this with the validation keys

                   i.    <machineKey validation=”SHA1” validationKey=”AutoGenerate,IsolateApps”/>

g.   For Encryption set decryption attribute of the <machineKey> element to specify the encryption algorithm

                        i.    <machineKey decryption=”Auto”/>

                        ii.    With the default Auto setting, if the value of the decryptionKey attribute is 8 bytes long (16 characters) then Auto defaults to DES. Otherwise, Auto defaults to AES. ASP.NET 2.0 supports AES, 3DES and DES algorithms. You should use AES because it offers larger key sizes (128 bits, 192 bits, 256 bits) than 3DES (56 bits)

                        iii.    <machineKey decryptionKey="AutoGenerate,IsolateApps">

h.   These keys will solve the solution if the application is not in a Web Farm or the same cookie is shared across applications. To solve this issue you need to manually create the keys instead of AutoGenerate option used in the above settings

i.   Finally the machineKey is as

<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="AES" decryption="Auto" />

j.     Web Farm Deployment Considerations. In the web farm the same key should be shared in all servers. Sample setting as below

<system.web>

<machineKey validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D7             AD972A119482D15A4127461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B" decryptionKey="ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F" validation="SHA1" decryption="AES" />

….

….

</system.web>

Settings

<system.web>

<machineKey validation="AES" decryption="AUTO" decryptionKey="AutoGenerate,IsolateApps" validationKey="AutoGenerate,IsolateApps"/>

<authentication>

<forms loginUrl="Restricted\login.aspx" Login page in an SSL protected folder

protection="All" Privacy and integrity

requireSSL="true" Prevents cookie being sent over http

timeout="10" Limited session lifetime

name="AppNameCookie" Unique per-application name

path="/FormsAuth" and path

slidingExpiration="false" > Sliding session lifetime

</forms>

</authentication>

</system.web>

Conclusion

Security is one of main layer in your web application. Don't compromise on security layer as the number of spam attacks goes on increasing.

Page copy protected against web site content infringement by Copyscape

About the Author

Sudhakarj21
Full Name: Sudhakar Kottapalli
Member Level: Bronze
Member Status: Member
Member Since: 10/5/2009 7:05:50 AM
Country:



Login to vote for this post.

Comments or Responses

Login to post response

Comment using Facebook(Author doesn't get notification)