In case anyone is wondering about these releases without details/announcements, I'm working with a security-focused developer in Korea on SQL injection vectors in HoneySQL. A formal release will follow once we're through the initial rounds of testing and have a CVE allocated. Fixing these vulnerabilities means some extra checks on fairly hot paths so this will slow HoneySQL down a little bit. We can look at speeding that up once we've plugged all the holes 🙂
Curious what the context of these vulnerabilities is. User generated honeysql? Non explicit parameterised honesql? Are the hot paths pre or post cache?
Take a look at https://github.com/seancorfield/honeysql/blob/develop/test/honey/sql_test.cljc#L1708
The "hot paths" are some of the lower-level functions that turn keywords/symbols into SQL that would previously allow arbitrary input, passed through keyword or symbol and then into HoneySQL's DSL, which could be used to essentially produce SQL injection attacks.
There was already a "suspicious entity check" that disallowed ; in SQL entity names, but a) it didn't check for , which could be used to injection malicious subqueries and b) it wasn't applied on every path that produced SQL entity names.
Previously "most" entity names were checked but some paths just called sql-kw without checking the underlying string and the :'... form wasn't checked and nor was the %fn.arg form. The biggest performance hit is in sql-kw since that previously had no entity check.
A CVE has been requested. My feeling is that although this is, by definition, a critical vulnerability, HoneySQL is very rarely used in a way where arbitrary user input (or other data) would be fed into the DSL like this.
Right that was my thoughts re what would you need to be doing to get exposed to these. If you're inlining user generated data you're going to have a bad time regardless. Not particularly concerning to me. I mean it's still good to guard against these things. I'll check out 2.7.1390. 🙏