Changes in validation of the final version of ASP.NET MVC 2
and a few security issues to watch out for
Brad Wilson, one of the developers in the ASP.NET MVC group, reported on his blog about upcoming conceptual changes that will be made in the final version of ASP.NET MVC 2.
It is about changing one concept of validation, based on form fields, to another - a concept based on a data model. In this article, I would like to tell you why these changes were made and what they mean for the developer.
')
For the demonstration, I would like to define a simple data model. For the sake of example, I chose a simplified model of a single entry of a digg-like service. In such services, each entry is the text of a link to a useful resource on the network, plus a description of this link.
Here, besides the Url and Description fields, the Id (identifier), Approved (flag indicating that the entry was moderated) and CreateDate (record creation date) fields are declared. The Bind attribute in this case indicates that when binding data to an instance of the model, it is not necessary to associate Id values.
For the demonstration, we need an input form and a field for outputting the results. Create the following markup:
Let's try to enter something and look at the result:
At first glance, everything is in order, except for the fact that there is no validation in our code. We modify the data model class using the attributes DataAnnotations to support validation:
Now, if we try to send empty fields from our form, we will get validation errors:
So far everything looks nice and beautiful. However, imagine such an option: the field for entering the description was not added in one of the variants of the form when another page was created by another developer. Or, more tragically, the attacker forms and sends the data at all without specifying the “Description” field. How will our application behave in this case?
To demonstrate such an attempt to send bad data, I formed a simple query that contains the value of Url, but not the value of Description. You can see the result of the query below:
As you can see, Description is null, but the data model is considered valid. In case there are no additional checks, this query would result in writing invalid (according to our views) model to the database.
What is the catch? The fact is that validation, which works in ASP.NET MVC 2 of all currently public versions (the latest version - RC), is based on form values. In other words, only those fields that have been transmitted to the server are subject to validation, the remaining fields do not pass validation.
The problem of this moment is as follows: is server validation a mechanism of protection against unauthorized access or not? Until recently, the answer was essentially no. Validation was a means of validating user input for certain conditions.
However, most developers who are not versed in the intricacies believe that validation protects their data from unauthorized access, and in this case, the default validation mechanism can be the source of numerous vulnerabilities in the created resources.
What is offered in exchange? The solution is to change the validation behavior from form-based to model-specific. That is, to bring the behavior to what is expected by most developers. In the final version of ASP.NET MVC 2, this is exactly what will be done: validation will no longer depend on the values ​​transferred, but will depend entirely on the data model.
So, the attacker will not be able to harm us by sending a malformed request, in which there is no data. If the model determines that the data is required, then when validating the values ​​of the form and the model instance, a validation error will occur and the model will not be valid.
There are several points in the upcoming innovations that need attention.
The validation rules for nested complex objects within a model will affect validation only when there is at least one field of this complex type on the form. For example, if a property of the Address type is declared in the Person class, then the validation rules for the Address will be applied only if at least one of the Address properties is involved in the request to the server.
Due to changes in the validation mechanism, the processing of the Bind attribute, which is set for the model, is changed. In the final version of MVC 2, validation will be performed for all properties of the model, regardless of whether the properties are placed in the Excluded list of the Bind attribute or not.
Previously, by specifying certain fields in the Excluded list, one could achieve partial validation of the model. From now on, it is impossible - all properties will be checked for validation rules.
Due to the fact that the validation will be repelled by the model, the use of Required for non-nullable types is useless. It was impossible to determine whether or not the value was transferred from the form, since the value-type has a default value.
Another possible problem is that the developer can use not a strict presentation model as action parameters, but part of it:
Here, the record is edited by first binding the single id parameter. Then an existing entry is loaded from the repository and an attempt is made to update it. The problem occurs when the data sent to the server does not contain all the necessary values. For example, the same “Description” field is empty. In the presented example, the validation for the Description field will not work in any of the code execution locations and the model will be incorrectly saved.
The solution to the problem is to use a strictly type of model, instead of part of it. Then validation will work at the stage of binding action parameters.
Another problem that may arise when using validation is the ability for an attacker to send the values ​​of such model fields that should not be sent to the server. This may be the Approved value for our Story model. The Approved value for the record means that the record has passed moderation, that is, this value determines the system security parameter and access to it must be explicitly restricted.
I sent a malicious request from our form, look at the result:
You can see that the model already has the established value Approved = true, that is, the attacker potentially overcame the pre-moderation mechanism.
To avoid this situation, it is necessary to carefully consider the validation mechanism and plan your models correctly. For example, in order to avoid such pre-moderation hacking, you need to add the value Approved to the Excluded list in the model for the Bin attribute:
In this case, the binding of user data will not be made for the Approved field, which solves the problem.
In this article, I reviewed the innovations for the validation mechanism that will be made in the final version of ASP.NET MVC 2. In addition, security issues were discussed when using data binding, validation, and sending data from a form.
Automatic validation and data binding are extremely useful mechanisms that can greatly facilitate your life. But their use imposes obligations to comply with certain safety rules, which should not be forgotten. Hope this article helps you build secure sites on ASP.NET MVC. Pleasant development, colleagues!
Brad Wilson, one of the developers in the ASP.NET MVC group, reported on his blog about upcoming conceptual changes that will be made in the final version of ASP.NET MVC 2.It is about changing one concept of validation, based on form fields, to another - a concept based on a data model. In this article, I would like to tell you why these changes were made and what they mean for the developer.
')
For the demonstration, I would like to define a simple data model. For the sake of example, I chose a simplified model of a single entry of a digg-like service. In such services, each entry is the text of a link to a useful resource on the network, plus a description of this link.
In the article, I use images to demonstrate the code. This is due to the fact that I plan to post an article on several resources and spend time on coloring the syntax in each of them I do not want. Instead, at the end of the article I attach the source code in the form of a finished project.So, the Story.cs class:
Here, besides the Url and Description fields, the Id (identifier), Approved (flag indicating that the entry was moderated) and CreateDate (record creation date) fields are declared. The Bind attribute in this case indicates that when binding data to an instance of the model, it is not necessary to associate Id values.
For the demonstration, we need an input form and a field for outputting the results. Create the following markup:
Let's try to enter something and look at the result:
At first glance, everything is in order, except for the fact that there is no validation in our code. We modify the data model class using the attributes DataAnnotations to support validation:
Now, if we try to send empty fields from our form, we will get validation errors:
So far everything looks nice and beautiful. However, imagine such an option: the field for entering the description was not added in one of the variants of the form when another page was created by another developer. Or, more tragically, the attacker forms and sends the data at all without specifying the “Description” field. How will our application behave in this case?
To demonstrate such an attempt to send bad data, I formed a simple query that contains the value of Url, but not the value of Description. You can see the result of the query below:
As you can see, Description is null, but the data model is considered valid. In case there are no additional checks, this query would result in writing invalid (according to our views) model to the database.
Problem
What is the catch? The fact is that validation, which works in ASP.NET MVC 2 of all currently public versions (the latest version - RC), is based on form values. In other words, only those fields that have been transmitted to the server are subject to validation, the remaining fields do not pass validation.
The problem of this moment is as follows: is server validation a mechanism of protection against unauthorized access or not? Until recently, the answer was essentially no. Validation was a means of validating user input for certain conditions.
However, most developers who are not versed in the intricacies believe that validation protects their data from unauthorized access, and in this case, the default validation mechanism can be the source of numerous vulnerabilities in the created resources.
Decision
What is offered in exchange? The solution is to change the validation behavior from form-based to model-specific. That is, to bring the behavior to what is expected by most developers. In the final version of ASP.NET MVC 2, this is exactly what will be done: validation will no longer depend on the values ​​transferred, but will depend entirely on the data model.
So, the attacker will not be able to harm us by sending a malformed request, in which there is no data. If the model determines that the data is required, then when validating the values ​​of the form and the model instance, a validation error will occur and the model will not be valid.
Details or “not so simple”
There are several points in the upcoming innovations that need attention.
Complex types
The validation rules for nested complex objects within a model will affect validation only when there is at least one field of this complex type on the form. For example, if a property of the Address type is declared in the Person class, then the validation rules for the Address will be applied only if at least one of the Address properties is involved in the request to the server.
Bind attribute processing changes
Due to changes in the validation mechanism, the processing of the Bind attribute, which is set for the model, is changed. In the final version of MVC 2, validation will be performed for all properties of the model, regardless of whether the properties are placed in the Excluded list of the Bind attribute or not.
Previously, by specifying certain fields in the Excluded list, one could achieve partial validation of the model. From now on, it is impossible - all properties will be checked for validation rules.
Required for non-nullable types
Due to the fact that the validation will be repelled by the model, the use of Required for non-nullable types is useless. It was impossible to determine whether or not the value was transferred from the form, since the value-type has a default value.
Parameters as part of the model
Another possible problem is that the developer can use not a strict presentation model as action parameters, but part of it:
Here, the record is edited by first binding the single id parameter. Then an existing entry is loaded from the repository and an attempt is made to update it. The problem occurs when the data sent to the server does not contain all the necessary values. For example, the same “Description” field is empty. In the presented example, the validation for the Description field will not work in any of the code execution locations and the model will be incorrectly saved.
The solution to the problem is to use a strictly type of model, instead of part of it. Then validation will work at the stage of binding action parameters.
Passing extra parameters
Another problem that may arise when using validation is the ability for an attacker to send the values ​​of such model fields that should not be sent to the server. This may be the Approved value for our Story model. The Approved value for the record means that the record has passed moderation, that is, this value determines the system security parameter and access to it must be explicitly restricted.
I sent a malicious request from our form, look at the result:
You can see that the model already has the established value Approved = true, that is, the attacker potentially overcame the pre-moderation mechanism.
To avoid this situation, it is necessary to carefully consider the validation mechanism and plan your models correctly. For example, in order to avoid such pre-moderation hacking, you need to add the value Approved to the Excluded list in the model for the Bin attribute:
In this case, the binding of user data will not be made for the Approved field, which solves the problem.
Conclusion
In this article, I reviewed the innovations for the validation mechanism that will be made in the final version of ASP.NET MVC 2. In addition, security issues were discussed when using data binding, validation, and sending data from a form.
Automatic validation and data binding are extremely useful mechanisms that can greatly facilitate your life. But their use imposes obligations to comply with certain safety rules, which should not be forgotten. Hope this article helps you build secure sites on ASP.NET MVC. Pleasant development, colleagues!
Appendix: source codes from the article
Source: https://habr.com/ru/post/82006/
All Articles