[delifue]

This is a common example of not fixing from root cause and try to fix from "outside valiation" that has bad side effects.

The correct way of fixing SQL injection is to use prepared statement and parameters.

Other examples: Windows allows software to do bad things, having no proper permission control (to maintain compatibility). Antimalwares scan applications by matching patterns of virus code, but has many false positives and false negatives. This causes many troubles (kill innocent software, scanning cost performance, etc.) because it does not fix from root case (proper permission management).

[rileymat2]

Can you say more about proper permission management?

If we are talking about ransomware running in a user context, it'd have the permissions of the user to encrypt anything the user has access to.

If we are talking about extreme sandboxing, you make it hard for programs to work together without permission fatigue, or the user having no idea what they are allowing or getting used to allowing all permissions.

[userbinator]

Somehow, escaping is beyond the comprehension of many people, yet I find it a simple and straightforward concept.

[ameliaquining]

Escaping isn't always straightforward. Or rather, it is in simple languages or in languages that are designed to make it straightforward, like HTML, but in SQL it's surprisingly tricky, and subtle bugs in escaping routines are an occasional source of vulnerabilities. E.g., https://stackoverflow.com/a/12118602. This is why modern best security practice is to use parameterized statements instead.

[matsemann]

There are so many foot guns, just don't do it.

Php users tried with addslashes(), realized there are cases it can't handle, made a sql variant in mysql_escape_string, realized it's open for abuse since you can mess with the character set. Then made mysql_real_escape_string and later mysqli_real_escape_string, which even them have some flaws depending on the db charset.

So if you find the concept easy, I'd wager it's because you don't handle some exploit path.

[abanana]

The simplest aspects of the concept of escaping are beyond the comprehension of some people.

Several years ago, I showed a colleague that in the simple file-storage web app he'd written, just changing part of the URL from e.g. "/folder/23/" to "/folder/23 OR 1=1" would show every file ever uploaded by any user, ever. (He hadn't even added a clause to limit it to the logged-in user, but that's another matter.)

He was taking that folder number from the URL, passing it through mysql_real_escape_string() because he'd simply learned by rote that that's how you make any user input safe, then concatenating the SQL, without putting quotes around the variable in the query because it's meant to be an integer: "...WHERE folder_id = $folder_id".

It didn't matter how I tried to explain things, he just didn't get it. He still works there (I left, I'd had enough) - his job title is "senior developer".

[userbinator]

he'd simply learned by rote

That's a common problem. A lot of people don't realise that if you accept user input, you can get every single byte and sequence of bytes possible. Validating that a parameter is an integer ([0-9]+) is even easier than escaping.

his job title is "senior developer".

Likely that's purely because of how long he's worked there, not how much he actually knows.

[jagged-chisel]

Doing your own escaping is digital whack-a-mole. Let the experts who wrote the prepared statement interface handle it. The knowledge of a team and/or years of experience compressed into an interface that’s trivial to use.

[ameliaquining]

Parameterized statements don't actually abstract over escaping; they entirely obviate the need for it, by moving the untrusted data out of band.

[jagged-chisel]

It’s the safest interface to your database query engine no matter how it does the job. That’s what matters.