Me Myself & C#

Manoj Garg’s Tech Bytes – What I learned Today

Archive for the ‘.Net 2.0’ Category

Encrypting entries in ASP.NET Web.Config

Posted by Manoj Garg on December 9, 2009

One of the best practices suggested while working with ASP.NET application is keeping values you want to make plug and play (changing them without changing the implementation) in web.config file. These configurable values can be anything ranging from some string constants to connection strings. Almost all the developers(at least those I know) follow this suggestion religiously. We keep these values in a readable format in web.config. Sometimes these values can have sensitive information like if we are storing connection string to our production database and if SQL server credentials are used to login to database server, then connection string will have username and password for the production database. Keeping credentials for database server unguarded can be a huge risk. Though IIS does a good job by blocking access to any resource with .config extension by default. But certainly there are many ways (leaving FTP open :)) by which someone with not so good intensions gets access to this config file containing credentials to database server. So, if one has this kind of sensitive data in config file then that data should be stored in encrypted way to mitigate risk of credentials falling under wrong hands.

This topic popped up while having a discussion with a colleague. He mentioned that .NET has some way of encrypting the values in config files. Which prompted me to search about this feature and Yes, .NET provides a very simple but effective way to encrypt values in config files. As you might already know, configuration settings in .NET work in provider model i.e. these settings can be replaced with another values without impacting the implementation.

.NET framework provides 2 encryption providers for encrypting the config file values.

  1. DataProtectionConfigurationProvider : It uses Windows DPAPIs(Data Protection API) to encrypt the data in config file and the key used to decrypt the encrypted values in stored in windows Local Security Authority (LSA).
  2. RSAProtectedConfigurationProvider : This provider uses public key encryption approach provided by RSACryptoProvider in .NET. This public key is stored in the config file itself.

To encrypt a configuration section use ConfigurationSection.SectionInformation.ProtectSection(providername) method and to decrypt the values use ConfigurationSection. SectionInformation.UnProtectSection() method.

