Skip to main content

Tag: web.config

How to use static values (parameters) from web.config file

Ned Leave a comment

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:

ConfigurationManager.AppSettings["APPLICATION_NAME"].ToString()

Best practices for session state and cookies in ASP.NET application

Ned 1 Comment

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.

.
Code examples

In order to implement best practices for cookies, add the code lines below into your application.

Web.config file:

<system.web>
<sessionState regenerateExpiredSessionId="false" cookieless="UseCookies" cookieName="id" />
</system.web>

Code-behind file:

Response.Cookies.Add(new HttpCookie("id", ""));
Response.Cookies["id"].HttpOnly = true;
Response.Cookies["id"].Secure = Convert.ToBoolean(ConfigurationManager.AppSettings["SecureCookie"]);

References:

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:

  1. Try not use session variables. Try to use cookies or database tables instead. For example: Instead of storing the user preferences in the session, you can store them in a cookie. Another example: You can store the currently logged in user in cache or database if form authentication class doesn’t have this information
  2. If you have to use session variables:
    1. 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.
    2. 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
    3. 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.

More information: Why can’t I execute two requests from the same session simultaneously for an ASP.NET application?

How to remove server data from response headers of your ASP.NET application?

Ned Leave a comment

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:

Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET

This data can be viewed by a proxy such as Fiddler.

Server details
Server details

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.
.

Remove “Server” header

Add this method into Global.asax:

protected void Application_PreSendRequestHeaders(object sender, EventArgs e)
{
     HttpContext.Current.Response.Headers.Remove("Server");
}

Add this line into Application_Start in Global.asax:

PreSendRequestHeaders += Application_PreSendRequestHeaders;

.
Remove “X-AspNet-Version” header

Add this line into web.config:

<system.web>
     <httpRuntime enableVersionHeader="false" />
...
</system.web>

.
Remove “X-Powered-By” header

Add this line into web.config:

<system.webServer>
     <httpProtocol>
          <customHeaders>
               <remove name="X-Powered-By" />
           </customHeaders>
      </httpProtocol>
       ...
</system.webServer>

.
References