I Disable a textbox by c# code in an ASP.net Page with below code:
Textbox1.Enabled=false;
to prevent user changing a specific value.
as you know Textbox1.Enabled=false; in html mode will convert to disabled="disabled" css prpoerties.
but unfortunately end user can remove this css properties by Firefox Firebug and enable the textbox and press the submit button and send the changed value to server.
so what can I do?
You should never - ever - trust user input. Everything submitted via website form is user input. There is nothing you can do to prevent someone from submitting anything they very well please, and you should not even try.
Instead, you should check/validate those values on the server. If it's a value you just want to display to them, but not allow them to change, then just don't have your code-behind check the value at all... since you know it should not change.
If you are enabling/disabling that TextBox based on whether the user is an 'admin' or something... then you are doing it wrong.
The same as for any data that you get from the browser.
Trust it only as much as you trust the user (and a bit less then that if you don't use SSL)
Untrusted users might be making an attack
Trusted users might be making a mistake
Check that it is sane (if whatever condition that causes the field to be disabled holds true, then check that the field isn't submitted)
Escape any data before you use it (e.g. for SQL before inserting it into a DB and for HTML before putting it in an HTML document).
Related
I was recently discussing this with someone, and I wasn't sure if this is an issue or not.
We are creating an ASP.NET website and if the user performs an action on a page we might create a database query using the Text values on controls that we have previously populated.
Could a user do something malicious like modify the text of a label control in their browser, then hit the update button and when we pull that label's .Text we end up inserting that value into the database?
It's easily done via firebug, for example, yes. Make sure you sanitize/validate any input coming in to prevent SQL injection or any other malicious intent.
Have a read of this MSDN article for more help.
Such a button is not rendered to the browser, so is there any way a malicious user would be able to trigger the action defined by the invisible button? e.g. with a JavaScript call to WebForm_DoPostBackWithOptions? Would ASP.NET accept a POST that appeared to be triggered by this button, even though it wasn't rendered?
Short answer yes.
It is always up to you (the developer) to ensure data received from user input (in this case a post) is valid. Having said that the asp.net framework will do a lot of verification for you, such as "suspicious looking post values".
It is possible to construct a post to a web endpoint, even if the page you display does not have a submit button.
Edit
This would be an example of security through obscurity and is generally not a best practice. Asp.Net "submit" buttons modify a hidden form field called __EVENTTARGET. The asp.net handlers will inspect this field when determining a button click "event". This value can be spoofed if the attacker knew the name of the event target.
Hiding/showing UI elements are good for improving the user experience, but you should always validate (on the server) user input before performing any business actions.
I don't believe it would, if it's not rendered it shouldn't accept the postback. .net uses hidden fields on the page to know which controls were on the page and can verify that during postback, so it knows what triggered the post back. if the control was not there to begin with it shouldn't accept it.
Yes, this is definitely possible. ASP.NET accepts all POST values for controls defined on the page, visible or not. Beware too of i.e. textfields that are set to "read-only". Don't use readonlyControl.Text after the post, and trust that it has the same value as it had the last time you set it.
Take a look at what is posted when you perform a submit with ASP.NET with i.e. Chrome Developer tools, Fiddler, etc, and you should be able to figure out how to add your own value to an "invisible" text field.
This is a clarification question: I'm studying for MCTS 70-515 and in my training kit it states that Hidden Fields: "users can view or modify data stored in hidden fields"
Now I'm aware that users can view the source of the page and then that would display the hidden field data. But I'm curious as to the modification part. How would a user modify a hidden field data and how would it affect the site? Even if they modify the data via View Source they can't save the page and then post the data back to the server.
What am I missing that the author is assuming I know?
OK well all the answers said the same thing (at this time). I guess if the author would of said "savvy" user then that might of tipped me off. I guess I've always assumed that users wouldn't know of Firebug or any other tool that can do manipulation after the page has been displayed to the user.
Thank you for all your answers. I appreciate it!
The hidden field is just a key-value-pair represented as a key-value-pair when serialized and sent to the server, just like any other form element. There are a number of ways to modify hidden fields - one is to use FireBug or some other "developer console" in the browser, another is to manually write the request and send it to the server.
In addition to using a debugging tool such as Firebug, the user could change the value of a hidden field indirectly though other interactions (with JavaScript) making the change for them. Normally, the user would be unaware of the technical detail of what they are doing (they neither know about, nor care about the fact a hidden field got changed)
Other tools, such as Fiddler, may intercept the web request and change the value of the hidden (or any) field as it is being transfered to the server on a postback.
It is possible to change the value of a hidden field on the server during a postback, as you know, or on the client using JavaScript.
Example using jQuery: http://jsfiddle.net/JGsQ5/
Once the page has been loaded by the browser, it is stored in the DOM (http://en.wikipedia.org/wiki/Document_Object_Model) which is what JavaScript manipulates and is used by the browser to build a HTTP request which is sent back to the server as a postback.
Easy, open up a program like FireBug and change the element value. Remember, markup is client side, so the server is trusting the client to send back the right data -- however, this is easily circumvented.
It is best to store data that is essential to the security of your application in session's, whereas the data remains on the server side and is tied to the client. ASP.NET can make up of hashes to prevent the unauthorized modification of fields, amoung other things.
I've seen plenty of Cross-Site Scripting attack prevention suggestions, but I'm not asking about Form Input validation. How would I prevent something like this:
javascript:(function(i,j){with(document){for(i=0;i<forms.length;++i){with(forms[i]){for(j=0;j<elements.length;++j){elements[j].disabled=false}}}}})()
from being inserted into the URL? This code would enable all form elements on a page if added to a URL. So if you disabled certain buttons based due to permissions or something then all those buttons would become enabled.
Should I just be parsing the URL and check for the Javascript keyword?
No. You can't, anyway, as it doesn't get sent to the server.
That is just JavaScript executed locally by the user themselves. It should mean nothing to you. The security of your system should never rely on client-side javascript, all your authentication, and so on, should be done server-side.
The key is to not worry much about it client-side. Server-side is where you have to be bullet-proof. Do not assume, for example, that just because you named your form inputs the same as your database column names, that you can just loop through Request.Form and persist all the data you get. You should validate that you only process the inputs you are expecting, and validate them for data type and range, as well as considering the user's permissions to alter a given field.
That way, the user can send whatever they want, you will only process and accept valid data server-side.
I have a custom made ASP control which is based on a select (drop down menu). If I disable my control by adding the word "disabled" in its html, I start getting null pointer errors when processing the form data.
I figure, either the browser doesn't post back disabled form items or ASP.NET ignores them when processing the form data. I'm not sure which one it is. I'm trying to understand where I'm loosing data.
Thanks for your help.
PS. I realize that there are better way to create and disable controls than manually editing html but there's a context here that doesn't allow me to do otherwise.
Yes setting control's Enable = false is prevents control's value to be added posted data collection.
you can use readonly attribute instead.
here in MSDN it says :
The Text value of a TextBox control
with the ReadOnly property set to true
is sent to the server when a postback
occurs, but the server does no
processing for a read-only text box.
This prevents a malicious user from
changing a Text value that is
read-only. The value of the Text
property is preserved in the view
state between postbacks unless
modified by server-side code.
Also here is the Microsoft's reply to a bug report related to topic.
but if you use in classical way like that it will work :
txt2.Attributes.Add("readonly", "readonly");
It will prevent the control from posting back but remember this web paradigm is a client/server technology. A person could modify the client data (HTML and / or Javascript) and force a postback no matter what you send him.
Therefore don't rely on this for security sensitive operations such as money manipulation and so on.
Always do a check on the server-side too for sensitive operations.