Web.config file consists of vital information for your website to work including authentication, server, and application specific settings. Depending on your website’s requirements, this file may grow quickly to a limit that IIS refuses to read to prevent possible vulnerability attacks.Read More
If you have static values that you use across your .NET application, one place to store these values is the web.config file.
Let’s say you use your application’s name in several pages in your application. Instead of hard coding this value in each page, it’s easier and more efficient to store it as a parameter in the web.config file.
Example record in web.config:
<add key="APPLICATION_NAME" value="My application"/>
In order to read this value in your code-behind file, use this line:
Session state best practices:
- Reconfigure the default session id name in order to obfuscate the true meaning of the cookie value. In the case of ASP.NET, the default name is ASP.NET_SessionId. This immediately gives away that the application is ASP.NET and that that cookie contains the session id value.
- Ensure the length of the session id is long enough to prevent brute force attacks. Recommended length is 128 bits.
- Ensure the session id is created in a truly random way. This ensures that attackers can’t guess the session id due to some predictability analysis.
- Ensure that the session id does not contain any additional sensitive data. Instead, the value should be nothing more than a random string of characters with no meaning other than the session id as a whole.
- HTTPS should be employed for all session based applications handling sensitive data.
- Session cookies should be created with the Secure and HttpOnly attributes set.
- Prevent concurrent sessions where possible.
- Destroy sessions upon timeout, logoff, browser close or log-in from a separate location.
Cookie best practices:
- Do not store any critical information in cookies. For example, do not store a user’s password in a cookie, even temporarily. As a rule, do not keep anything in a cookie that, if spoofed, can compromise your application. Instead, keep a reference in the cookie to a location on the server where the information is.
- Set expiration dates on cookies to the shortest practical time you can. Avoid permanent cookies if possible.
- Consider encrypting information in cookies.
- Consider setting the Secure and HttpOnly properties on the cookie to true.
In order to implement best practices for cookies, add the code lines below into your application.
<system.web> <sessionState regenerateExpiredSessionId="false" cookieless="UseCookies" cookieName="id" /> </system.web>
Response.Cookies.Add(new HttpCookie("id", "")); Response.Cookies["id"].HttpOnly = true; Response.Cookies["id"].Secure = Convert.ToBoolean(ConfigurationManager.AppSettings["SecureCookie"]);
Is your application is generating a new session ID after postbacks? Check this out for instructions to solve this issue: Solved: ASP.NET application generates a new session ID after every postbacks
Bonus: How to avoid using the same Session ID
Especially for the high CPU usage issues, you may come across the error message below in DebugDiag reports:
Multiple requests in the process state with the same ASP.NET Session ID were detected in the dump file. At any point of time, ASP.NET executes only one request with the same session id and the remaining requests are queued behind the request which is getting executed.
There are a few recommendations about avoiding using the same session ID for multiple requests OR reducing the delays when there are multiple requests with the same session ID:
- If you have to use session variables:
- Try to use
EnableSessionStatewhere possible. This will not block other Read requests. If you assign True to this parameter, it will block both Read and Write requests.
- Make sure the requests are not long running so that if there is a lock on the session variable, it won’t delay other requests for a long time
- You can try decreasing the value of
LOCKED_ITEM_POLLING_INTERVAL. This is 500 ms by default which means the session will be checked if it is free every 500 ms. Decreasing it may reduce the delays for pending requests but it may increase CPU overload. I would recommend being extra cautious and doing extra tests if you want to change this interval.
- Try to use