←back to thread

When parameterization fails: SQL injection in Nim using parameterized queries

(blog.nns.ee)
19 points xx_ns | 2 comments | 02 Apr 25 16:17 UTC | HN request time: 0s | source
Show context
jiggawatts ◴[02 Apr 25 20:53 UTC] No.43561417[source]▶
That’s… not parameterization the way most people understand it. It’s text templating, which is different and fraught with risk as the OP discovered.

For comparison: the Microsoft SQL client code will not substitute an escaped version of the query parameters into the query text! It sends the query with the named placeholders first, and then the parameter values encoded separately so that there’s zero risk of this kind of thing happening.

Also, this makes it trivial for the database engine to cache each query independently of the specific query parameter values.

replies(2): >>43562671 #>>43564746 #
1. inbx0 ◴[02 Apr 25 22:49 UTC] No.43562671[source]▶
Yes. And that is what a client should 100% do from the security standpoint. But since you mention caching - from the perf standpoint, it could sometimes be beneficial for the query planner to know the values before coming up with the query plan. Sometimes I have done little optimizations by replacing prepared statement placeholders with baked-in numbers or known enum values.
replies(1): >>43563531 #
2. jiggawatts ◴[03 Apr 25 00:53 UTC] No.43563531[source]▶
In .NET land that's handled by EF Core 9 using the EF.Constant(...) and EF.Parameter(...) wrappers that either (safely!) inline the value or force parameterisation.

https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-cor...