You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Michael Werle (JIRA)" <ji...@apache.org> on 2018/05/30 14:32:00 UTC

[jira] [Created] (NIFI-5253) GenerateTableFetch and QueryDatabaseTable use un-escaped string literals

Michael Werle created NIFI-5253:
-----------------------------------

             Summary: GenerateTableFetch and QueryDatabaseTable use un-escaped string literals
                 Key: NIFI-5253
                 URL: https://issues.apache.org/jira/browse/NIFI-5253
             Project: Apache NiFi
          Issue Type: Bug
    Affects Versions: 1.6.0
            Reporter: Michael Werle


{{org.apache.nifi.processors.standard.AbstractDatabaseFetchProcessor#getLiteralByType}} uses un-escaped values from the database as string literals in later statements:

 
{code:java}
protected static String getLiteralByType(int type, String value, String databaseType) {
    // Format value based on column type. For example, strings and timestamps need to be quoted
    switch (type) {
        // For string-represented values, put in single quotes
        case CHAR:
        case LONGNVARCHAR:
        case LONGVARCHAR:
        case NCHAR:
        case NVARCHAR:
        case VARCHAR:
        case ROWID:
        case DATE:
        case TIME:
            return "'" + value + "'";
        ...{code}
The value is the last computed maximum value; it is stored in the state manager un-escaped.  Granted, this is only used for maximum value columns, but it will blow up on anything with a single-quote in it, and presents a really good opportunity for attackers who can manipulate any of these columns.  Ideally, this method should be removed entirely and the code using it refactored to use standard JDBC variable binding.  In the short run, using {{org.apache.commons.lang.StringEscapeUtils#escapeSql}} or simply replacing all instances of a single quote with two single quotes (the SQL escape mechanism) might help; I don't remember if doing so is safe or not.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)