databricks-sql-go icon indicating copy to clipboard operation
databricks-sql-go copied to clipboard

[Bug] Driver error: query parameters are not supported by this server

Open csm-kb opened this issue 6 months ago • 5 comments

Hey team, Databricks customer here! (related internal Help ticket 00404964)


Context

  • We use this library to provide access to our data core to our API, for serving customers ETL'd data objects -- via a serverless SQL instance.

We originally implemented the SQL query writes using substitutes like so (this is not real code, very simplified):

import (
  "database/sql"
  "fmt"
  dbsql "github.com/databricks/databricks-sql-go"
)

connector, err := dbsql.NewConnector(
  dbsql.WithAccessToken(config.DatabricksToken),
  dbsql.WithServerHostname(config.DatabricksHost),
  dbsql.WithPort(port),
  dbsql.WithHTTPPath(config.DatabricksHttpPath),
)
// ...
db := sql.OpenDB(connector)

// ...
query := fmt.Sprintf("select * from table where obj_id in (%s) and timestamp > %s", ids, timestamp)
res, err := db.Query(query)

, but this is very bad practice when ids or timestamp are user-provided via GET query parameters (/objects?id=x&id=y).

Even with initial sanitization and validation of the params, it is still a SQL injection vulnerability by static analysis (CWE-89) -- so we need to mitigate that by using the official Go database/sql library's recommendation to use a parameterized SQL query:

queryParams := []interface{}{
  ids,
  timestamp,
}
query := "select * from table where obj_id in (?) and timestamp > ?"
res, err := db.Query(query, queryParams...)

Issue

But, when we try to execute this parameterized query, we receive the following error:

driver error: query parameters are not supported by this server

... which isn't a good thing if we want to query our warehouse directly from the API while mitigating SQL injection.

I haven't taken the time to look, but I do not know if this is a package issue or a SQL Warehouse issue.


Notes

  • If this is in-fact supported by the driver implemented here, then at least this issue will be a historical reminder that it is -- and I'm hoping I can get this in front of whomever owns the SQL Warehouse implement!

csm-kb avatar Dec 22 '23 22:12 csm-kb