Although in some places they speak of prototype pollution (or ‘prototype comtamination’) as a new technique for attacking websites. In reality, this novelty is relative, since as early as 2018 it is possible to find some CVEs, such as this one that affected lodash. It was more notorious when, last year, a similar problem was detected in jQuery. What was not so much mentioned at the time is that it was actually the second incidence of the same type, and that the previous one had taken place three years earlier. Therefore, and in view of the dates, we are actually talking about a problem that has been identified for quite some time.
The problem with prototype contamination is that a malicious actor can avoid attacking a particular object in the code and instead target the prototype, on which it will focus its efforts. And it makes perfect sense, because the modification of the object can have a limited scope, while the modification of the prototype provides a more global scope, as it reaches all objects that are inheriting properties from it.
And prototype contamination, if undetected, offers another advantage over modifying objects individually, and that is that the inheritance of the object’s properties will apply not only to existing objects, but also to those that may be added in the future. As long as the prototype remains contaminated, all objects, present and future, will be compromised by this problem.
With regard to solutions, and given that the attack is carried out on the client side, one of the main recommendations is to limit the user’s entry possibilities as much as possible. Establishing strict limits on which objects can be modified by users is currently the main way to combat the risk posed by prototype contamination. Other options, such as individual review of all types of objects that can be compromised, escape (by volume of work) the vast majority.