zeroshade commented on PR #1738: URL: https://github.com/apache/arrow-adbc/pull/1738#issuecomment-2070087202
@lidavidm Ultimately this comes down to the question of who is responsible for ensuring we avoid sql injection vs ease of use. Because we provide this whole bulk ingestion API via options to define the table name etc, is ADBC itself (and therefore every driver) responsible for ensuring there's no sql injection? Or is the application that is *using* ADBC responsible for ensuring there's no injection in the value they pass for the option of the table name? Since ADBC itself allows arbitrary SQL strings it feels like it should be the **application's** responsibility for ensuring there's no sql injection rather than ADBC (and therefore every driver). There's also the case that blindly adding quotes like we were doing isn't sufficient to prevent sql injection anyways and only served to create failure cases for the ingestion rather than potentially reasonable results (see [here](https://github.com/apache/arrow-adbc/issues/1721#issuecomment-2059353483)). One possible solution could be for us to try to use the snowflake `IDENTIFIER` function https://docs.snowflake.com/en/sql-reference/identifier-literal which might solve the issue while preventing injection? it's still not perfect though unless we also check for un-escaped single quotes in the passed in string and forcibly escape them etc. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
