I need to store data from a web page. There are many (80~100) input controls and I need to validate as submit the form as well. What would be the best practice, either get value one by one from every control or something better else?
That depends: when there are simple rules by which you validate your fields like checking phone numbers etc., you should do it client side before submitting. If there are some more complicated rules (or sensitive data neccessary for checking that you cannot expose to the user's browser), you should submit everything and validate server-side.
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.
I'm working on a WebForms application that consists of a number of pages and each page contains a form which the user fills out. Each form corresponds to a part of an entity meaning that the data from one page/form populates a part of the entity's fields or its child entities' fields.
As an example: a Person's name and birth data is filled out on first page, health status on second page, family information on third page etc.
The data should of course be valid before continuing to the next page. My customer doesn't want to deal with jQuery or Javascript so this is ruled out. What is "best practice" for implementing validation in this case?
Entity Framework 4 is being used and most of the GUI controls are implemented in HTML and not by WebForms controls.
If you're using custom HTML for your inputs, then you're probably going to have to use some custom code for your validation. In your server-side form handler you can validate the inputs and render the page back to the user if something was invalid. The input checking could be as simple as:
if (string.IsNullOrWhiteSpace(FormCollection["someRequiredInput"])
You can iterate through all of your inputs, check them according to business logic, and perhaps build a list of errors. Then after the input checking, if the list of errors isn't empty, render the page back to the user with the errors added to a placeholder of some kind. If the list is empty, continue processing the form post.
Even if JavaScript wasn't ruled out, you'd still want to perform server-side validation. Never assume that the client-side code worked as intended or was even executed at all. Client-side validation isn't a security measure, it's just a better user experience. Server-side validation is the only real validation.
(So you may still be able to add client-side validation for that added UX touch, and if the client does indeed disallow JavaScript then they wouldn't see that and would just use the server-side validation instead. This is sometimes referred to as "graceful degradation" where you design a web application to still fully function, albeit with slightly less UX goodness, when the user disables client-side technologies.)
My customer don't want to deal with jQuery och[sic] Javascript so this is ruled out.
Good. Javascript is the wrong place to enforce validation. Any validation you do with javascript is merely a performance optimization. The only acceptable place to truly validate data is on the server.
That out of the way, .Net includes some handy Validation controls you can use. One of those controls is a CustomValidator, that is very easy to override and provide your own server-side code to enforce whatever rules you want. If you're using webforms, these controls are an obvious choice.
Since you have a multi-paged approach, you may also want to look into the Wizard control.
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'm trying to get some User Controls I'm writing to perform their own server-side validation, checking the database to ensure that certain criteria are valid. In one case the control doesn't even accept any input, it just displayed some information based on database state.
I know the ASP.Net has its own validation framework, and I'm keen not to re-invent the wheel. However, I'd like the controls to check whether they're valid themselves (that seems more object oriented to me), rather than having to create custom validators on every page on which I place the controls. I've had a quick look at the IValidator interface, but this seems to be targeted at Validators, rather than the controls themselves. It seems cleaner to me to have the control itself check the entered data (where appropriate) and database state and report whether or not it is valid.
Is this possible in ASP.Net without re-writing the whole of the ASP.Net validation framework, or am I just trying to go about this in completely the wrong way?
It turns out I was close with the IValidator stuff, just missing the link to the Page.Validators collection. Here's a fully worked example:
http://www.codeproject.com/KB/custom-controls/selfvalidatingtextbox.aspx
Hard to believe how much time I spent looking for this yesterday!
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.