Detecting possible SQL Injection Vulernerabilties about phpstan-dba HOT 2 OPEN

I think phpstan-dba will have different views/solutions on this problem

• add a RuntimeConfiguration which allows enforcing literal-string queries
• add a Rule which checks whether proper ' quoting is used arround quoting functions/methods like real_escape_string
• maybe something more I don't have thought about yet

from phpstan-dba.

While I'd prefer literal-string to be the primary method (and to make developers aware of it); the real_escape_string() one could work... but some things to keep in mind, where it's not simply surrounded by single quotes, making them risky, but technically valid:

• "WHERE name = '" . $mysqli->real_escape_string($name_first) . " " . $mysqli->real_escape_string($name_last) . "'"
• "WHERE name LIKE '%" . $mysqli->real_escape_string($name) . "%'"
• "WHERE name REGEXP '^" . $mysqli->real_escape_string($name) . "'" (as an aside, it's risky allowing user values in a RegEx, could create a denial of service with an overly complex pattern).
• "WHERE name = '" . $db->escape($name) . "'" (not calling real_escape_string directly)
• "WHERE id = " . intval($id)
• "WHERE id IN (" . implode(",", array_map("intval", $ids)) . ")" (really hope they always remember to call intval, I've seen a few cases where that wasn't the case).
• 'WHERE name = "' . $mysqli->real_escape_string($name) . '"' (a string could use double quotes, even though it's not ideal, e.g. ANSI_QUOTES mode treating double quotes as an identifier).
• Escaping doesn't always play well with mixed character encodings, or NO_BACKSLASH_ESCAPES .

from phpstan-dba.