Example: Preventing an Injected SET QUERY_BAND from Changing the Proxy User - Teradata VantageCloud Lake

Lake - Working with SQL

Deployment
VantageCloud
Edition
Lake
Product
Teradata VantageCloud Lake
Release Number
Published
February 2025
ft:locale
en-US
ft:lastEdition
2025-11-21
dita:mapPath
jbe1714339405530.ditamap
dita:ditavalPath
pny1626732985837.ditaval
dita:id
jbe1714339405530

You can use the standard application programming interfaces such as CLIv2, JDBC, or .NET to enable an application to designate an SQL request as being either trusted or not trusted.

If the application submits SQL requests created or modified by a client user, you may want to require that all SET QUERY_BAND requests that set a proxy user be submitted in trusted requests. Grant the CONNECT THROUGH WITH TRUST_ONLY privilege to the trusted user (see GRANT CONNECT THROUGH). With this privilege, Vantage requires that any SET QUERY_BAND requests submitted by a trusted user that either set or remove a proxy user be designated as a trusted request.

Using an API, the application can mark requests from user input as being not trusted to prevent the client from injecting a SET QUERY_BAND request that changes the proxy user or proxy role.

To use this feature in JDBC, create a JDBC DataSource with TRUSTED_SQL=ON. Requests on the DataSource are then trusted unless you downgrade them with the escape function {fn teradata_untrusted}.

For requests containing user-input SQL requests, the application can prepend the {fn teradata_untrusted} escape function to the SQL call before the request is passed to the Teradata JDBC Driver. This escape function sets the request to the not trusted state. For example,

     untrustedSQL = "{fn teradata_untrusted}"   untrustedSQL ;