Which validations are preferred : client side(using Javascript) or serverside (using validation controls in C# asp.net)?
You should always validate on the server. Client-side validation is fine to enhance the user experience, but anything that has come from the client is potentially dirty and should be validated on the sever again, as your server-side code is not vulnerable to malicious user manipulations (at least, not in the same way that client-side code is).
Always finally validate on the server!!
both are good, at minimum server side validation is a must. As client might have javascript disabled on the browser
Reason you shouldn't rely on client side validation
The end user could have javascript switched off
The data could be sent directly to your server by someone who's not
even using your site, with a custom app designed to do so
A Javascript error on your page (caused by any number of things)
could result in some, but not all, of your validation running
Both.
JavaScript is important because it prevents invalid postbacks to
server.
Server-side is important if client disabled JavaScript from browser
than JavaScript validation bypass.
I also recommend you to make validation at database level also. for reliability.
You should perform validations at server side as well as client side.Client side validations increase interactivity of your applications.In other words make your application more user friendly.However client side validations may have their shortcomings , if your user disables javascript , then he could very well enter non sense data values and send them to your server.You dont want this to happen.For that purpose you need to perform server side validations.Server side validation controls filter the input and make sure proper data is entered.There are good validation controls Asp.Net offers.You could very well utilize them.
I recommend you to use both client as well as server side validation for a blend of interactivity and protection.
Thanks
The basic validation such as the emptiness of the fields, valid emails, number, strings or dates should be done at the client side, but you should always validate at the server for any potential hacking like cross site scripting or tags (php tags for example) and to make more and more secure always use stored procedures and also make sure to have a function that replaces "'" by this """ or <> by empty string and any other dangerous characters.
Related
I have read that people can remove javascript from browsers or something and the validations of client side stop working, which is important for us to have server side validation..
In .NET Core, we have data annotations, does this work for both server and client side or do we need to make a validation in server side?
Also, using [Remote] validation, is the same thing? I am using both of this, and I am not sure if i need to also make the validations on the create() action for example..
One more thing, does ModelState.IsValid() work with remote validation? Thanks for any help
Example:
public IActionResult VerifyCargo(string Descricao, int ID_Cargo)
{
var validateName = ValidateName(Descricao);
if (validateName != null)
{
return Json($"Description {Descricao} is already in use.");
}
else
{
return Json(true);
}
}
public RH_Cargos ValidateName(string Descricao)
{
return _context.RH_Cargos.FirstOrDefault(x => x.Descricao == Descricao);
}
I have those functions and in model I have a [remote] annotation that calls that first one...
It works fine, but do I need to make any validation on the Create action? Or will this remote attribute do for both server/client side? Is it safe?
In .NET Core, we have data annotations, does this work for both server and client side or do we need to make a validation in server side?
Those data annotations, i.e., [Required], would work on the server. As others might have already mentioned, the client-side validation is a bonus/nicety added only when you include jQuery Unobtrusive Validation and jQuery validation plugin (of course their dependency jQuery is also needed).
So don't need to worry if someone turns off JavaScript on the browser. You will still get the server-side validation by the MVC framework when the data posts back to the server.
That would also mean client-side validation cannot trusted. You can see it would be easy for others to by-pass the client-side validation and submit data to the server (i.e., using 3rd party tool like Postman).
Also, using [Remote] validation, is the same thing?
The [Remote] attribute will call a method defined on the server to determine whether the field is valid or not. For that to work, you need to define an action method that returns a JSON response. Anything other than true would mean invalid input.
I am not sure if i need to also make the validations on the create() action for example.
You would need to inspect ModelState.IsValid and make decisions what to do when there are errors. If you meant something other than checking the modal state, then I have no idea what you meant by making the validations.
Does ModelState.IsValid() work with remote validation?
I am not sure what you meant by that. The remote validation requires an action method defined, which either returns true to indicate the input is valid, false, undefind or null to indicate the input is not valid, or returns a string for the error message.
ModelState does get updated after the remote validation returns.
My rule of thumb
I just never trust client inputs. Even you have all the validations setup, you still need to have your domain validations in place, to make sure everything is in valid state when the information persists.
One example I can think of could be: you have a form to take user's email and create an account. The field Email uses remote validation to check if the email has been taken or not. If it just happens that right after the remote validation comes back as OK, another person just quickly registers an account with the same email before the person submits the form. Now you can't just blindly create another account with the same email address because that email has been taken.
I have a form that uses v validates (vue.js validation). I'm trying to implement some server side validation also, but am having trouble testing it as the client side validation kicks in before the server side does, so I'm not able to see if it's working as it should.
Instead of turning off the v validation for each individual input, is there a way I can turn it off for the whole website?
I don't think you can turn it off from your solution as per their documentation. However, You can remove data-vv-scope attribute from the form.
Request Validation is a powerful mechanism to prevent injecting malicious code via a request to server. This is done on server-side so regardless of the fact that whether any client-side validation has done or not, one can be sure if something unusual is coming then an exception will be thrown automatically.
My question:
While we have "Request Validation" in hand, does it still necessary to sanitize requests?
I'm using Asp.net MVC 5.0
PS:
I'm solely talking in the context of web (not DB or something else) and its potential vulnerabilities (such as XSS).
Yes! There is plenty of perfectly valid input in ASP.NET's eyes that could cause issues in your application if not dealt with correctly.
For example, if somebody passed some data in a request and you weren't correctly parameterizing queries in your data layer then this input:
x'; DROP TABLE users; --
Could result in this query:
SELECT FieldList
FROM Users
WHERE Email = 'x'; DROP TABLE Users; --
Oh noes! You've lost your Users table!
You should always treat user-input as hostile irrespective of request validation. This demonstrates some scenarios whereby request validation wouldn't save your skin.
HTML encoding when you render user-provided input is important... Never render any untrusted input using #Html.Raw and be careful that your HtmlHelpers correctly encode anything coming from a user.
Defence in depth is important. Think of request validation as just one piece of that process.
Here's a link about Xss on MSDN and Request Validation
https://msdn.microsoft.com/en-us/library/vstudio/hh882339%28v=vs.100%29.aspx?f=255&MSPPError=-2147217396
We are using the web security scanner which found out one of my web page has a Bind SQLi. The scanner modified the parameter "news.aspx?id=123" to "news.aspx?i=123' or 1=1--", And the web server responses to the news information for id=1 information currently.
After investigation from development team, they said that there's no injection cannot access to Database which has already blocked by the .NET Built-in API SQL Parameter, and the back-end program will auto return the data of id=1 information to client side.
May I know can it be identified as false positive, or is it better to redirect to generic error pages? Or it is enough and acceptable for current stage?
the back-end program will auto return the data of id=1 information to client side.
IMO, this is a lame behavior for the backend. I'd say the page should detect the error and redirect the user to an error page. Nevertheless, based on that description it is not a valid injection, so if the business can accept that behavior, then it is a false positive.
P.S. While this isn't a SQL injection, it is potentially an information disclosure bug if it's possible to get the page to display the data for id=1 and the user of the page shouldn't have access to that particular record.
So long as your underlying application code is parameterizing the values being sent to SQL (as your developers claim), then you do not need to worry about such warnings.
I want to insert some data into database when user cuts/exits the browser or tab.
This is the statement which I want to be executed.How is this possible
_objQ117.insert();
I'm in no way a C# guru, but I'll try to explain the general principle.
Browsers are pretty protective of the user's data these days, though there are possibilities.
You may use something akin to onunload or onclose to send an AJAX request to the server, executing the query.
However, support of this may be spotty in certain browsers. By sending AJAX requests, say every minute or so, the server will be aware that your client is still connected--until the requests stop. An AJAX request is nothing more than a standard HTTP request created by javascript and returned as a variable(i.e. without necessarily loading an entire page, as the server only returns a small amount of result data)