Validating anything but content
Deserialization is often the first step after the request (HTTP or other) is received, while there are a lot of other things to be validated first in the context of application security. When something becomes deserialized, this assumes the user input that is deserialized is somewhat how you expected it to be.
Things that come to mind are the content length of the request; the type of content in the request; or any other schema information that tells you what the content looks like (extension, for example).
For isolated Azure Functions applications, Arcus provides a middleware component that verifies if an incoming HTTP request is in fact JSON. For in-process Azure Functions, you have to do this yourself:
This and all remaining steps are, of course, valid for any type of request handling code. It is only that Azure Functions applications seem to get a ‘pass’ on these security-related verifications. It’s better to control your own validation.
Strict JSON deserialization
After this, we can assume that the request’s content is safe to be deserialized and we can try to deserialize it to a JSON representation. This step could also benefit from an extra content length validation check. Loading everything that is available from the request is not safe, so an additional middleware component or other infrastructure logic helps to make sure that we only buffer the expected amount of data before we begin deserialization.
With the JsonSerializationOptions, you can also manipulate the JSON deserialization to match your needs. The maximum depth is for example 64 by default. You can also already ignore any null values. All this sanitization logic will only help later when the DTO is actually created.
With the JsonPropertyAttribute and Newtonsoft JSON, you can have even more fine-grained control over this deserialization.
DTO model validation
Lastly, we can look at the model validation of the DTO. Not only is this often forgotten, but it is often mistaken for domain model validation. DTO models are purely used to communicate with external systems. They can be adapted to increase performance, be batched, or transformed in relation to serialization. Because of this, they are not suitable to represent the domain in any way.
That being said, they have their own model validation that checks the rudimentary and no-brainer validations.
These rudimentary validations are run by default in Web API applications, but for Azure Functions you can use the Validator.ValidateObject(...) in the System.ComponentModel.DataAnnotations.
Conclusion
In this post, we looked at three relatively easy steps to secure your DTO deserialization. Start by making sure that you have the right kind of content to deserialize, and if this content is within the bounds of the expected length. After that, the deserialization itself could be improved by matching the schema and format of the content. Finally, with some DTO model validations, we can make sure that the model is relatively safe to use further in the application. Note that this post does not handle domain validation. After the last step, the values are still not safe to be used within the core of your application. The translation between DTO and Domain is just as important (maybe more?) than the validation steps described here.
Azure Functions may be particularly vulnerable to these kinds of security risks. They are often seen as ‘ready’ from the start, while they are just as liable to be attacked as any other application.
Do not trust anything, validate everything.
Thanks for reading,
Stijn
Subscribe to our RSS feed