9 ms·
While this is true, the developer implementing this can still make a mistake. I've seen (esp. on long multiline queries that get modified over some time), a mix
by 234dd57d2c8db 10y ago
While this is true, the developer implementing this can still make a mistake. I've seen (esp. on long multiline queries that get modified over some time), a mix of prepared variables for things like userids and string concat for things like table names but the dba or the dev doesn't realize the attacker has control over the table name due to how they are handling user input on that particular endpoint. Maybe the table name is passed in on one endpoint because it's old and janky. Then it fools people because they see it's a str passed to prepared statement func and assume it's safe. I've seen this in some place in a large number of the apps I've worked on.
- kuschku 10y agoIf you have to let the attacker control a direct substring of SQL, then use a whitelist of allowed characters – for tablenames, [a-zA-Z0-9_] is usually good enough, and then put that in quotes (as some databases reserve keywords such as "user" or "password", which is bad if you want to name columns like that). I’ve had quite a few codebases I’ve worked on where I had to replace naive code [1], and until now, it’s always been easily possible to ensure that the entire space of possible inputs is limited enough to prevent SQL injections. Sure, there are rare projects where you have to do such very complicated systems, but for 99%, it’s possible to get guaranteed protection from SQL injections. ________________________ 1: "db->query('SELECT 1 FROM users WHERE username = "' + $_POST['username'] + '" AND password = "' + md5($_POST['password']) + ';"');" was real code I’ve seen