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
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 know how anti-forgery token in ASP.NET MVC works.But still not clear about few scenarios. One I mentioned below.
submit a post request with below information
cookie token(antiforgerytoken)
form data(first name & last name)
form input hidden token(antiforgerytoken)
Before reaching server a hacker modified form data(first name & last name) leaving token info unchanged.
In this scenario, how we can make sure the data submitted securely reached server without any modification
Actually this question is asked by an interviewer. I discussed with my colleagues and I searched in Google too. Since I couldn't find a clarity on this I thought to ask here.
I am not sure if this is a valid question.If yes,any help would be appreciated
Multiple things are mixed here. The confusion is around the purpose of different protections, so let me try and get that straight.
CSRF, and antiforgerytoken
The basic threat is the following. A victim user is logged on to the victim website victim.com. Meanwhile (say in another browser tab) he visits a malicious website malicious.com that wants to exploit CSRF in victim.com. For that, malicious.com has the user post the required parameters to victim.com to call a certain function which obviously victim user did not want to perform. This is the base case of CSRF, exploiting an existing user session, malicious.com performed something on victim.com via a victim user.
This is prevented, if for example antiforgerytoken is used, because malicious.com will not be able to send the right token to victim.com, so the request will be denied.
Note that this has nothing to do with legitimate request content.
Integrity of requests
A different problem is making sure the request is received as sent, ie. data is the same. This is usually achieved by using HTTPS, which provides message integrity and encryption (among others). So if HTTPS is used, such change of data in transit is not possible.
Of course if the attacker controls either the client or the server (more precisely, the TLS endpoint, which is not always the server), ie. anything outside the TLS channel, then the attacker can modify data. But that would mean having control over the client. For example you can do this if you run a local proxy (Fiddler, Burp, ZAP Proxy, etc.) on your client - you can then change any data in the request, that's how penetration testers work. However, an attacker not having this level of control would not be able to do this.
Without HTTPS, request (and btw also response) integrity and encryption are problems that are hard to solve. The solution is HTTPS. :)
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.
In ASP.NET MVC views, it is typical to bind model values using Razor's syntax:
#Html.DisplayFor(m => m.Name)
We know that Razor will html encode the value by default. But imagine a malicious user inputting scripts in a textbox and submitting it:
<script>alert('Executing evil script')</script>
Now if we do not use the [ValidateInput(false)] or [AllowHtml] attributes, we will be hit with a HttpRequestValidationException which means this exception have to be caught every time a user submits a form.
From the answer in another stackoverflow question, I know we can disable request validation on an application level but many are suggesting this is a bad practice.
My question is, given we have Razor to escape all > and <, can we assume the site will still be secure if we turn off request validation?
No, relying only HTML encoding during Razor page generation and switching off request validation is not a good strategy to combat XSS attacks:
Request Validation prevents bad user input from getting into your database / storage / other user screens in the first place.
Html encoding (sanitization) is there as a backup strategy, e.g. where the attacker has already got through the door.
Considering that an App can serve more than just Html - e.g. Xml and REST services, which will not be subject to the encoding by the Html helpers. (e.g. attacker might find a way to put a malicious payload in an Xml CDATA section)
Also, consider running regular Sql / NoSql queries against your database looking for signs that your site request validation has been compromised.
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.