Once you have encrypted the configuration sections, config file will no longer show the actual values instead it will be showing some cipher text. But at the time of accessing these values in code (C# or inline in aspx page) you don’t have to do anything like decrypting the config file or something, .NET will do it for you. But just take precaution while encrypting the config file values as this auto decryption done by .NET has some performance implications as well. So one should take a wise decision about which data to encrypt and which data can be written in plain text.

There are plethora of resources on this topic on web and my this post will also add to crowd, but following few link I found very informative and to the point.

  1. Encrypting Configuration Information in ASP.NET 2.0 Applications
  2. Encrypting Connection Strings in Web.config

Posted in .Net 2.0, ASP.Net, C# | Tagged: , , , , | Leave a Comment »

ViewState Compression in ASP.NET 2.0

Posted by Manoj Garg on September 16, 2009

STATE as a noun can be described as “the condition of a person or thing, as with respect to circumstances or attributes“.  In ASP.NET world, State of a control or a page is what it looks like, what its value is and what its value was before the page was posted back.

Since HTTP is stateless, to maintain state across postbacks in ASP.NET, some state management techniques are used. In ASP.NET state management can be categorized in two types depending on the location where state is being kept:

  1. Client Side: Client side state management involves keeping the state data on the client end, either on client machine or the browser. There are various mechanisms to maintain state on client side like Cookies, ViewState, Hidden Fields, Control State, Query strings etc.
  2. Server Side: Server side management is keeping state on a different machine be it database or file system on a different computer. Server side state management can be done using Application State, Session state etc. this data can be  stored in the server process or in a database or server file system.

For detailed information about different option available for state management in ASP.NET, please refer this link for MSDN. This link also gives a good comparison of various state management techniques with  their pros n cons.

ViewState is the first thing that come to mind when dealing with postbacks in ASP.NET.


In simple terms, ViewState is keeping information about page in a non-readable i.e. serialized way with the page itself. In ASP.NET, view state is kept in a hidden field name _VIEWSTATE on the page. So every time the page loads after the postback this serialized data is read and appropriate state is loaded into the controls.

To understand how viewstate is saved and loaded, one should know the page life cycle i.e. the steps a request, for loading a page, goes through before a page is fully rendered into the browser. This link on MSDN explains Page life cycle along with a good overview of what view state is. This post by Dave Reed gets under the hood of view state and explains the nuances of view state very well. I would recommend reading the above mention post to every one. That post has been the best link I have come across on view state.

As mentioned above, View state is kept in a hidden field _VIEWSTATE on the page. So every time the page is posted back to the server or retrieved from server, the content of View state also travel along with page content. In turn contributing to usage of network resources. Generally, developers have tendency to keep view state enabled for controls on their page. which unknowingly keeps growing the page size. This means as page size grows, it would take longer for the page to completely render itself.

Problem comes when the page size grows inordinately and waiting time for the end user to see the completely rendered page is too high. There are recommendation that one should use viewstate as minimally as possible to ensure the page size is with in limits. But sometime scenario enforces the developer to use viewstate in his/her page. In such cases following are some of the guideline/approaches to keep view state size in check.

  1. Enable view state for a control only when absolutely necessary: Set the EnableViewState attribute for the control to false explicitly, when you are sure that you do not require to keep state for that control.
  2. Don’t save large datasets into view state: Whenever possible keep the datasets and big data tables in cache or say session so that view state is small.
  3. Use IIS Compression: Internet Information Services(IIS) has the feature to provide compression for the pages it serves as response to the requests received. You can configure the IIS on your server to compress the appropriate websites or pages in the website. For detailed information about how to configure the IIS configuration on your server, please read this post by Scott Forsyth.  There is one another post by Shivprasad koirala, which is an extension of the post by Scott Forsyth, it also explains IIS compression in great details along with it also provides some comparison statistics data about what level of compression is good and for what type of pages one should avail this
  4. Using old ASP.NET 1.1 approach for storing the view state on server: In Page life cycle there are two steps available which do the job of fetching the view state from the hidden field and putting the view state content back into the hidden field it was stored. These methods are LoadPageStateFromPersistenceMedium and SavePageStateToPersistenceMedium. These methods are virtual methods from the Page class. A simplest approach would be to store the viewstate in session itself. Following code snippet shows how this could be done by overriding the two above mentioned methods and storing the viewstate in session after serializing and loading the viewstate from session again after desterilizing it. Serialization and deserialization is done using LosFormatter class. One can use any of the available formatters, BinaryFormatter, SOAPFormatter etc., for serializing the viewstate content. Content is stored in session with SessionID being the key.
protected override object LoadPageStateFromPersistenceMedium ()
    return (new LosFormatter().Deserialize ((string)Session[Session.SessionID]));
protected override void SavePageStateToPersistenceMedium (object state)
    LosFormatter los = new LosFormatter();
    los.Serialize (sw, state);
    string vs = sw.ToString ();
    Session[Session.SessionID] = vs;

An improvement in above mentioned approach could be to apply the compression on the viewstate content before storing them in session and decompressing the session content before restoring the viewstate. Following code does exactly this. This code introduces one more step, between storing and retrieving the view state from session, by compressing and decompressing the content. This approach again leads to save some more bandwidth.

Following class contains method for compression and decompression. Source code from


using System.IO;
using System.IO.Compression;

public static class Compressor
/// <summary>
/// Method for compressing the ViewState data
/// </summary>
/// <param name="data">ViewState data to compress</param>
/// <returns></returns>
public static byte[] Compress(byte[] data)
    //create a new MemoryStream for holding and
    //returning the compressed ViewState
    MemoryStream output = new MemoryStream();
    //create a new GZipStream object for compressing
    //the ViewState
    GZipStream gzip = new GZipStream(output,CompressionMode.Compress, true);
    //write the compressed bytes to the underlying stream
    gzip.Write(data, 0, data.Length);
    //close the object
    //convert the MemoryStream to an array and return
    //it to the calling method
    return output.ToArray();

/// <summary>
/// Method for decompressing the ViewState data
/// </summary>
/// <param name="data">Compressed ViewState to decompress</param>
/// <returns></returns>
public static byte[] Decompress(byte[] data)
    //create a MemoryStream for holding the incoming data
    MemoryStream input = new MemoryStream();
    //write the incoming bytes to the MemoryStream
    input.Write(data, 0, data.Length);
    //set our position to the start of the Stream
    input.Position = 0;
    //create an instance of the GZipStream to decompress
    //the incoming byte array (the compressed ViewState)
    GZipStream gzip = new GZipStream(input, CompressionMode.Decompress, true);
    //create a new MemoryStream for holding
    //the output
    MemoryStream output = new MemoryStream();
    //create a byte array
    byte[] buff = new byte[64];
    int read = -1;
    //read the decompressed ViewState into
    //our byte array, set that value to our
    //read variable (int data type)
    read = gzip.Read(buff, 0, buff.Length);
    //make sure we have something to read
    while (read > 0)
        //write the decompressed bytes to our
        //out going MemoryStream
        output.Write(buff, 0, read);
        //get the rest of the buffer
        read = gzip.Read(buff, 0, buff.Length);
    //return our out going MemoryStream
    //in an array
    return output.ToArray();

protected override object LoadPageStateFromPersistenceMedium()






string viewState = (string)Session[Session.SessionID];



byte[] bytes = Convert.FromBase64String(viewState);



bytes = Compressor.Decompress(bytes);



LosFormatter formatter = new LosFormatter();



return formatter.Deserialize(Convert.ToBase64String(bytes));





protected override void SavePageStateToPersistenceMedium(object state)






LosFormatter formatter = new LosFormatter();



StringWriter writer = new StringWriter();



formatter.Serialize(writer, state);



string viewStateString = writer.ToString();



byte[] bytes = Convert.FromBase64String(viewStateString);



bytes = Compressor.Compress(bytes);



Session[Session.SessionID] = Convert.ToBase64String(bytes);


5. ASP.NET 2.0 approach for saving viewstate on server:

In ASP.NET 2.0, ViewState is saved by a descendant of PageStatePersister class. This class is an abstract class for saving and loading ViewsState and there are two implemented descendants of this class in .Net Framework, named HiddenFieldPageStatePersister and SessionPageStatePersister. By default HiddenFieldPageStatePersister is used to save/load ViewState information, but we can easily get the SessionPageStatePersister to work and save ViewState in Session object. The only thing to do this is to override PageStatePersister property of Page class and ask it to return an instance of SessionPageStatePersister class:

protected override PageStatePersister PageStatePersister









return new SessionPageStatePersister(Page);






The PageStatePersister class can be inherited to also created custom storage mediums for session state. The PageStatePersister class has two methods Load() and Save() which can be used to provide custom loading and saving media for ViewState.

public class StreamPageStatePersister : PageStatePersister






public StreamPageStatePersister(Page page)


: base(page)






public override void Load()




Stream stateStream = GetSecureStream();


// Read the state string, using the StateFormatter.



StreamReader reader = new StreamReader(stateStream);


IStateFormatter formatter = this.StateFormatter;


string fileContents = reader.ReadToEnd();


// Deserilize returns the Pair object that is serialized in



// the Save method.



Pair statePair = (Pair)formatter.Deserialize(fileContents);


ViewState = statePair.First;


ControlState = statePair.Second;










public override void Save()





if (ViewState != null || ControlState != null)




if (Page.Session != null)




Stream stateStream = GetSecureStream();



StreamWriter writer = new StreamWriter(stateStream);



IStateFormatter formatter = this.StateFormatter;


Pair statePair = new Pair(ViewState, ControlState);



// Serialize the statePair object to a string.



string serializedState = formatter.Serialize(statePair);














throw new InvalidOperationException(“Session needed for StreamPageStatePersister.”);








Then a PageAdapter can be used to use this persister

public class MyPageAdapter : System.Web.UI.Adapters.PageAdapter




public override PageStatePersister GetStatePersister() {


return new Samples.AspNet.CS.StreamPageStatePersister(Page);







This adapter can be configured via a .browser file placed in App_Browsers folder locally with the web site directory.

    <browser refid="Default" >
                adapterType="MyPageAdapter" />


This all above content was related to removing/reducing the Viewstate getting transferred over network. But there is still one more type of state “ControlState”. In layman’s terms, Its the minimal information that a control needs to render and function itself properly after a postback. A more apt definition from MSDN is:

Control state, introduced in ASP.NET version 2.0, is similar to view state but functionally independent of view state. A page developer can disable view state for the page or for an individual control for performance. However, control state cannot be disabled. Control state is designed for storing a control’s essential data (such as a pager control’s page number) that must be available on postback to enable the control to function even when view state has been disabled. By default, the ASP.NET page framework stores control state in the page in the same hidden element in which it stores view state. Even if view state is disabled, or when state is managed using Session, control state travels to the client and back to the server in the page. On postback, ASP.NET deserializes the contents of the hidden element and loads control state into each control that is registered for control state.

As it is mentioned in the above description, that ControlState will be traveling with the page all the time. There may come a requirement where we want to have it stored somewhere else other then the page hidden fields. While searching for methods to reduce the viewstate size, i stumbled across this post by SZOKELIZER, which describes a way to store the ControlState in session as well. ASP.NET provides a switch “RequiresControlStateInSession ” which allows to store the control state in session rather then the page itself. So for the sake of completeness I am putting the code that needs to be put to enable storing the control state in session from the above mentioned post.





In this post I have written about different mechanisms to reduce size of viewstate that travels along with an asp/aspx page every time. I have tried to covered few of the approaches that can be used but I am sure there can be many more. One such approach suggested by a friend of mine is using HttpHandlers to cut the viewstate from the request and restore it back. I am working on a poc for this. I will post it once it is complete. Please do post a comment, if you have come across any other way to tackle this or if there is some correction in approaches I have described above.

Posted in .Net 2.0, ASP.Net, C#, ViewState | Tagged: , , , , , , , , , , | 3 Comments »

Request.ValidateInput() : A common misconception

Posted by Manoj Garg on September 7, 2009

Attackers try to exploit smallest possible hole into the security of a website. A common and widely used method is script injection attack or cross site scripting where attacker tries to put some script as input to the website and tries to damage the system. A simplest example could be passing a java script function that redirects every request to a page to some other site next time onwards or passing a SQL DML statement which deletes/updates record into the database.

ASP.Net provide some measure to mitigate this risk of script injection. One of such technique is validating each and every input entered by the user before passing it on the server automatically. In this approach IIS parses the input before it is sent to the worker process and checks it for potential dangerous characters lie <, > etc. If any of such character is found in the input request, an exception is thrown, thus saving the site from a possible attack.

The exception thrown is

“A potentially dangerous Request.Form value was detected from the client”

In ASP.NET this feature can be applied per page basis or for the entire site depending on the requirement. To enable input request validation for the entire site, set validateRequest attribute of page section in web.config to true.

        <pages validateRequest="false" />

Similarly, to override the request validation or enable/disable request validation on a page ValidateRequest attribute of Page directive can be set to true/false respectively. Setting this attribute to true instructs the IIS to check the sanity of the incoming request before passing it on.

So this approach won’t let any script to pass through. But there are situations where you need to take a script or the prohibited characters like <,> as input from user, at the same time preventing a misuse of this opportunity of script injection.

A commonly used approach in ASP.NET for this scenario is:

  1. Set ValidateRequest to false for that page.
  2. Encode the input entered by the end user using Server.HtmlEncode(): Encoding ensures that all the stop words(potentially harmful characters) are converted to an equivalent HTML character encoding e.g. “<” is converted to “&lt;” etc.

I had a similar requirement, few days back, when in our application on “contact us” page, We wanted to allow user to enter html scripts into a text box. So we disabled the ValidateRequest attribute to false and used Server.HtmlEncode() method to encode the entered input. But at the same time we didn’t wanted the user to pass something malicious through the query string or the cookies. ASP.NET also provides a method on the Request object named ValidateInput(), which validates the request input passed by the client to the server. And if something fishy is found in the request an HttpRequestValidationException exception is thrown. And this is where the confusion gets in.

As per MSDN, Request.ValidateInput() method ….

The HttpRequest class uses input validation flags to track whether to perform validation on the request collections accessed through the Cookies, Form, and QueryString properties. The ValidateInput method sets these flags so that when the get accessors for the Cookies, Form, or QueryString property are invoked, input validation is performed. Validation works by checking all input data against a hard-coded list of potentially dangerous data.

If the validation feature is enabled by page directive or configuration, this method is called during the page’s ProcessRequest processing phase. The ValidateInput method can be called by your code if the validation feature is not enabled.

As this definition says that ValidateInput method does nothing but sets some flags indicating that all access to user input must be validated before using it. But normally developer tend to call Request.ValidateInput() method and then expect it to throw the HttpRequestValidationException exception, which will not happen since this method doesn’t throw any exception, rather any access now onwards to input will throw the above mentioned exception.

Lets disassemble the Request.ValidateInput method.

public void ValidateInput()

As shown in the above code snippet, this method has just some set methods calls. Actually these method set a flag for one of the input approach that can be used by the client. Like querystring, form input , cookie etc.

So what does this setter method do?? This method is merely an indicator for the getters methods of each of the request fields to check the sanitation of the value before returning the value to the requestor and if there is some invalid input then throw the HttpRequestValidationException.

So to check for invalid input in Form values, we need to access form values collection of the request as Request.Form after the call to Request.ValidateInput(). Following is a sample code for validating Form values,

String firstName = string.Empty;
    //Access the Form value collection. So if there is any non complient input entered by user.. It will throw an exception
    System.Collections.Specialized.NameValueCollection nvc = Request.Form;

    firstName = txtName.Text.Trim();
    firstName = HttpUtility.HtmlEncode(txtName.Text.Trim());

here line in yellow color will throw an exception if at all there is some bad data in the input. Then in catch we can use HtmlEncode() to encode the user input.

Similar approach can be used while accessing cookies or QueryString.

Posted in .Net 2.0, ASP.Net, C# | Tagged: , , , | 3 Comments »

Problem with Webdev.webserver.exe when working with web services with non-fixed ports

Posted by Manoj Garg on May 6, 2009

Yesterday, a team mate of mine sent an email regarding a problem with his Visual Studio 2005. ASP.NET web server wasn’t allowing him to debug any Web services. Following is the complete description of his problem:


In short, the ASP.NET 2.0 development web server (webdev.webserver.exe) on my machine broke after I installed and uninstalled NDoc some days ago. IIS still works fine. I’ve tried re-registering ASP.NET 2.0 (aspnet_regiis –r from the 2.0 directory) to no avail. Other than re-installing VS 2005, could you recommend a quick fix?

Problem Description

I am on XP. I had VS 2005 with v2.0 of the framework. Then I installed NDoc recently and that supports only v1.1, so it installed v1.1 on top of v2.0. That is fine because both versions can co-exist but what it did was screw up some settings with:
a) The web server that comes with ASP.NET, the one you run your web services on in debug mode.
b) SQL Server’s active CLR settings (but this isn’t bothering me as much)
c) IIS settings (but I fixed this by re-registering IIS with 2.0)
What’s bothering me to the hilt now is the broken ASP.NET web server won’t allow me to debug my Web services or even have another project in the same solution create a web reference to it.
I can’t generate proxies in Visual Studio because of this, nor can I set a web reference to a web service in the same solution (as it involves generating a proxy).
Note that I can call wsdl.exe though. My web services compile, and if I generate a proxy myself through wsdl.exe, deploy my WS locally on IIS, and change the url in the proxy’s constructor to my locally deployed WS, and add the proxy to my client project, it all works fine.

