I have a line of code in my view which looks like the following:
<button id="show-Lookup" class="inithide" name="show-Lookup">Lookup</button>
It crashes when it gets sent back to the controller on form submit with the following error:
"A potentially dangerous Request.Form value was detected from the client show-Lookup="
When I analyze the the value of show-Lookup in the debugger I see the following:
Request.Form["show-Lookup"]
Lookup
Where is ASP.net MVC getting this from? This shouldn't have a value?
This has nothing to do with MVC; it's basic HTML. Anything with a name can be considered for inclusion in your form, subject to certain restrictions (see the spec). If you don't want it in the form, get rid of the name.
A <button></button> is submitted with the form. Different browsers treat this slightly differently - IE sends the value of whatever is between the opening and closing tags (the button "content") while other browsers send the value attribute.
Note too that the behavior of your button will vary by browser unless you specify it. In IE (prior to 9?) a <button> element is type "button", while in other browsers it is "submit". (This is the W3C spec, too.)
on contoller add this attribute
[ValidateInput(false)]
One thing i would like to suggest, just dont use above code if you are not sure of what you are doing. The above code wont let server validate the input it received from form.
That means, if a user in ur form types his name like "alert('hacked')", your controller will receive that value as it is. And if you just add it in DB and displays it some where then its disaster. User may type fully qualified javascript to make ajax requests.
Another way to solve this problem is just remove the attribute name from button, as its not solving any purpose.
Question:
When I analyze the the value of show-Lookup in the debugger I see the following: Request.Form["show-Lookup"] Lookup
Where is ASP.net MVC getting this from? This shouldn't have a value?
You are seeing this value as you have added the attribute name to button, since you have added the attribute, browser is sending that property too to server.
Related
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 thought you couldn't change the QueryString on the server without a redirect.
But this code works* for me:
Request.QueryString edit
I'm so amazed.
So here are my questions regarding this:
Why is Request.QueryString readonly?
Why does this code/hack work*?
How safe is it, if you change to readonly as soon as you are done editing, both regarding bad errors or unexpected behaviour, and regarding maintaining and understanding the code?
Where in the event cycle would it make most sense to do this crazy edit if you are only using PageLoad and OnPageRender?
*More details:
I have a page with items that are grouped into tabs. Each tab is an asp:LinkButton
I want to be able to link directly to a specific tab. I do that with a QueryString parameter 'tab=tabName'. It works. But when I then click a new tab, the querystring is still in the Url, and thus the tab specified in the Querystring gets activated and not the one I clicked.
By using Request.QueryString edit this does not happen. Then my solution 'works'.
Thanks in advance.
Well the QueryString property is readonly because it cannot be changed on a single request. Obviously the browser sends only one request with only one string so only one collection is created. The hack uses reflection (i.e. manipulates the code and the memory) to change stuff that you cannot change normally. This hack breaks the encapsulation and the design of the QueryString property. You should not use it. It makes no sense from design standpoint. Your query DOES NOT change so why change the object that represents it? Only the browser can send new query string so you are basically lying to your own code about what the browser sent.
If you want the tabs to use the URL just use Hyperlinks instead of LinkButton.
From what I remember reading, this is a security standard that all browsers adhere to. It's main purpose is to stop phishing attacks, where someone could have the website www.MyLameWarcraftPhishingSite.com" and when someone hits the page, rewrite the url to look like www.blizzard.com. The only way to get to that url is to actually redirect to it.
mmm, last post was in Feb 11 - hope its ok to post in this.
If ASP.NET Request Validation is enabled for a site, do you still need to HtmlEncode and HtmlDecode string information to and from simple forms (e.g. ASP Textboxes)?
If ASP.NET Request Validation is enabled for a site, do you still need to HtmlEncode
ASP.NET Request Validation is a hack to try to work around stupid authors' broken programs. Don't write broken programs.
Any text string you write into an HTML page must be HTML-encoded; this is a matter of correctness, not just security (which is a subset of correctness). Even if Request Validation could magically remove any possible XSS attack (and that is so nothing like the case), failing to HtmlEncode text output would still leave you open to producing malformed output, mangling your data. Say I was making a forum post talking about some variables a, b and c and wanted to say:
a<b b>c b>a
If that was echoed to the HTML source unencoded, I'd get:
ac b>a
and maybe the rest of the page would be bold too. Whoops!
Request Validation is bogus and shouldn't be relied upon. Being on by default and “recommended for all production environments” is sad and makes me seriously doubt the sanity of the ASP.NET team.
If you have written your program correctly, you don't need it and it will just get in your way. (For example, if SO used it, I wouldn't be able to make this post that mentions the <script> tag.) If you haven't written your program correctly, Request Validation isn't going to fix your security holes, it's just going to make them a bit more obscure.
and HtmlDecode string information
You don't usually HtmlDecode anything in a web app. You encode to push content out into HTML, but when content comes back in from a submitted form it is as plain text, not HTML-encoded.
to and from simple forms (e.g. ASP Textboxes)?
Textboxes should be fine; setting their .Text does do any necessary encoding, making the exact string you had appear in the textbox. But. Some things that look like they should be HTML-encoding automatically actually don't. For example:
myTextBox.Text= "a<b b>c"; // Fine!
myLabel.Text= "a<b b>c"; // Broken!
Oh dear. Text does not always mean Text. Sometimes, it actually means HTML. Thank you Microsoft, way to muddy the waters of a topic too many people already find hard to understand.
There's no danger from text in ASP.NET text boxes, whether Request Validation is on or off. The text box control automatically encodes data when displayed in the text box.
When outputting data that originated from the user in other places, it is important to HTML (or JavaScript) encode that data. ASP.NET's Request Validation provides only a minimum level of protection. It is not impenetrable, or even close to it. It is only designed to protect against the most simple attacks.
You still have to encode things as you output them on other parts of your site.
Edit
What I mean by other places, is that if the user enters the data into a text box, using the ASP.NET Text Box control is safe because the control automatically encodes the output so it will render safely.
Say, for example, you're working with StackOverflow's user info page. When a user chooses their username they could choose to input something that may be malicious when output in another part of your site. For example my StackOverflow login name is displayed at the top of every page for me, and is also listed on the "Users" page.
On the Users page, AJAX is used to load users. When JavaScript goes to evaluate the user name, it is not bound by the same encoding rules as HTML tags, so I could type something into the user name text box that could cause some breaking behavior when it is output in the User list.
StackOverflow obviously encodes user data correctly when sent to the client, so they're safe. Before sending my user name off to the client, they (presumably) have some JavaScript encoding routine that makes sure that my user name can't become malicious when executed in JavaScript code.
You could also have problems if using it in a non-ASP.NET input control. Input tags use attributes to define content, so you can easily enter text that would get past the Request Validation check but could allow the user to add a malicious "mouseover" attribute.
In ASP.net Webforms how do you detect which Textbox someone pressed enter?
Please no Javascript answers.
I need to handle it all in the code behind using VB.NET.
Why do you need to determine the which TextBox was pressed? Are you looking to see which TextBox was being focused so that you can trigger the proper button click event?
If you are looking to do something like this, one trick I've done was to "group" the appropriate form elements within their own panel and then set the "DefaultButton" property accordingly.
Doing this allows me to have a "Search by Name", "Search by Department", "Search by Id", etc. Textbox/Button combination on a single form and still allow the user to type their query parameter, hit Enter, and have the proper search method get invoked in the code behind.
I suspect it cannot be done without javascript - when you hit enter, the browser submits the form - it doesn't submit what field had the focus. So unless you use JS to add that information to the form being submitted, you're out of luck.
Without using Javascript, you just can't. That information is not conveyed from the client browser to the server.
As far as I know there is no possible way for a server side script to detect that. It simply does not get sent to the server. It must be done client-side (i.e. With Javascript) and then sent to the server.
I solved this for one site's search by looking at the Request.Form object, server side to see if the search box had a value. I did it in a base class that all my pages (or a base class for the masterpage) inherit from. If it has a value, the odds are pretty good somebody typed something in and hit enter and so I handled the search.
In the event handler, the "source" object (the first parameter of the event handler) is the object raising the event. Type it to button and get the name, or use reflection to get information out of the non-typed object.
In addition, if the control is a child of a web control that you do not have raise its own events (just saying...) then you can use OnBubbleEvent to determine what's going on. OnBubbleEvent also has a "source" parameter you can type, or use reflection on.