News for hackers. Stuff that matters.
Re:Don’t try to sanitize input, escape output (2020) by hombre_fatal on Thursday January 13, 2022 @12:50PM (#29924022)
I'd argue that sanitization makes things worse from that standpoint.

What exactly was transformed in some given data and for what context? What needs to be done to reverse the sanitization process if you want to see the verbatim data, if that's even possible? Now that you want to escape the output, how can you reverse the sanitization transform so that you aren't double-escaping? What were the assumptions being made when this data was sanitized and what was that transform?

In other words, it's simpler to hold the verbatim data and then ask "ok, how does it need to be escaped for this context?" than having to ask that same question with arbitrarily mangled data while worrying if the data was sufficiently escaped for this context at input-time some point in the past.

Even beginners get almost all mileage from parameterized SQL queries + using an HTML templating library that escapes by default which is almost all of them these days.

I think knee-jerk sanitization is a relic of the days where that wasn't common, namely <?php echo $username ?>, which wasn't necessarily the worst advice when you otherwise had to remember to echo htmlEscape($username) every single time. Fortunately, things have improved since those days.

Re:Don’t try to sanitize input, escape output (2020) by pydry on Thursday January 13, 2022 @01:20PM (#29924465)
I've used a bunch of sanitizers and never had any issues with any of them. I'm sure there are exceptions but IME they tend to mangle the kind of text which the user really has no legitimate need to enter most of the time.

Far from being a relic the recent log4j vulnerability highlighted just how much value there is in this kind of defense in depth.

Obviously knee jerk decisions in tech are usually bad news.