ReBuildAll Blog
Thoughts (mostly) on .NET development

Tampering with ASP.NET disabled controls   (ASP.NET)   
Ever disabled a control because of say authorization reasons? For example, some users might not have the necesarry rights to edit some detail of a data item, while other users can edit it. If you solve this scenario by simply using disabled controls, without any further data check when you update the values on the server side, you might be surprised that it is not really an effective way.

You see, the values sent to the server control can be tampered with. There are really good tools to do this, for example, TamperIE for Internet Explorer. Similar tools are available for Firefox as well as extensions.

All of these tools allow you to change (read: insert, delete or update) any form values that are sent when doing an HTTP POST request.

Now under normal conditions when you set a TextBox to disabled, it will not send the value to the server. This is actually a feature of the HTML standard, which says that disabled controls should never send their values when submitting a form.

However, with TamperIE, you can insert values into the POST value list. And ASP.NET will read the values from this list, regardless of the control being disabled or not. If you simply update your data item with the values from controls, your application might be vulnerable to this kind of spoofing attacks.


Suppose we have the following ASP.NET code:

a picture in a bl0g

You can see two text boxes, one of them disabled. When you press the button, the following code is executed:

        protected void Button1_Click ( object sender, EventArgs e )
            labelEnabled.Text = txtEnabled.Text;
            labelDisabled.Text = txtDisabled.Text;

The code feeds the values from the text boxes into labels, but it could just as well update some data item and save the changes into a database.

Under normal conditions the labelDisabled control will have the "constant" text that was put into the txtDisabled text box, by the server. However, start playing with the parameters, and you can change that value as well.

After you have installed TamperIE, when you do a form post, the following window will appear:

a picture in a bl0g

This window allows modifying the parameters that are to be sent to the server. You can then choose to send the original or the altered values. In the screenshot above you can already see that I added the txtDisabled parameter to the collection of parameters, and set its value to Hello world!. As a result my labelDisabled will display that value (also the text box) after I submit the values to the server and get back an updated page.


There are two solutions how you can avoid this kind of attack.

First, you can just not use a TextBox control. This might or might not be an available solution in your case. Using a Label will prevent invalid values from entering into the server by altering parameters.

But a better way is to always validate any data received on the server side. If the text box was disabled because the user is not authorized to modify that value make sure you never use or update that value when the POST occurs.


Can this affect applications based on the ASP.NET MVC Framework? The short answer is: yes it can. If for example you use the UpdateModel method when processing data, it will read the values from POST paremeters. As a result, tampering with the POST values will also affect what gets updated into the model. In fact in a way it is much easier to trick the system into processing parameters - given that you know what to name them.

Dangers of comments with ASP.NET   (ASP.NET)   
Ever wanted to comment out a section of your code - temporarily or for a longer time - in an .ASPX page? If you have not used server side comments, you might be surprised at the ends results.

There is something to remember concerning comments that you might not be aware of when commenting out code in an .ASPX or .ASCX file. When you use HTML comments, that is, <!-- ... -->, that code will not be commented out from an ASP.NET point of view. The code will be parsed. If you have controls there, they will be available to the page. If you have text there, it will be visible on the client side. This can pose a security risk and can lead to defective programs (as a worst case scenario).

A much better way is to use server side comments. These are available when you enclose the section in <%-- ... --%>. This section of code will not be visible on the client side, and it will not be parsed by ASP.NET.

Suppose you have the following in your ASPX page:

a picture in a bl0g

As you can see there are two comments after one another. To the casual observer, there is no real difference: both are comments.

Now check out what the generated HTML looks like:

a picture in a bl0g

As you can see the server side comment in the <%-- ... --%> form is completely hidden and not visible. However, the normal HTML comment was parsed and a control was rendered. Not only that, the control is available in server side code as well:

a picture in a bl0g

So next time you want to comment out something - for whatever reason - make sure you remember to do it right.

Of course I have to note that in any real world scenario you would not commit/checkin commented code into version control. That defeats the whole idea of version control. If you want to remove something you can be sure it will still exist in a prior version.

WinDbg Adplus.vbs on Windows 7 with IIS not working   (Debugging)   
I was preparing some WinDbg demos under Windows 7, when I bumped into an issue with ADPlus.vbs. I tried to generate dumps of IIS (W3WP.EXE) when it crashes.

It seems that ADPlus generates "package names" from the Process parameters (how the process was started, command line arguments). It uses then these package names for dump files, CDB configuration files and Exception configurations.

The problem was, that on my Windows 7 machine the W3WP.EXE parametes were a mile long (something over 160 characeters anyway). This meant that when running ADPlus.vbs it failed because of long filenames. It generated the dump directory name and some filenames that went over the 255 limit imposed on non-unicode applications.

First I tried generating dumps into a higher directory - not really ideal, but maybe it could work. Using only a \TEMP folder for the dump output path solved the file name too long problem. However, then came the problem that it was complaining about the Exception configuration. The error message was something like: The command size for the exception [AccessViolation] is [2006] and exceds the allowed limit. You can reduce it's size by using an output directory with a shorter name.

Google helped not this time :(

I ended up adding a quick tweak into ADPlus.vbs. I copied it into ADPlus_custom.vbs and added the following code after line 2550. In case you have a different version, this was in the Sub DumpSelectedProcesses(), after strPackageName was assigned and appended with the package name in the If statement. Right before the variable was printed out with WScript.Echo.

if len ( strPackageName ) > 40 then
    strPackageName = left ( strPackageName, 40 )
end If

I know it is a very dirty hack, but at least it works :)

Splitting CSV data with Regex   (Tips & Tricks)   
The other day I needed to process CSV data from a .NET program. The basic processing is quite simple, you can just call string.Split() to have the job done. But I was faced with a CSV file that contained items in quotes. And of course inside the quotes, a comma would be allowed, thus rendering string.Split() quite useless.

I asked around and found that people were using a library that can be obtained from CodeProject. You can find the actual project here. It provides quite robust CSV processing capabilities. Unfortunately, I was in a hurry, and did not want to play around with a library (I know: bad me). I needed a regular expression that could split my string.

As it turned out, there were some articles to be found around the internet, but none would offer a perfect solution. I finally stitched together a regex from various sources and Google cache entries.

Regex rex = new Regex(",(?=(?:[^\"]*\"[^\"]*\")*(?![^\"]*\"))");

This would work for my case. It might not be general enough, but if you have CSVs with quotes and need a fast solution, you can just take the above regex and then use it to split:

string[] result = rex.Split(csvLine);