Why do we need both client side and server side validation ? i have read that both are necessary for security reasons.. so if client side validation can be bypass then why not use only server side..what is the use of using client side..
It is important for users with slow/restricted/limited internet connection to avoid unnecessary request to the server (e.g. request to submit a form containing invalid data, which will eventually get rejected by the server). The waiting time for the response may become a reason for a user to leave your web page, and then talk bad about your web site to friends and relatives, or even to whoever.
We always want to make all users happy, don't we (even though sometimes we feel that they are the enemy)
Client side validation helps the user to correct the errors without a full postback with all error messages in it. It enhances efficiency, but its just a convenience and can obviously be bypassed.
it's not good practice postback for every validation so you will need to put client side validation to validate fields which are mandatory so you should put client side validation also
About Server side validation, you cant realy compltetly on client side in case browser javascript disabled it is better to be validated at server side.
With client-side rendering, your initial request loads the page layout, CSS and JavaScript. It's all common except that some or all of the content isn't included. Instead, the JavaScript makes another request, gets a response (likely in JSON), and generates the appropriate HTML (likely using a templating library).For subsequent updates to the page, the client-side rendering approach repeats the steps it used to get the initial content. Namely, JavaScript is used to get some JSON data and templating is used to create the HTML.
Updates using server-side rendering is where a lot of developers start going off the deep end. They actually think page refresh
Both client-side and server-side are needed for many reasons. i am writing few points that will explain why it is necessary
for every from validation a request sent from web browser to the web server. so it is a unnecessary overhead to the server for checking every control to validate. suppose 1,00,000 people sending the same request to the server. For every request and response it will take some time(may be in nano seconds) which is really unnecessary. so it is recommended to use client-side validation.
For security reason we must use the server-side validation. As a programmer it is responsible to stop the bad data coming to our application. suppose in browser someone intentionally or by unknowingly disable the JavaScript and trying to insert the data. if server-side validation is not present there bad data can come to our application. Data may be some wrong information or it can be a self executed program also which is really harmful for our application.
so it is recommended to use both client-side and server-side validation for a better standard application.
You don't need client side, but it's much more convenient for the user if a post-back isn't necessary. If you don't care about the UX, you can make all of your validators server-side only and your data and operations will be protected.
Related
I am a newcomer developer to ASP.NET.
I wonder that is running forms on server (namely runat=server) the right way of coding ? I feel that all of scripts, forms etc. must run on client side because server side runnings may cause bottleneck on server side.
So what kind of advantages/ disadvantages
-running on server side
-running on client side ?
Yes, that runat=server means that ASP.Net does some processing on the server side.
This processing means that
You have an object model you can use in your code, to access properties of your controls and event handlers (such as an OnClick for the various Buttons)
The (possibly complicated - see grids) HTML is generated to be sent to the client (=browser)
The real form/script etc does run on the client. Validations run both client-side and server-side.
I think this link will give you a good understanding of the difference. difference between server and client controls There are plenty of explanations out there if you just Google
If I have a intranet application and am doing both client & server side validation - should I be designing the server side validation (which is done mainly for security reasons) to have a similar look to the client side validation?
I suppose what I am asking is: does server side validation need to really return proper error messages at the field level? Or can it simply reject the page, as the user should be using javascript in a modern browser? (I am using Kendo for client side validation which will work in major browsers).
Is this a strategy sometimes performed, or is there reasons for having the server side validation be useful in a visual sense? If so, what's the reason for this, and does it change if the site is public facing?
Thanks!
I think there are definitely instances where you will want your server side validation to be as user friendly as your client side validation. Imagine a common scenario where your user has to input some login details. You can validate some of this client side - the email address is properly formatted, for example - but from a security point of view you would want to check that the login information is correct on the server, and if the password isn't right then you need to pass a friendly message back. Rejecting the whole page in this case would be OK but that doesn't tell the user where they went wrong.
What client side validation does is allow you to cut down on the amount of server side validation that you need to perform. Checking that certain types of input - mandatory fields or phone numbers - are correct is a lot quicker to do client side and this adds to the overall user experience. It's also becoming technically much quicker to add client side validation; it's pretty well embedded into HTML 5 and there are a number of great jQuery libraries. But friendly server - side validation will always have a place where security is a requirement.
I was wondering if there is any way to always run some server side code when a user leaves a page in ASP.NET. The page Unload event is no good because that doesn't get called if someone clicks on a link. Ideally I'd also like the code to run even if the user closes the browser.
I suspect what I'm asking isn't possible, but it doesn't hurt to ask
Problem is, HTTP is a stateless protocol, so when the page has finished being served, you wont know if the user is still on the page or not.
The only way to acheive this would be a hidden piece of Javascript that constantly pings the server with it's session ID, or another similar mechanism. When the ping becomes unresponsive you can reasonably assume the page is not being viewed by the user anymore.
Here is a diagram that explains traditional HTTP message flow.
im not really sure if you can do that but i have a workaround in mind.
There is an event in the DOM called onbeforeunload. it get calls everytime a user leaves a page. you can try sending an ajax request to the server from this function.
The closest thing you can come without creating too messy a solution is to enable ASP sessions. This will create a session on the server for each visitor, who will be identified by a cookie.
After a certain amount of inactivity from the visitor, the session will be closed, and a SessionEnd event will be raised. This you can hook up to in the Global.asax file.
I will not recommend this however, because HTTP is pr. definition a session-less protocol, and using server based sessions violates this fact, and are often problematic. Many solutions that use server based sessions run into problems when the user uses the browser-back button, and resubmits a form. Because the content of the submitted form no longer corresponds the data that exists in the server session.
Also, enabling server based sessions seriously hurts the scalability of the application.
Not that I know of. You'll need to use javascript for that, and call a web service on the server side.
I am using jQuery with ASP.NET in a project. Instead of using ASP.NET Ajax, I am using jquery's ajax functions. Is there any security risk if I do that? I mean, since I am using jquery's ajax calls, no view state information will be passed to the server so that it can verify the page's authenticity (though it saves a lot of bandwidth..).
I would also like to know what is the best/good practice here.
Microsoft has included Jquery in their Visual Studio releases (see: http://weblogs.asp.net/scottgu/archive/2008/09/28/jquery-and-microsoft.aspx)
If there was a big security risk they probably wouldn't have done that ;)
As with al webapplications never trust the input you recieve. It doesn;t matter if you're working with ASP.Net AJAX, Jquery or any other library. Web requests can always be spoofed. Therefor always sanitize the input you recieve and make sure that the user is authenticated (ASP.Net forms authentication uses cookies and not viewstate).
Make sure that you validate all user input. And post basic authentication information to your Web Services (jQuery.ajax has a data parameter), so that no one can use the services without being a part of the system.
Passing along a session GUID and thus providing the Web Service with full authentication, is enough security for most applications (in addition to normal security checks such as input validation). You may specify closer what security level your application needs.
I use the same practice on many case - jQuery ajax on aspx pages
You can check 3 thinks (select 1-2 of them) and be sure that none can create troubles on your site.
Send all the post data encrypted (if you can).
Send hash value with the post data - and check for the correction of the hash (if you can).
Check that the calls is coming from your host on url.
eg, you have a page 'http://www.yourhost.com/askforajax.aspx',
check if the url starting with the 'http://www.yourhost.com/'
The hash I mean here, must be your implimation of hash or crc check or what ever you like you can call it.
here is a real ajax call from my pages
doSomeWork.aspx?plist=36&pslst=1&e=1202638085&er=12585795
The last 2 parametres are check parametres.
Also inside the the ajax page that make the calculations check every parameter for be correct.
I also check some other thinks in some cases, for example if a user press a button that make a change somewhere this user must have cookies enabled, so I check if the users cookie hash is the same.
For the url check
I belive that the Request.ServerVariables["HTTP_REFERER"], can do the work of checking from where the request come from.
HTTP_REFERER Returns a string containing the URL of the page that referred the request to the current page using an tag. If the page is redirected, HTTP_REFERER is empty
Hope this help you.
Is there a "clever" way of stopping direct page calls in ASP.NET? (Page functionality, not the page itself)
By clever, I mean not having to add in hashes between pages to stop AJAX pages being called directly. In a nutshell, this is stopping users from accessing the Ajax pages without it coming from one of your websites pages in a legitimate way. I understand that nothing is impossible to break, I am simply interested in seeing what other interesting methods there are.
If not, is there any way that one could do it without using sessions/cookies?
Have a look at this question: Differentiating Between an AJAX Call / Browser Request
The best answer from the above question is to check for a requested-by or custom header.
Ultimately, your web server is receiving requests (including headers) of what the client sends you - all data that can be spoofed. If a user is determined, then any request can look like an AJAX request.
I can't think of an elegant method to prevent this (there are inelegant and probably non-perfect methods whereby you provide a hash of some sort of request counter between ajax and non-ajax requests).
Can I ask why your application is so sensitive to "ajax" pages being called directly? Could you design around this?
You can check the Request headers to see if the call is initiated by AJAX Usually, you should find that x-requested-with has the value XMLHttpRequest. Or in the case of ASP.NET AJAX, check to see if ScriptMAnager.IsInAsyncPostBack == true. However, I'm not sure about preventing the request in the first place.
Have you looked into header authentication? If you only want your app to be able to make ajax calls to certain pages, you can require authentication for those pages...not sure if that helps you or not?
Basic Access Authentication
or the more secure
Digest Access Authentication
Another option would be to append some sort of identifier to your URL query string in your application before requesting the page, and have some sort of authentication method on the server side.
I don't think there is a way to do it without using a session. Even if you use an Http header, it is trivial for someone to create a request with the exact same headers.
Using session with ASP.NET Ajax requests is easy. You may run into some problems, like session expiration, but you should be able to find a solution.
With sessions you will be able to guarantee that only logged-in users can access the Ajax services. When servicing an Ajax request simply test that there is a valid session associated with it. Of course a logged-in user will be able to access the service directly. There is nothing you can do to avoid this.
If you are concerned that a logged-in user may try to contact the service directly in order to steal data, you can add a time limit to the service. For example do not allow the users to access the service more often than one minute at a time (or whatever rate else is needed for the application to work properly).
See what Google and Amazon are doing for their web services. They allow you to contact them directly (even providing APIs to do this), but they impose limits on how many requests you can make.
I do this in PHP by declaring a variable in a file that's included everywhere, and then check if that variable is set in the ajax call file.
This way, you can't directly call the file ever because that variable will never have been defined.
This is the "non-trivial" way, hence it's not too elegant.
The only real idea I can think of is to keep track of every link. (as in everything does a postback and then a response.redirect). In this way you could keep a static List<> or something of IP addresses(and possible browser ID and such) that say which pages are allowed to be accessed at the moment from that visitor.. along with a time out for them and such to keep them from going straight to a page 3 days from now.
I recommend rethinking your design to be sure that this is really needed though. And also note IPs and such can be spoofed.
Also if you follow this route be sure to read up about when static variables get disposed and such. You wouldn't want one of those annoying "your session has expired" messages when they have been using the site for 10 minutes.