My understanding is that Log4Shell vulnerabilities come from parsing `${jndi:ldap:path}` files coming from HTTP requests, which raises the question of why wasn't that input sanitised in the first place.
Aren't `[${}]` in `$GET` and other HTTP headers normally replaced with sanitised strings to prevent these kinds of vulnerabilities?
What kind of sanitation needs to be done based on where the data is going. There is no "one size fits all" method of sanitizing because what sanitizes for one purpose will just make the data look like garbage in another.
ie, if the User-Agent is being reflected back to a user on the web page, then HTML entities such as < and > need to be changed to < and > respectively. If it's being put in a SQL query, then quotes (both single and double) and backticks needs to be filtered. Of course, really you should be using parameterized queries so sanitation isn't necessary at all.
If your data is going straight into a log, nobody would expect that data needs to be sanitized, beyond possibly filtering \r and \n to prevent log forging via CRLF injection. I would expect it to not be sanitized, since then it's not clear based on the log what a user actually sent.
My understanding is that Log4Shell vulnerabilities come from parsing `${jndi:ldap:path}` files coming from HTTP requests, which raises the question of why wasn't that input sanitised in the first place.
Aren't `[${}]` in `$GET` and other HTTP headers normally replaced with sanitised strings to prevent these kinds of vulnerabilities?