I'm writing an application that accepts form posts for a knockout/jquery mobile application that later users can pull down the posted data and view what was filled in on the form.
A user could potentially put html or script tags in an input. Right now it appears that when the data is brought down and put back into the form any html tags or scripts are displayed in the inputs and everything is fine. Even labels that have html seem escaped correctly and do not actually display as html.
but how can I be sure that if a user inputs some html in a form input like
<h1>Show This</h1>
That when it is displayed in the form later it doesn't actually mess with the display of the form or run a script tag or something.
Does Web Api or Knockout provide any sort of automatic encoding where this is mostly covered to prevent this scenario?
The text binding in Knockout will escape the value by create a text node and populating it with the value.
The html binding, on the other hand, would not do this type of escaping and could potentially execute code, so you would not want to use it with user entered input.
Related
I know this has been asked several times, but I'm not happy with the answers so far.
Root problem is the way the browsers detect a "login form" to auto-fill the fields and decide if they should ask the user to save the info. It works fine if your form has just the basic login fields. If the same form has lots of other fields, the browser doesn't detect it as a login form.
The solutions I've seen say to use a separate non-ASPX form on your page. In my case all of my input fields are rather complex subclassed versions of ASPX controls, mostly to get stuff like a custom background image and nice handling of place-holder/watermark text and items of that nature. So trying to create a non-ASPX form is a lot more work since I can't use these controls on the form. I'd have to replicate them in standard HTML. I could do this, but would rather not. Plus it's more maintenance anytime I need to make a change.
Is there a better way? That lets me use all of the greatness that is ASP.NET.
My page has both a login area and a register area (name, email, DOB, etc). This is why the browsers are confused.
I seem to recall when I was writing a website for mobile browsers that there was some markup that could be used to tell the browser "this is a login name field, and this is a password field". If something like that was available, that would be perfect.
Maybe I could do something with an iframe? Like an ASPX page inside an ASPX page?
Despite the complexity of your code, any custom ASP.NET user controls will eventually render output as HTML and every browsers only speak HTML
What you 're looking for is how to write ASP.NET code that results HTML mark-up containing the simple attribute..
<input type="password" autocomplet="off" ...
So that all browser will able to recognize it's a form containing password field. It doesn't care what you do in code behind. Focus on the output.
I have a basic form for submission in a detailview aspx page.
On of my textareas contains html code <br>. Whenever I try to do an insert, it fails, and I get a generic:
The status code returned from the server is 500
I know the issue is the html code offending <br> because when removed, it inserts fine.
Is there a setting for the templateview for this field to allow html tags be allowed on the insertion?
Any pointers appreciated!
Any HTML in a textbox in asp.net web forms (assuming web forms) will cause this error. You need to encode it in JavaScript, set the ValidateRequest property on the #Page attribute to false, or use some other utility (there are some out there, don't know of a specific one, maybe the HTML agility pack?).
In your Page Declaration ensure that ValidateRequest="false"...beware, this opens you up to XSS, Cross Site Scripting.
Ensure theat you encode the Data from the textarea before sending it to your Database, then when you return it to display, you'll Decode it.
From Microsoft.
**Encode Output
Use the HttpUtility.HtmlEncode method to encode output if it contains input from the user or from other sources such as databases. HtmlEncode replaces characters that have special meaning in HTML-to-HTML variables that represent those characters. For example, < is replaced with < and " is replaced with ". Encoded data does not cause the browser to execute code. Instead, the data is rendered as harmless HTML.
Similarly, use HttpUtility.UrlEncode to encode output URLs if they are constructed from input.**
http://msdn.microsoft.com/en-us/library/ff649310.aspx
I am creating a website that will offer the option to email the user a copy of dynamic, code-behind, calculation-driven content on a final page of a website. To send an email as of now I obtain the calculation values from the model object again when the user clicks the button, writing all HTML tags by hand, sticking the model data in where needed.
My question is: is there any easier way to copy website output to an html formatted email? I currently code an HTML email by hand and would like the ability to just get a copy of the rendered HTML, and possible modify it from there.
The easiest way (at least for me) is to actually create a webpage that does everything that you want it to do and then scrape it using System.Net.WebClient or System.Net.HttpWebRequest.
So you've got Page1.aspx which allows a person to select some things and submit a form and then you've got Email1.aspx which is the final output. When Page1.aspx is submitted use WebClient to download the contents of Email1.aspx, probably passing a querystring or some cookies over if needed. The user never "sees" Email1.aspx (except in their email of course), its just used behind the scenes.
The advantage of this approach is that you can test the HTML output without having to jump through SMTP hoops. In the Email1.aspx page you could also override the OnRender() method (I think that's the one, might have a different name possibly) if you need to modify the HTML. Or you could modify the HTML after downloading it. If you're performing the same basic HTML modifications you could subclass System.Web.UI.Page, implement your custom rendering and then have all of the emails inherit from your new subclass.
One thing that's important to remember, going down this route creates an HTTP request that's completely separate from the user's request, so things like session and cookies aren't passed over automatically, you'll need to find a way to do that on your own.
You can access the final ready-to-render html using the asp.net
Response.WriteFile("filename");
method
So, when i was dealing with forms before what i would do is find web element that is part of the form input, set value of that form input by element.setattribute("value", "infoi want to add")
then simply when i set value of form elements i click submit button of form.
Is this possible to do with web-form input type="file" and how can i do it?
Thanks
The simplest and the most straightforward way to do exactly what you've described is to get form's target address with QWebFrame::hitTestContent and then to post a file with QNetworkAccessManager::post. You also could inject some javascript code into a loaded page (see this for more details), but that would be an overkill for such a simple taks. And besides in the latter case all your injected javascript will be gone after submitting the form (i.e. after the page is reloaded).
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.