PSA: If you want to fix security with better documentation be aware that it almost certainly won't work.
This seems like an utterly broken implementation architecture. There's no reason the DB server of proxy ever needs to see prepared stmts.
-
-
A proper API does them entirely client-side and sends standard SQL (filling in parameters with proper escaping) over the wire.
-
Ah, you mean client-side escaping, not server-side prepared statements that save server resources (parsing, permissions, query planning).
-
I don't really care how it's implemented under the hood. Important part is that the app never be allowed to write queries as strings.
-
Server-side prepared statements are an optimization choice (maybe a tradeoff) whereas how API looks to the app is a matter of secure design.
-
Do you propose, e.g., that the custom SQL API check that the SQL string does not contain value literals, only table/column/function names?
-
I propose APIs that do not accept value literals anywhere in the query string, only as parameters.
-
So e.g. in https://docs.djangoproject.com/en/1.11/topics/db/sql/#executing-custom-sql-directly … the "foo = 1" would raise exception, you have to pass the 1 in the args? I agree, that is a good idea.
-
keep set of hashes of checked SQL strings, to not parse same string again, the parsing only happens once per custom SQL string per process.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.