Update: Recommend Input sanitization as supplementary defense

[timurozkul]

What is missing or needs to be updated?

The current cheats do not recommend input sanitization: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html]

I agree that input sanitization is not a strong prevention method for a sophisticated attacker for preventing malicious input but it is still a valid way of preventing. All other recommendation on input validation require individual implementation making it high workload and more error prone vs implementing a sanitization library as middleware which is quick win. Sanitization libraries help fend off a degree of attacks (ie DOMPurify). Many organization use sanitization libraries if they follow the OWASP guide and remove the sanitization libraries I would guess that they all would be worst off.

How should this be resolved?

OWASP should recommend input sanitization as supplementary defense instead of primary however it should still be recommended none the less.

[randomstuff]

It makes sense for HTML (and some XML-based languages) under very specific circumstances but in many cases you actually want to do proper escaping instead. However it is actually recommended in this case:

HTML Sanitization

When users need to author HTML, developers may let users change the styling or structure of content inside a WYSIWYG editor. Output encoding in this case will prevent XSS, but it will break the intended functionality of the application. The styling will not be rendered. In these cases, HTML Sanitization should be used.

HTML Sanitization will strip dangerous HTML from a variable and return a safe string of HTML. OWASP recommends DOMPurify for HTML Sanitization.

For other contexts (such as SQL), I don't believe it makes sense and is opening up a huge can of worms :canned_food: :worm: :worm: :worm: :worm:.

[timurozkul]

I have scoured the internet have not found one valid literature that explains why input sanitization is bad other then it gives a false sense of security and that it can strip out legitimate characters. I'm curious about what evidence or reasoning led OWASP to change its stance on this. Can someone explain why filtering out ; DROP TABLE from an input field for "favorite food" would be considered a bad?

[mackowski]

I think that depending on the case and design input sanitization can be as good and input validation as an supplementary defense. My logic is: When I see something that should not be part of the valid user input e.g. the input is outside of my allowed-list values, I can either reject the input or sanitize it. In both cases security is similar.

The problem with sanitization is that it is much harder to implement correctly, because you need to do the same job as for input validation but later you also need to filter out dangerous input. Filtering out dangerous input is very hard and we saw that in the past with all HTML sanitizers had some issues with that.

Other aspect is UX. I am not expert in this domain but from my experience it is preferred to reject the bad input and return error to the user or API rather than mutate the input in unpredicted (for a consumer point of view) way. But that is a design decision we will not made in this CS.

So going back to the example of

filtering out ; DROP TABLE from an input field for "favorite food" What we gained (from security point of view) when we filtered out ; DROP TABLE in comparison to just returning the error and rejecting the input?

Also do we have some good examples of sanitization, outside of HTML (and some XML-based languages), that are proved to be a good defence step?