News for hackers. Stuff that matters.
Re:Finding an authorization bypass on my own website by progforlyfe on Saturday March 05, 2022 @07:05PM (#30573376)
Bingo. Any time software is made to try parsing & escaping SQL queries before sending to the server is going to find out the hard way why that is risky.

With prepared statements it's like saying to the DB, here's the query: SELECT * FROM users WHERE email = ? AND password = ?. And here's the data: ["whatever", "whatever"]. You can literally send whatever your heart desires for those two strings, unescaped, to the DB server and let them deal with it.

Re:Finding an authorization bypass on my own website by galaxyLogic on Saturday March 05, 2022 @07:34PM (#30573616)
Prepared Statements are great. Is there any way to force the programmer to use (only) them?
Re:Finding an authorization bypass on my own website by singron on Saturday March 05, 2022 @08:52PM (#30574202)
From the DB, no. E.g. you could always have `query("... a = ? and b = "+b, [a])`.

From within a language, you somehow need to restrict how you build up the query. E.g. a query builder or ORM usually makes it hard to use anything besides parameters, but they usually have escape hatches (e.g. a where method that takes arbitrary sql strings).

One trick you can do in Go is to create a type like `type sqlLiteral string`. The type is private, so other packages can't directly instantiate it, but a string literal will automatically coerce to it. Basically, you can't compute sqlLiteral from arbitrary expressions. It must be a single hardcoded string literal.

Re:Finding an authorization bypass on my own website by nicoburns on Saturday March 05, 2022 @08:59PM (#30574251)
No, because constants and column names are of course legitimate parts of SQL queries (even those using prepared statements), and because queries with no parameters are also legitimate.
Re:Finding an authorization bypass on my own website by namibj on Saturday March 05, 2022 @10:57PM (#30574900)
Code review and static analysis work great, by allowing obviously-safe dynamic SQL where static SQL is insufficient.