Weak authentication increases the identity spoofing threat. If a user's logon credentials fall into the wrong hands, an attacker can spoof the user's identity and gain access to the application. The attacker shares all of the user's privileges in the application. Credentials must be protected as they are passed over the network and while they are persistent, for example, in the application's user store. The authentication cookie that represents an authenticated identity to the application after the initial logon must also be protected to mitigate the risk of session hijacking and cookie replay attacks.
Forms Authentication
The threat of session hijacking and cookie replay attacks is particularly significant for applications that use Forms authentication. You must take particular care when querying the database using the user-supplied credentials to ensure that you are not vulnerable to SQL injection. Additionally, to prevent identity spoofing, you should make sure that the user store is secure and that strong passwords are enforced.
The following fragment shows a "secure" Forms authentication configuration in
Web.config:
<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="true" > Sliding session lifetime
</forms>
In your site design, make sure that secure pages that require authenticated access are placed in a subdirectory that is separate from the anonymously accessible pages.
Note: If you are using Server.Transfer in your application to transfer from an anonymous page to a secure page, .NET Framework version 1.1 or earlier bypasses authentication checks, so code that uses Server.Transfer should be verified to ensure that it does not transfer to a secure directory.
To ensure that SSL is used to protect the logon credentials that are posted from the login form, and that the authentication cookie passed on subsequent requests to restricted pages, configure the secure folders in IIS to require SSL. This sets the AccessSSL=true attribute for the folder in the IIS metabase. Requests for pages in the secured folders will only be successful if https is used on the request URL.
To allow anonymous access to public pages, use the following <authorization> element
<system.web>
<! -- The virtual directory root folder contains general pages. Unauthenticated users can view them and they do not need to be secured with SSL. -->
<authorization>
<allow users="*" />
</authorization>
</system.web>
Use the following <authorization> element inside a <location> element in Web.config to deny access to unauthenticated users and force a redirect to the login page that is specified on the <forms> element:
<! -- The restricted folder is for authenticated and SSL access only. -->
<location path="Secure" >
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</location>
To prevent session hijacking and cookie replay attacks, secure the cookie by making sure that it is only passed over SSL connections using the HTTPS protocol. For additional risk mitigation, encrypt the cookie before sending it to the client and limit the period for which the cookie is valid. To secure the authentication cookie:
Cookies support a "secure" property that determines whether or not browsers should send the cookie back to the server. With the secure property set, the cookie is sent by the browser only to a secure page that is requested using an HTTPS URL.
If you are using .NET Framework version 1.0, set the secure property manually in the Application_EndRequest event handler in Global.asax using the following code:
protected void Application_EndRequest(Object sender, EventArgs e)
{
string authCookie = FormsAuthentication.FormsCookieName;
foreach (string sCookie in Response.Cookies)
{
if (sCookie.Equals(authCookie))
{
// Set the cookie to be secure. Browsers will send the cookie
// only to pages requested with https
Response.Cookies[sCookie].Secure = true;
}
}
}
Encrypt the cookie contents even if you are using SSL. This prevents an attacker from viewing or modifying the cookie if he or she manages to steal it through a XSS exploit. In this event, the attacker can still use the cookie to gain access to your application. The best way to mitigate this risk is to implement the appropriate countermeasures to prevent XSS attacks, and limit the cookie lifetime as described in the next recommendation.
Limit the cookie lifetime to reduce the time window in which an attacker can use a captured cookie to gain spoofed access to your application.
Consider setting slidingExpiration="false" on the <forms> element to fix the cookie expiration, rather than resetting the expiration period after each Web request. This is particularly important if you are not using SSL to protect the cookie.
Do not persist authentication cookies because they are stored in the user's profile and can be stolen if an attacker gets physical access to the user's computer.
Keep personalization cookies that contain user-specific preferences and non-sensitive data separate from authentication cookies. A stolen personalization cookie might not represent a security threat, whereas an attacker can use a stolen authentication cookie to gain access to your application.
Use unique name and path attribute values on the <forms> element. By ensuring unique names, you prevent possible problems that can occur when hosting multiple applications on the same server. For example, if you don't use distinct names, it is possible for a user who is authenticated in one application to make a request to another application without being redirected to that application's logon page.
Navigating between the public and restricted areas of your site (that is, between HTTP and HTTPS pages) is an issue because a redirect always uses the protocol (HTTPS or HTTP) of the current page, not the target page.
Once a user logs on and browses pages in a directory that is secured with SSL, relative links such as "..\publicpage.aspx" or redirects to HTTP pages result in the pages being served using the https protocol, which incurs an unnecessary performance overhead. To avoid this, use absolute links such as http://servername /appname/publicpage.aspx when redirecting from an HTTPS page to an HTTP page.
Similarly, when you redirect to a secure page (for example, the login page) from a public area of your site, you must use an absolute HTTPS path, such as https://servername/appname/secure/login.aspx, rather than a relative path, such as restricted/login.aspx. For example, if your Web page provides a logon button, use the following code to redirect to the secure login page.
private void btnLogon_Click( object sender, System.EventArgs e )
{
// Form an absolute path using the server name and v-dir name
string serverName = HttpUtility.UrlEncode(Request.ServerVariables["SERVER_NAME"]);
string vdirName = Request.ApplicationPath;
Response.Redirect("https://" + serverName + vdirName +"/Restricted/Login.aspx");
}
Identity spoofing is one of the most common authentication-related threats to your application. Identity spoofing occurs when an attacker gains access to the application under the guise of another user. One way to do this is to hijack the session cookie, but if you have secured the authentication cookie as described earlier, the risk is significantly reduced. In addition, you must build secure credential management and a secure user store to mitigate the risk posed by brute force password attacks, dictionary attacks, and SQL injection attacks.
The following recommendations help you reduce risk:
If your user store is SQL Server, store one-way password digests (hash values) with an added random salt value. The added salt value mitigates the risk of brute force password cracking attempts, for example, dictionary attacks. The digest approach means you never actually store passwords. Instead, you retrieve the password from the user and validate it by recalculating the digest and comparing it with the stored value.
Use regular expressions to ensure that user passwords conform to strong password guidelines. The following regular expression can be used to ensure that passwords are between 8 and 10 characters in length and contain a mixture of uppercase, lowercase, numeric, and special characters. This further mitigates the dictionary attack risk.
Private bool IsStrongPassword(string password)
{
return Regex.IsMatch(password, @"^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,10}$");
}
Forms authentication is especially prone to vulnerabilities that lead to SQL injection attacks because of the way that the user-supplied logon credentials are used to query the database.
It is very important to know some of the basic security points while writing ADO.NET programs.
One of the key points of security is "never ever trust user inputs". You must validate the user's data properly before process. The hacker always tries to crash your application through malicious inputs (especially dynamic SQL statements). As a developer you must take care of all vulnerable inputs pass through SQL statements
For example, Lets say you are trying to search customer details by taking the customer name as input and you are building dynamic SQL to fetch the details from SQL Server. If you do not validate the user's input and directly process it, it can cause a heavy damage to your application. Assume the user (smart user) passes the customer name as '1; DROP TABLE Cust ;--.
The code snippet will be as below:
string strQuery = "SELECT * from Cust WHERE custName="+txtCustName.Text;
SqlCommand cmd = new SqlCommand( strQuery, conn);
conn.Open();
SqlDataReader myReader = cmd.ExecuteReader();
myReader.Close();
conn.Close();
The solution to the above problem is to validate such inputs against the length data type, and permissible values before executing the query.
The next point is to use parameterized queries or stored procedures. This is a convenient way to safeguard your application against SQL injection attacks, make sure your stored procedures or methods accept only values not SQL statements with a recommendation to validate the user inputs as explained in above point before execution.
Use Regex Class to validate user input for a particular format (pattern).
For example to validate the input value ‘should have 5 character alphanumeric string'.
public void CheckString(string inputValue)
{
Regex rg = new Regex("^[A-Za-z0-9]{5}$");
return rg.IsMatch(inputValue)
}
One of the way a hacker can reach your database or data source through system generated exceptions. The most keep point for everyone is do not display complete system exception information to the user, display only required exception information to client, suggest to implement exception wrapping or replace to display custom exception by hiding the actual database exception.
To Summarize, mitigate the risk in following ways:
-
Thoroughly validate the supplied credentials. Use regular expressions to make sure they do not include SQL characters.
-
Use parameterized stored procedures to access the user store database.
-
Use a login to the database that is restricted and least privileged