[yairchu]

Doesn't it cause a "Javascript eval injection" vulnerability?

I don't know Javascript so I may be wrong here, but:

* Suppose someone uses this library to create a "MariaSQL Explorer App", where you give the app connection credentials and it connects to the database and shows you the data etc.

* A malicious attacker tells a user "have a look at my database" and the user goes to the attacker's database.

* The attacker's database (or spoof of one) has a column called 'dummy": MALICIOUS_CODE(), "colname'. notice the '"' chars inside column name.

* The MALICIOUS_CODE() runs in the user's node.js app. Perhaps it sends the attacker the passwords to other databases from the app's keychain or something..

* Profit

[Groxx]

Which is why you sanitize input. Which every sql-communicating system must eventually do somewhere - this is no different.

Besides, that's just an example snippet.

[Zr40]

If you sanitize input, it implies you're inserting the input into an execution environment. If possible, it's better to treat data as data.

In the Javascript eval case, it's definitely possible; just access the data through a variable instead of inserting it into the eval'ed code.

[snprbob86]

As Groxx points out, yes, you need to sanitize input. It's pretty easy to return an error if the user input doesn't match a whitelisting regex. It can be as simple as /[a-z][a-z0-9]*/i

However, in a Lisp, eval typically works on lists, not on strings. In effect, behaving like a parametric SQL query: a quotation mark or close paren or whatever in the string would be harmless.