How rapid development technologies can become a source of unpleasant vulnerabilities
Security with real examples is always more interesting.
As a penetration tester, I love when projects based on Rapid development frameworks come in, like Ruby-on-Rails, Django, AdonisJs, Express and so on. They allow you to build a system very quickly due to the fact that business models skip immediately to all levels, including the client browser. Model (models of business objects in the database) and ViewModel (contract for interacting with customers) such frameworks are often combined together to avoid unnecessary shifting from Model to ViewModel and vice versa, REST services are automatically generated. From the development point of view, you can simply develop a business model on the server, and then use it immediately on the client, which undoubtedly increases the speed of development.
Once again, I am not saying that the aforementioned frameworks are bad, or something is wrong with them, they have the means and tools of proper protection, it’s just that the developers make the most mistakes with them. This was also seen in one ASP.NET MVC project, in which developers made the same vulnerabilities by exposing Models instead of ViewModels ...
Vulnerability: due to weak validation of the fields of incoming models from the client, it is possible to inject fields that are not provided by the functionality, but are in the business model. For example, there is a method that allows you to change only the username, and returns a user profile object. What if I copy the returned object, change all the properties in it and send it again to the input? It may turn out that you can change any property of the object (password, role), bypassing the standard workflow.
Of the various projects that we tested for security, I will give real examples. All these problem areas have been fixed, and any extra information in the screenshots is hidden.
System 1
On this system, only the user name could be changed in the profile. But substituting another Email, it was possible to change the user's login. Moreover, invitations to other users now left this soap.
System 2
In this example, a simple user managed to change the role to the administrator by adding the roles field, and by url / admin just open the system admin panel with all transactions, users, reports and so on.
System 3
In this system, it was possible to renew a free subscription for an indefinite period. It is understood that the standard approach required payment.
The input method would take, it would seem, only the selected color according to the branding of the workspace, and return the object of the entire workspace, including a full dump of the StripeCustomer object, which reflected the payment. It was possible to insert not just a field, but a huge sub-object StripeCustomer, and as a result, having paid once, or from another user to capture this object, and duplicate it to all of its workspaces.
System 4
And finally. This system had the same problem: it was possible to change the password and passkey bypassing the invented workflow. The lack of protection against CSRF and the storage of authentication cookies for a long period raised the risk of this vulnerability to heaven. A malicious user could place a script on a popular resource requesting to change the password of the current user of this system, and all users who would open this resource would lose access to the system.
Hide in the server code in the metadata for this field, this made it possible not to return this field to the client in the response, but in the input data this field was processed without problems.
The message:
The above information is provided only for educational and educational purposes, how to do their systems is not necessary.
Denis Koloshko, Penetration Tester, CISSP
As a penetration tester, I love when projects based on Rapid development frameworks come in, like Ruby-on-Rails, Django, AdonisJs, Express and so on. They allow you to build a system very quickly due to the fact that business models skip immediately to all levels, including the client browser. Model (models of business objects in the database) and ViewModel (contract for interacting with customers) such frameworks are often combined together to avoid unnecessary shifting from Model to ViewModel and vice versa, REST services are automatically generated. From the development point of view, you can simply develop a business model on the server, and then use it immediately on the client, which undoubtedly increases the speed of development.
Once again, I am not saying that the aforementioned frameworks are bad, or something is wrong with them, they have the means and tools of proper protection, it’s just that the developers make the most mistakes with them. This was also seen in one ASP.NET MVC project, in which developers made the same vulnerabilities by exposing Models instead of ViewModels ...
Vulnerability: due to weak validation of the fields of incoming models from the client, it is possible to inject fields that are not provided by the functionality, but are in the business model. For example, there is a method that allows you to change only the username, and returns a user profile object. What if I copy the returned object, change all the properties in it and send it again to the input? It may turn out that you can change any property of the object (password, role), bypassing the standard workflow.
Of the various projects that we tested for security, I will give real examples. All these problem areas have been fixed, and any extra information in the screenshots is hidden.
System 1
On this system, only the user name could be changed in the profile. But substituting another Email, it was possible to change the user's login. Moreover, invitations to other users now left this soap.
System 2
In this example, a simple user managed to change the role to the administrator by adding the roles field, and by url / admin just open the system admin panel with all transactions, users, reports and so on.
System 3
In this system, it was possible to renew a free subscription for an indefinite period. It is understood that the standard approach required payment.
The input method would take, it would seem, only the selected color according to the branding of the workspace, and return the object of the entire workspace, including a full dump of the StripeCustomer object, which reflected the payment. It was possible to insert not just a field, but a huge sub-object StripeCustomer, and as a result, having paid once, or from another user to capture this object, and duplicate it to all of its workspaces.
System 4
And finally. This system had the same problem: it was possible to change the password and passkey bypassing the invented workflow. The lack of protection against CSRF and the storage of authentication cookies for a long period raised the risk of this vulnerability to heaven. A malicious user could place a script on a popular resource requesting to change the password of the current user of this system, and all users who would open this resource would lose access to the system.
Hide in the server code in the metadata for this field, this made it possible not to return this field to the client in the response, but in the input data this field was processed without problems.
The message:
- Never trust incoming data from users, they can do anything with them
- Be careful with systems that do not have a separate ViewModel-s layer, and work directly with the base models
- Explore in more detail the protections your framework offers.
The above information is provided only for educational and educational purposes, how to do their systems is not necessary.
Denis Koloshko, Penetration Tester, CISSP
All Articles