Hi I get this error when i hit the submit button on a user login form because there is a repeater on the same page with is repeating html which is being posted back with the form content. apart from applying ValidateRequest="false" to the login usercontrol is there anything i can add around the repeater to stop this?
When you set ValidateRequest to false all kind of dangerous characters are accepted as parameters so you must make sure to properly HTML encode them if you intend to redisplay this user input.
If for some reason you can't HTML encode the text:
1) In the repeater, render the dangerous text inside HTML elements that don't get posted, like <p> or <span>.
2) If you absolutely must render the HTML inside <input> elements, disable those elements and so your page doesn't submit them.
I answered how to allow this here:
"<" in a text box in ASP.NET --> how to allow it?
basically by escaping the HTML just before the post
Related
I have a page with a repeater containing RadioButtonLists which have requiredFieldValidators attached to them. I need to keep the RFV next to the control (it's the only way I can get it to work to be honest!)
However, the form is made up of a few sections contained in an accordion. This means that when the form is submitted, the item that has failed validation may not be visible, so the user won't know where the error is.
Is there a way I can also have a message by the submit button which is triggered by an RFV changing saying "please go back and check your answers" or something? I guess I'd need to use JQuery / JavaScript as it would be clientside.
There is a special ValidationSummary control for that:
<asp:ValidationSummary ID="Summary" runat="server"
DisplayMode="SingleParagraph"
HeaderText="Please go back and check your answers" />
This control is used to summarize all validation errors on the page.
Try "ValidationSummary". look for example from here.
http://www.w3schools.com/aspnet/control_validationsummary.asp
I tried using Page.ClientScript.RegisterStartupScript to place HTML or invisible elements at the bottom of my page and this seems to be working fine. Is there anything wrong with this as the RegisterStartupScript was intended for JavaScript only?
<asp:ContentPlaceHolder> is the correct control to use to "place HTML or invisible elements at the bottom of my page"
The problem you'll most likely encounter with this approach is that when using the UpdatePanel, you should be calling ScriptManager.RegisterStartupScript() instead. This will depend on the structure of your page (eg, are you registing the script from within a UserControl), and what your javascript is doing
What you've done is not something to be taken as a best practice, but I believe it should not cause you any problem. What the ScriptManager and the ClientScript do, is just append the specified content to the output HTML that is going to be sent to the browser.
However, you can consider to achieve this by placing place holder control at the bottom of the page and then append your HTML content to that holder.
I have a page that does not have runat="server" set in the <head/> section. I do not have access to modify any of the code in the page.
This page contains a user control which I do have access to. Can I add a <meta/> tag to the head section of the page from the user control? It needs to be server-side so a javascript solution won't work.
One option is to create a Response Filter, and then modify the output before it's sent to the user.
https://web.archive.org/web/20211029043851/https://www.4guysfromrolla.com/articles/120308-1.aspx
You can parse the text in
(this.Page.Controls[0] as LiteralControl).Text
to see where the string <head> starts, and insert whatever text you need in there thus injecting your own code into the page header without it being marked with runat="server".
Please be aware though, this is pretty hacky way of getting your code where it most likely shouldn't be (otherwise the <head> element would have been marked as runat="server" so you can access it normally). This will also break if at a later date the head element is changed to be an ASP.NET control. It might will not work with master pages, you will have to walk up the control tree looking for topmost literal element.
I have a requirement that user can input HTML tags in the ASP.NET TextBox. The value of the textbox will be saved in the database and then we need to show it
on some other page what he had entered. SO to do so I set the ValidateRequest="false" on the Page directive.
Now the problem is that when user input somthing like :
<script> window.location = 'http://www.xyz.com'; </script>
Now its values saved in the database, but when I am showing its value in some other page It redirects me to "http://www.xyz.com" which is obvious
as the javascript catches it. But I need to find a solution as I need to show exactly what he had entered.
I am thinking of Server.HtmlEncode. Can you guide me to a direction for my requirement
Always always always encode the input from the user and then and only then persist in your database. You can achieve this easily by doing
Server.HtmlEncode(userinput)
Now, when it come time to display the content to the user decode the user input and put it on the screen:
Server.HtmlDecode(userinput)
You need to encode all of the input before you output it back to the user and you could consider implementing a whitelist based approach to what kind of HTML you allow a user to submit.
I suggest a whitelist approach because it's much easier to write rules to allow p,br,em,strong,a (for example) rather than to try and identify every kind of malicious input and blacklist them.
Possibly consider using something like MarkDown (as used on StackOverflow) instead of allowing plain HTML?
You need to escape some characters during generating the HTML: '<' -> <, '>' -> >, '&' -> &. This way you get displayed exactly what the user entered, otherwise the HTML parser would possibly recognize HTML tags and execute them.
Have you tried using HTMLEncode on all of your inputs? I personally use the Telerik RadEditor that escapes the characters before submitting them... that way the system doesn't barf on exceptions.
Here's an SO question along the same lines.
You should have a look at the HTML tags you do not want to support because of vulnerabilities as the one you described, such as
script
img
iframe
applet
object
embed
form, button, input
and replace the leading "<" by "& lt;".
Also replace < /body> and < /html>
HTML editors such as CKEditor allow you to require well-formed XHTML, and define tags to be excluded from input.
I have a series of controls on an ASP page. Some are inside an UpdatePanel and some are not.
If I put an XML tag in one of the text boxes (eg, "<foo>") then all the controls within the UpdatePanel don't work. As soon as the tags are removed, everything is fine.
My 'submit' button is in the UpdatePanel and the breakpoint on btnSubmit_Click is only hit when there aren't tags in the text boxes.
I'm a long-time C# dev but quite new to ASP.NET so might be missing something obvious... this just isn't the behaviour I expect.
If you were to take the UpdatePanel off the page, you'd find that the postback was causing an error because .NET thinks that "<foo>" is a potentially dangerous bit of data to accept at the server. See this question on StackOverflow. You don't see the error because the error page HTML is being returned to the UpdatePanel's ajax call rather than direct to you browser, and the UpdatePanel doesn't know what to do with it.
You can turn off the checking by adding
ValidateRequest="false"
to the <#Page ... > directive at the top of your aspx file. Or you can modify the web.config to get the same effect right across your web app.
You can't put markup in a textarea. You must HTML-escape any markup characters inside textarea just as you must with any other element.
<textarea><foo> & <bar></textarea>
Although in practice browsers will usually work out what you mean and show any < characters as-is, it's still invalid HTML and non-well-formed XML (presumably this is also the root of your issue in ASP.NET, though without specific code it's difficult to tell).