1. Session Cleanup
Create a new Session before Login Page is presented to avoid Session hijacking.
Please refer to http://support.microsoft.com/kb/899918
Session.Abandon();
Response.Cookies.Add(new HttpCookie(“ASP.NET_SessionId”, “”));
2. Web.Config Changes
Make the following changes to web.config to secure external facing web app.
- Instead of <forms cookieless=”UseUri”> , use <forms cookieless=”UseCookies”>
- Instead of <forms requireSSL=”false”>, use <forms requireSSL=”true”>
- Use <httpCookies httpOnlyCookies=”true”> is a useful measure against Cross-Site Script attacks. (works only on IE 6 & above, FireFox 3 & above, Chrome, in future other browser would embrace)
- Instead of <customErrors mode=”Off”>, Use <customErrors mode=”RemoteOnly”>
- Use <trace enabled=”false” localOnly=”true”>
- Use <compilation debug=”false”>
- <pages> validateRequest should be set to “true” which is default.
3. Expire Pages
Add the following changes to all the pages which need to be expired.
Cache-Control : no-cache, max-age=0, s-maxage=0,must-revalidate,proxy-revalidate,no-store,private
Pragma : no-cache
Expires : -1
4. Cookie Cleanup during Logout
Add the following changes to all the pages which need to be expired.
5. Request.MapPath
If we 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 we can prevent cross-application mapping. This means that a user cannot successfully supply a path that contains “..” to traverse outside of application’s virtual directory hierarchy.
6. Avoid Persistence Cookies
Use Session cookies to store information instead of using persistence cookies. This will avoid information stored in the user’s computer.
7. SSL (HTTPS) for all Form Logins
Make sure Login Pages are served using SSL Session instead of serving over HTTP.
8. Enforce Strong Passwords
Ensure that passwords are complex enough to prevent users guessing other users’ passwords and to prevent successful dictionary attacks against user credential store.
9. Do Not Reveal Exception Details to the Client
When exceptions occur, return concise error messages to the client and log specific details on the server. Do not reveal internal system or application details, such as stack traces, SQL statement fragments, and table or database names to the client. Ensure that this type of information is not allowed to propagate to the end user or beyond current trust boundary. A malicious user could use system-level diagnostic information to learn about application and probe for weaknesses to exploit in future attacks.
Configure a Custom Error Page to display all Application/System related Errors.
10. View State
- Avoid Storing Sensitive Data in View State
- Using SSL protects ViewState between Server and Browser, but it does not stop it being viewed and modified on the user’s computer
- Use the following setting to encrypt View State
And
When validation was set to 3DES, ViewState was encrypted before being rendered in the page.
11. Configure the MachineKey to Use the Same Keys on All Servers in a Web Farm
Configuration files on each server share hashing and encryption keys. These are used by ASP.NET to protect ViewState and forms authentication tickets. Manually generated, common keys are required because we cannot guarantee which server will handle successive requests.
12. Set the Correct Character Encoding
To successfully restrict valid data for Web pages, we should limit the ways in which the input data can be represented. This prevents malicious users from using canonicalization and multi-byte escape sequences to trick input validation routines.
13. Use the innerText Property Instead of innerHTML
Wherever we use innerHTML property to build a page and if the HTML is based on potentially untrusted input, we must use HtmlEncode to make it safe. To avoid having to remember to do this, use innerText instead. The innerText property renders content safe and ensures that scripts are not executed.
14. Block All “403” Forbidden Errors
Instead of displaying 403 forbidden errors to the end user, always display Custom Error page to the user. 403 forbidden errors expose the web server directory structure to the user.
15. Consider Using Page.ViewStateUserKey to Counter One-Click Attacks
Consider using 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.
void Page_Init (object sender, EventArgs e) {
if (Session["ViewStateUserKey"] == null)
Session["ViewStateUserKey"] = new Guid().ToString();
this.Page.ViewStateUserKey = Session["ViewStateUserKey"].ToString();
}
The server has no way of knowing that the ViewState originated from the attacker. ViewState validation and HMACs do not counter this attack because the ViewState is valid and the page is executed under the security context of the user.
By setting the ViewStateUserKey property, when the attacker browses to a page to create the ViewState, the property is initialized to his or her name. When the legitimate user submits the page to the server, it is initialized with the attacker’s name. As a result, the ViewState HMAC check fails and an exception is generated.
Tags: .NET Web Security
