I've got a DropDownList and I'm trying to prevent it from being used as an attack vector. Can I assume that the user is unable to actually change the values of the DDL and postback to the server? At the moment, I get this ASP.NET error message thrown if I try and change the packet after submission:
For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them.
Am I right in thinking that this is due to the integrity being compromised in the viewstate hash? Can this be bypassed?
Thanks
Actually you should be able to assume that the dropdown list options have not been changed client side as long as the page has EnableEventValidation = true (which is default although you can disable it per page or in the web.config). If a new value is added to your dropdownlist client side, and a postback occurs an error will occur unless you register this new value for event validation (http://odetocode.com/blogs/scott/archive/2006/03/21/asp-net-event-validation-and-invalid-callback-or-postback-argument-again.aspx)
No, you can't assume that.
You should always consider that all input is untrusted, and treat it appropriately (make sure it is what it should be, and that it is of the right type, and that the current user (or whatever) has access to it, and so on).
Related
My previous impression of RequiredFieldValidator and similar have been that they show you an error label and set Page.IsValid false and that is it. Meaning they leave the rest of the task (preventing the use of wrong input data) to you. But today I have realised say if you use a DetailsView to insert a new record to a database, and you use validators to check the TextBoxes inside the DetailsView, they automatically prevent the database from being updated.
I would like to know how this is implemented behind the scene. I'm guessing it aborted the Page Lifecycle at Validator.PreRender event, so that database connections at later stage could not be reached? I'm probably wrong.
I'm trying to use Reflector to get inside the RequiredFieldValidator to see how it is implemented, but I don't really know where to look. Can someone give some hints?
This article explains the validation in detail for ASP.NET.
http://msdn.microsoft.com/en-us/library/aa479045.aspx
Validation can be both Server side and/or client side. If used, client side validation doesn't let user submit the form until it is validated. Client side validation is implemented using JavaScript and DOM. Every submit button is wired by the framework to check validation before doing post back.
Server side validation works differently. The event chain is extended between page load and event procedure call. The validation results are set, which can be interpreted by any event procedure.
In your situation I guess you have client validation on - which it prevents Form from being submitted to server and that's why no actual update to database is done.
EDIT: DetailsView control does support server side validation controls. Follow this link for details http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.detailsview.aspx#security
I'm populating a DropDownList using JS on the client and validating with a RequiredFieldValidator.
This works fine on the client but the Page.IsValid consistently comes back false on the server.
Is this because the selected value wasn't in the DropDownList when it was first served to the page?
What's the easiest way around this? (I need to leave server validation turned on)
Is this because the selected value
wasn't in the DropDownList when it was
first served to the page?
Yes. You'll probably notice that your dropdownlist will contain no items when you do your postback, and yes, this is because you're adding your items on the client side. Any items that you add to a control on the client are totally unknown to the server. Therefore, your server validation will always fail, since that field is required.
In fact, adding items dynamically with client script will trigger EventValidation to complain that there is a possible security problem, and you'll have had to set EnableEventValidation to false in your <%# Page %> directive to be able to post.
The best way around this is to either
Generate your items on the server side, or
Not use a server control for this (use a regular non-asp.net select list) and manually validate it on the server by looking at the posted values.
Rather than using the Session object or storing to the database, I am storing temporary variables that I need persisted to custom ViewState variables. For example, ViewState("MyField1") = 1
When the user hits the browser Rrefresh button, Page.IsPostback is back to False and the ViewState is gone.
My question is. If the user can blow away the Viewstate by refreshing, why would anyone use it?
I know that a Refresh reposts the last submitted page, by why is Page.IsPostback reset to False and the ViewState blown away?
Flame me if you want for creating a potential dup question, but I've read other postings here, and it ain't sinking in...
Update to original post:
I now think that it has to do with postbacks that are performed as a result of clicking on Buttons that are within an UpdatePanel. Can someone help shed some light on this?
When a client refreshes their browser, it re-submits the last full page request issued by the client (which may be a GET or a POST). It does not ever resubmit AJAX requests such as those produced by update panel event triggers ("partial page postbacks").
The fact that Page.IsPostback is false when you refresh the page means that your original request is a GET, so here's what's probably happening:
1) During the initial request, the client sends no form data to the server - hence no hidden field containing view state data (Understanding ASP.NET View State is pretty detailed, but a great read if you want to really understand what's going on). While processing this request, ASP.NET may send some view state back to the client, but the original request is just a URL.
2) When the user clicks a button within an UpdatePanel, they trigger a partial postback during which MyField is set to 1. The UpdatePanel changes the client's view state to reflect the new value.
At this point, if the user submits a POST request by normal means, such as clicking a button, the view state will contain the updated information.
If the user clicks 'Refresh' though, they re-submit the original request from step 1, with no form data and therefore no view state.
Where do you set your ViewState? And where do you re-read your ViewState value? Maybe oyu check its content before asp.net calls the LoadViewState() method.
User hitting refresh and using updatepanel will not work together very well. I quess this is why people say that WebForms provides a leaky abstraction on web programming and some are moving to mvc.
If you're not interested in migrating, I'd give you the advice that do not use updatepanel for too long or big operations, where you can assume that user might refresh the page. Use it for small things like dropdown2 items changing when selection on dropdown1 changes.
Wrapping lots of functionality in one updatepanel will cause trouble, if you just depend on viewstate.
Your question is, "Why would anybody use it."
Viewstate comes in handy for data you know is generated by a post back. Hitting refresh is not a post back, but a fresh request.
So lets say you are browsing a datagrid and you need to know certain bits of data about what they have clicked, on the click event you could store that data in the viewstate and process it during other times in the page life cycle, or subsequent post backs.
ViewState's advantage is that it is just embedded into the HTML, so it is all client side. Where as SessionState is server side, and if you store a great amount of data in the session you can cause your web or db server to work harder to handle that data.
Hope this helps.
Don't know why it works but I had a similair problem and solved it by putting this line in the form_load:
me.myProperty = me.myProperty
where
Public Property myProperty() as String
Get
If Not IsNothing(ViewState("data")) Then
Return CType(ViewState("data"), String)
Else
Return String.Empty
End If
End Get
Set(value As String)
ViewState("data") = value
End Set
I have user control on a ASP.NET web page, which contains a GridView and a radio button selector.
In the underlying middle tier I have a thread which goes to the database and then raises an event to say "I have some data" my User control handles this event and sets a Session Variable.
This works and I can see the event being handled and the Session variable gets the new data.
However when i go to use this session variable when the selected index of the Radio button selector changes the Session variable reports as "Nothing"
I have ensured that the obvious (i.e. spelling, Sessions switched on etc) are correct.
The GridView and radio button selector are encapsulated in the same Update panel.
Check that if your UpdatePanel - updatemode is set to 'Conditional'? also Child as triggers? I would first start by putting a stop in your page load, see whats happening from there. Do a search for all places where you populate that session variable and put a stop. You may be surprised, I have often found that page lifecycle gets confusing even though I thought I understood it. Alt - post some code and we can step through.
Yeah, sounds almost like a problem with order of operations or not checking for postback on a page load or something?
Like JamesM suggested, running your website in debug mode should really help identify the problem. You can bring up your watch window and set it for the Session variable you're looking for, then set breakpoints all over and check the value at each stop to divide and conquer the code.
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.