What prevents a user from adding controls to an ASP.NET page client side?

Question

This goes back to my other question which I thought was sufficiently answers but upon reflect am not sure that it was (sorry).

Backgrounder:

1. I am generating a form dynamically. I am pulling from the database the controls.

2. I must associate each control with a database ID which is not the user's session id. I do this currently by storing my ID in the ID for the web control with some other stuff to make it unique/clear what I am doing.

3. On the post back, I iterate through all the controls on my web page checking for my special identifier, ie, MyGeneratedTextBox_ID_Unique. This process enables for 2 important steps, identifying the control was one I generated and also getting the ID for this input field.

And, all of this works but I'm still concerned about the security of it. I do not see a security issue with showing the actual database ID's in this case, although agree it is not desirable. However, I am concerned of the following possibilities:

1. If a user could add a nefarious control to my collection and use that for a SQL injection attack.

2. More academic, but if a user could somehow store data for fields they do not have access too by changing the id's.

I agree this is a "hack" of a way to do it. But my question is, is it a security risk and is there an 'easy' way to do it in a less hack way?

I assume that only the controls that are created/instantiated on the page are added to the controls list.. thus all controls must be created server side and thus the security issue is address but just wanted to validate. Thanks again.

PS: I could see adding a property for each control and encrypting the viewstate would be a little more secure.

Answer 1

In the original guidelines for ASP.NET 2.0 security they specifically state that you should perform input validation on every input being posted back from the browser. There is really nothing that prevents someone from posting back different data to your server side code. There is some minimal request validation built into ASP.NET, but they specifically state not to rely on that.

You should always validate each individual input that is being posted back from your controls for data integrity. All inputs should be sanitized for SQL injection attacks by removing unnecessary special characters and patterns that might indicate an attack vector. If all you are relying on is an identifier from the control to say that the data is good then you have a huge hole in your validation logic.

You should perform server side validation on each input that validates the format of the input is good as well as that it has no problematic data contained in it.

http://msdn.microsoft.com/en-us/library/ms998258.aspx

Answer 2

I am going to try to answer my question because I think this is the only way it could be:

The only way server side controls get created is on the server thus you can trust that they will have the id that you set them too. This is one reason the controls must be created on every page instantiation. You may not trust any form submitted data but controls and there IDs are generate server side and thus safe. Likewise, it is not possible to edit the HTML to ever generate a server side control.

Thus my method is relatively secure even if it is not elegant. The only security flaw is the id revealed.

Answer 3

I assume that only the controls that are created/instantiated on the page are added to the controls list.. thus all controls must be created server side and thus the security issue is address but just wanted to validate. Thanks again.

The controls you create "live" on the server with runat="server". You don't need to check for your special ID in the controls collection. As Harv said, you do need to validate all of the input from your controls.

No one can add server controls to your pages unless perhaps your web server was compromised.

Answer 4

I think what you answered yourself is not wrong. But I feel like you are still mixing things up a bit (creation/instantiation/definition of controls vs. restoring ViewState/state management).

Maybe the following two pieces of information help clear things up a bit:

• ASP.NET Page Life Cycle Overview
• TRULY Understanding ViewState

I very warmly recommend the second article to anyone using ASP.NET (and thus ViewState).