Some do not realize that the data life cycle is fundamentally different from the code life cycle.
Suppose the developer Natasha examines a case of a persistent XSS attack on a web server, in which customer data was stolen, and sees that all data is screened while being saved, however.
Natasha did not feel better when she saw that the SaveCommentOperation.cpp file never changed in the Git repository.
It turns out that it was created only half a year before by the developer Vasya, and replaced the saveComment function in the AllCommentOperations.cpp file, which lacked screening.
The project was launched two years ago, and the suspect Kulhacker managed to initiate a persistent attack by inserting his script tag. It was a prototype stage, and no one thought that the data would live for so long ...
Before the withdrawal, you need to screen necessarily, since it is generally not known what data you have already saved in the database.
In the general case, for the preservation in the database, there is a limited context in which it is impossible to foresee the features of all contexts of use. For example, to prevent XSS attacks, you must take into account the features of the HTML element, the URL, the script, the comment, the style, the attribute, and the arguments of the JavaScript functions. To prevent an attack on the logs (this is when the admin scrolls through the logs in the terminal, under the root, and suddenly the code of the attacker is executed) you need to take into account something completely different. You can even attack using Excel-document, displaying macros. You can attack the database ... In all these cases, (and they can all be in one project all at once), you need to escape in different ways.
It is even harmful to screen while saving, as someone’s stupid sanitizer will spoil the attacker's code, and then it will be harder to figure out how the attack was implemented.
It is simply a duplication of code, and a false sense of security.
... before starting to screen the output, our losers decided to re-read XSS (Cross Site Scripting) Prevention Cheat Sheet
Then the team-leader Petya gave a hint that you need to screen user input, before making the lines as a whole for querying the database, and Natasha threw a rubber pig at it, which she was given on March 8th.
After that, he was sent to read about the fact that it does not count, since it does not guarantee anything: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_3:_Escaping_All_User_Supplied_Input
He was also told that all normal guys have long been using data access libraries that support parameters .
