PSA: If you want to fix security with better documentation be aware that it almost certainly won't work.
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.