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.
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.
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.
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
If you have to use session variables:
Try to use ReadOnly value for EnableSessionState where 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.
The less you give to hackers, the safer your web application is. Hiding the product, technology, and version information of your server is one big step towards narrowing the attack surface of your application.
By default, IIS server will reveal this data to everyone who has access to your application:
This data can be viewed by a proxy such as Fiddler.
You can remove these headers by add a few lines into web.config and Global.asax files. You don’t need to do any configuration changes in IIS if you are using IIS 7 or an upper version. .