Protecting Web.Config file

Sensitive information should not be kept as clear text. At times we need to store sensitive information into web.config file. We store the database connection string in unencrypted format also. Some of the vulnerability in doing so..

1. Client changes things they shouldn't change in the web.config file.

2. An employee of your ISP can read your sensitive data when your site is hosted in a shared hosting environment

Since Web.config may contain sensitive data such as connection strings, it is important that the contents of Web.config be kept safe and hidden from unauthorized viewers. By default, any HTTP request to a file with the .config extension is handled by the ASP.NET engine, which returns the “This type of page is not served” message.

But what if an attacker is able to find some other exploit that allows them to view the Web.config file’s contents? What could an attacker do with this information, and what steps can be taken to further protect the sensitive information within Web.config? Fortunately, most sections in Web.config do not contain sensitive information. What harm can an attacker perpetrate if they know the name of the default Theme used by your ASP.NET pages?
Certain Web.config sections, however, contain sensitive information that may include connection strings, user names, passwords, server names, encryption keys, and so forth. This information is typically found in the following Web.config sections:
• appSettings
• connectionStrings
• identity
• sessionState
Refer the following link to read more on this article by.. Scott Mitchell

http://www.asp.net/Learn/data-access/tutorial-73-cs.aspx

Form Authentication and Session State

Form Authentication and Session State

Form Authentication with default configuration is next to impossible to create a forged forms authentication ticket. The problem with depending on session state as an indicator of a logon session is that unlike forms authentication, it is trivial to create a valid session identifier.
A session identifier is nothing more than a 120-bit random number encoded using letters and numbers (this works out to a 24-character cookie value due to the way session state encodes the random number), there is a chance that we can easily create a perfectly valid session identifier. Of course, if we send such an identifier to Asp.NET, there probably isn’t going to be any session data associated with it. (We have 2^120 possible combinations to guess if you were actually trying to grab someone else’s session).
The configuration options for session state, unlike forms authentication, don’t include options for setting a cookie domain or a cookie path.
Another flaw of using session state for tracking logon status is the inability to set the secure property of the session state cookie. Unlike forms authentication, the session state cookie always flows across the network regardless of the state of any SSL security on the connection. If we think about it, this makes sense for a feature like session state because many applications break If the data in session randomly became unavailable when a user surfer between secure and insecure pages.
The whole point of a logon session is that it requires authentication to obtain a session, and once established there is persistent association between an authenticated user and the actual session data. Please check the image for a security feature comparison of forms authentication and session state.

The best way to think about session data is to treat session state as if it were data stored in forms variables on a page. Session state acts as a server-side store for this type of information.
Protecting Session Cookies
As with forms authentication in ASP.NET 2.0, the session state feature explicitly sets the HttpOnly property on the cookie to true. Because applications store interesting information inside of session state, ASP.NET protects the session identifier from client-side cross-site scripting(XSS) attacks.
The likelihood of an attacker ever guessing a live session cookie is astronomically low (with 120 bits in the session identifier, that works out to an average of 2^60 guesses required.
HttpOnly property prevents cookie hijacking.
Why SessionID is not encrypted like forms authentication ticket ?
The default session state cookie is a cryptographically strong 120-bit random number, there didn’t seem to be much point in layering the overhead of encryption and signing on top of it. Furthermore, not only is the session identifier a strong random number, because the session state identifier is stored in a session based cookie, the session ID changes from browser session to browser session.
With session state the only time we can really someone else’s session state is while that user’s session is still active. There is no such thing as an offline brute force decryption attack or hash collision attack with session state. With session state, an attacker must successfully guess (incredibly unlikely) or hijack (possible but difficult to accomplish) a session identifier while that session is still active somewhere in an application. Although an attacker could theoretically stumble across a session identifier associated with an expired session, this isn’t of any use because an expired session means that the data associated with that session is no longer available.
When you abandon a session, the session ID cookie is not removed from the browser of the user. Therefore, as soon as the session has been abandoned, any new requests to the same application will use the same session ID but will have a new session state instance. At the same time, if the user opens another application within the same DNS domain, the user will not lose their session state after the Abandon method is called from one application.
Sometimes, you may not want to reuse the session ID. If you do and if you understand the ramifications of not reusing the session ID, use the following code example to abandon a session and to clear the session ID cookie:
Session.Abandon();
Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));
This code example clears the session state from the server and sets the session state cookie to null. The null value effectively clears the cookie from the browser.

Reference: Asp.Net security book related to roles, authentication by Stephan Schakow. Its a great book.