[
https://issues.apache.org/jira/browse/HIVE-20055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16530404#comment-16530404
]
Andrew Sherman commented on HIVE-20055:
---------------------------------------
I'm not sure I completely understand this jira, but often then best way to
avoid sql injection attacks is to code jdbc using prepared statements.
> SQL injection via metastore ACID APIs (and maybe queries, although that's
> unlikely)
> -----------------------------------------------------------------------------------
>
> Key: HIVE-20055
> URL: https://issues.apache.org/jira/browse/HIVE-20055
> Project: Hive
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Assignee: Thejas M Nair
> Priority: Major
>
> [~thejas] asked me to create this JIRA based on my earlier email :)
> {noformat}
> This might be doable with a specially crafted query, I’m not sure what APIs
> calls have what checks (e.g. via Hive parser) that would prevent the below.
> However, for remote metastore (default on many clusters currently, afaik it’s
> the default for ACID) we expose thrift API that accepts strings e.g.
> get_valid_write_ids.
> That passes the string table names to TxnHandler::getValidWriteIdsForTable,
> that inserts them into the query string w/quoteString call; quoteString
> doesn’t do any validation.
> Some ready made delete statements also exist e.g. "delete from REPL_TXN_MAP
> where RTM_SRC_TXN_ID = " + sourceTxnId + " and RTM_REPL_POLICY = " +
> quoteString(rqst.getReplPolicy());
> I think my replication policy might be {' OR '1' = '1} ;)
> So, SQL injection might be possible thru these APIs.
> I wonder if this class should be switched to parameter based execution?
> DirectSQL could be used as an example, although that uses DataNucleus direct
> sql feature… at least we need some checks on these.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