But I don’t want to deploy my service yet. I just want all projects in the same solution referencing the ws like well-behaved little kids.
When I do try to create a web reference to the WS project in my solution, I keep getting this error:
Server Error in ‘/’ Application.
Parser Error
Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.
Parser Error Message: Could not create type ‘DaWS.PhoneDirectory’.
Source Error:
Line 1:  <%@ WebService Language="C#" CodeBehind="PhoneDirectory.asmx.cs"
Line 2:  Class="DaWS.PhoneDirectory" %>
Source File: /PhoneDirectory.asmx    Line: 2
Version Information: Microsoft .NET Framework Version:2.0.50727.3082; ASP.NET Version:2.0.50727.3082
It’s been nagging me for days now and I’ve been managing with deploying in IIS.
Other than re-install Visual Studio, does anyone have a better solution?
Here’s what the Event Log says:
Event Type:    Warning
Event Source:    ASP.NET 2.0.50727.0
Event Category:    Web Event
Event ID:    1310
Date:        06/05/2009
Time:        12:04:33 AM
User:        N/A
Computer:    ABCD
Event code: 3006
Event message: A parser error has occurred.
Event time: 06/05/2009 12:04:33 AM
Event time (UTC): 05/05/2009 6:34:33 PM
Event ID: c41a610193fa4c2e810dad096709b0b0
Event sequence: 4
Event occurrence: 1
Event detail code: 0
Application information:
    Application domain: a54e0deb-1-128860220726250000
    Trust level: Full
    Application Virtual Path: /
    Application Path: C:\Me\rnd\DotNet\DoIndexersGetSerialized\DaWS\
    Machine name: ABCD
Process information:
    Process ID: 660
    Process name: webdev.webserver.exe
    Account name: Domain\Me

Some one finally caught the issue, following are his observations and solution:

Just wondering if you are using a fixed port or not for the web service that you try to reference. Because Web Dev by default always host the app on different port and if that the case you will not be able to get it working ever.

If you are not using the fixed port I would suggest you to use the “External Tool” options present in the VS’s Tool menu and create a fixed web dev location that is associated with you web service and you should be able get it working.

I may be telling you the thing that you might have tried but just incase if you haven’t please give it a try.

Please have a look at this URL and probably give you the solution you are looking for.

This did the trick. The problem was solved. So I thought to write it here as someone else may face the same issue. 🙂

Posted in .Net 2.0, ASP.Net, VS 2005 | Tagged: , , , | 4 Comments »