Is it possible to decode, and thus tamper with, the rendered _EVENTVALIDATION field? I found a lot of information about what it DOES, but couldn't find anything that actually says whether or not the value itself is protected against tampering. I did attempt to base64 decode it and got gibberish back, so I'm assuming that it is in fact encrypted, but if someone knows for sure and can verify that, that would be awesome.
I do know that Viewstate is not encrypted (although you can set it to be). I'm not as interested in that, I'm just interested in eventvalidation.
I found a similar question: Is it possible to decode EventValidation and ViewState in ASP.NET? but no one seemed to have a specific answer regarding the event validation field.
Concrete example: I have a dropdown of available reports that the user can run. It's populated with some "members" reports but also some "Admin only" reports which are rendered during OnLoad, and only adds them if the user is an Admin. When the page posts back, can I trust the event validation routine to be secure and that the user has not injected an "admin only" report into the list of acceptable values, or should I re-check permissions in my postback handler to verify the user can actually use the report that was selected?
First, event validation is a backstop protection against XSRF, not against malicious users.
If you want to make sure they can only run the reports they are permitted to run, then check they are permitted to run the report at the point you run it.
Secondly, the event validation data is encrypted and has a MAC. It should be very hard to tamper with. But relying on it is not the right way to solve to your problem.
If you havn't turned off the native injection protection settings then if anyone try's to edit the controls list of values and post it back it will cause an error.
Related
I got a simple Site with a textbox where the user can enter some stuff. That Text is analysed and fancy stuff is done with it (like counting the words, displaying the text in another textbox)
No Database-Connection exists. No data is saved permanently
Do I still have to worry about code injection?
Can something harmful be done?
I agree with #nmat and want to add here that If you want to do check against the security, the only thing you need to consider is cross site scripting due to weird inputs in textbox. You can use Anti-cross site scripting library for validation. Same site is also having details regarding what I just said.
Depending on how you implement the application behaviour, plenty of things could go wrong. You don't have to worry about SQL injection because you don't have a database, but you may have problems if you aren't careful with the submitted data.
Add ASP validators to the TextBox to ensure that the user only submits data that you expect to receive. Ex: add a maximum length, a regex or other custom validation. ASP validators work both on the client side and on the server side so this should be enough protection in this case.
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 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).
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 only need to parse URL Request.Querystrings on GET, not on postback, right?
if(!IsPostBack)
{
Viewstate["magic_number"] = Parse(Request.Query);
}
The user can't be expected to modify the URL in the Request for subsequent postbacks, or can they?
Motivation for question-- I don't control the javascript snippet that does the postback, so it's something of blackbox to me.
The URL is not expected to change. But remember that each postback is a new instance of your page class. So if you didn't save the results somewhere on the first view you need to be prepared to do it again on the next one, and so on. In this case you saved it to ViewState, and so that should be fine.
However, I suspect you wouldn't be asking the question unless you had observed behavior that led you to suspect otherwise. So let's consider for a moment what things could cause this to break:
It is possible to modify ViewState at the client where you saved your results (though not trivial and definitely not recommended).
You can fake a postback before the initial page view.
You can use javascript to alter the posted url.
However, for all these things you would certainly know if you have written anything to do that.
Your assumption is correct, the URL is not expected to be modified in subequent post backs and you need to parse the query string only on the GET, which happens the first time the page is loaded.
The URL does not normally change for a postback.
It's of course possible to use a tool like FireBug to edit the URL in the form tag before the postback, but then you probably don't want the value that the user injected anyway, but the original value.
As others have pointed out, The URL is not expected to change. Of course if we lived in a perfect world you would never get email spam and noone would ever attempt to do anything malicious to your website.
In the real world you should expect that malicious people will attempt to hijack your website and need to be concerned with things like injection attacks
You should never make any assumptions that the data received on a postback is valid.