Asp.net security best practices
To help protect the site from intruders and attackers I have studied and explored Microsoft suggested best practices for security and based on that we should follow the measures listed below.
1. Input Data Validation
i. Do not make ValidateRequest = false in web.config file. Make it false at page level where required.
ii. Validate input for length, range, format an type.
iii. Validate input from different sources like QuesryString, Cookies, HTML controls etc.
iv. Do not rely on client side validation. Server side validation must be done.
v. If you need any file path from any file name Ensure that file paths only refer to files within your application's virtual directory hierarchy if that is appropriate. When checking file names, obtain the full name of the file by using the System.IO.Path.GetFullPath method.
vi. If you use MapPath to map a supplied virtual path to a physical path on the server, use the overloaded Request.MapPath method that accepts a bool parameter so that you can prevent cross-application mapping. The following code example shows this technique. Here is the sample code:
try
{
string mappedPath = Request.MapPath(inputPath.Text,
Request.ApplicationPath, false);
}
catch (HttpException)
{
// Cross-application mapping attempted
}
vii. If you write output that includes user input or data from a shared database or a local file that you do not trust, encode it. Echoing input directly back to the user makes your application vulnerable to cross-site scripting attacks. Encoding the data ensures that it is treated as literal text and not as script. You can use the HttpUtility.HtmlEncode method. Similarly, if you write URLs that might contain unsafe characters because they have been constructed from input data or data from a shared database, use HttpUtilty.UrlEncode to make them safe.
2. Forms Authentication
i. Validate user login information including user names and passwords for type, length, format, and range. Use regular expressions to constrain the input at the server. Do not use login details to dynamically construct SQL statements because this makes your code susceptible to SQL injection. Instead, validate the input and then use parameterized stored procedures.
ii. Do not store user passwords either in plaintext or encrypted format. Instead, store password hashes with salt. By storing your password with hashes and salt, you help prevent an attacker that gains access to your user store from obtaining the user passwords. If you use encryption, you have the added problem of securing the encryption key.
iii. If you must implement your own user stores (We are not still confirm if we can extend asp.net membership to fulfill our requirement. ), store one-way password hashes with salt. Generate the hash from a combination of the password and a random salt value. Use an algorithm such as SHA256. If your credential store is compromised, the salt value helps to slow an attacker who is attempting to perform a dictionary attack. This gives you additional time to detect and react to the compromise.
iv. Enforce Strong Passwords
v. Do Not Persist Authentication Cookies. Here is the sample code to do this:
// Parameter two set to false indicates non-persistent cookie
FormsAuthentication.RedirectFromLoginPage(username.Text, false);
vi. Set the secure property of the authentication cookie to ensure that browsers only send authentication cookies over HTTPS connections. By using SSL, you prevent an attacker from capturing the authentication cookie to gain spoofed access to your application.Set the secure property by using requireSSL="true" on the <forms> element as shown here. Here is the configuration:
<forms loginUrl="Secure\Login.aspx" requireSSL="true" ... />
3. Code Access Security (We will have to do more work to define CAS for OPLM)
i. Consider code access security for partial trust applications.
ii. Choose a trust level that does not exceed your application's requirements.
iii. Create a custom trust policy if your application needs additional permissions.
iv. Use Medium trust in shared hosting environments.
4. Data Access
i. Encrypt your connection strings.
ii. Use Least-Privileged Accounts for Database Access.
iii. When Using SQL Authentication, Use Strong Passwords. A strong password should be at least seven characters in length and contain a combination of alphabetic, numeric, and special characters.
iv. When Constructing SQL Queries, Use Type Safe SQL Parameters.
v. Avoid Dynamic Queries That Accept User Input
5. Exception Management
i. Use Structured Exception Handling
ii. Do Not Reveal Exception Details to the Client
iii. You should also use the <customErrors> section of the Web.config file as shown in the following code example to specify a default error page to display, along with other required error pages for specific HTTP response codes that indicate errors. Here is a sample configuration:
<customErrors mode="On" defaultRedirect="ErrDefault.aspx">
<error statusCode="401" redirect="ErrUnauthorized.aspx" />
<error statusCode="404" redirect="ErrPageNotFound.aspx" />
<error statusCode="500" redirect="ErrServer.htm" />
</customErrors>
iv. Use a Global Error Handler to Catch Unhandled Exceptions in Global.Asax file.
v. Use Microsoft Enterprize Library Exception Handling application block for handling exception.
6. Parameter Manipulation
i. Do Not Make Security Decisions Based on Parameters Accessible on the Client-Side. Do not trust input parameters, especially when they are used to make security decisions at the server. Also, do not use clear text parameters for any form of sensitive data. Instead, store sensitive data on the server in a session store and use a session token to reference the items in the store.
ii. Validate All Input Parameters.
iii. Avoid Storing Sensitive Data in ViewState.
iv. Use Page.ViewStateUserKey to counter one-click attacks. If you authenticate your callers and use ViewState, set the Page.ViewStateUserKey property in the Page_Init event handler to prevent one-click attacks. Here is the sample code:
void Page_Init (object sender, EventArgs e)
{
ViewStateUserKey = Session.SessionID;
}
7. Sensitive Data
i. Avoid plaintext passwords in configuration files.
ii. Avoid using any of the client-side state management options, such as ViewState, cookies, query strings, or hidden form-field variables, to store sensitive data. The data can be tampered with and viewed in clear text. Use server-side state management options, such as a SQL Server database to help protect data exchange.
iii. If your page contains data that is sensitive, such as a password, credit card number, or account status, the page should not be cached.
8. Session Management
i. As so far we do not have any decision to use state server or sql server based session management we are safe here. If we need to switch one of those 2 we will have to explore the security measures for that.
9. Auditing and Logging
i. Use health monitoring to log and audit events.
ii. Instrument for user management events.
iii. Instrument for unusual activity.
iv. Instrument for significant business operations.
v. Consider using an application-specific event source.
vi. Protect audit and log files.
vii. We will use Microsoft Enterprise Library Instrumentation Application Block for this.
Ref: