CODEWITHSUNDEEP
sqloracle-databasecoldfusionsql-injection
gfrobenius
gfrobenius

Reputation: 4067

ColdFusion and Oracle SQL Injection Example

Assuming ColdFusion 10,0,13,287689 and Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production.

With this example...

<cfquery name="q" datasource="ds">
    update someTable set
    #form.col#label = <cfqueryparam cfsqltype="cf_sql_varchar" value="#x#">
    where id = <cfqueryparam cfsqltype="cf_sql_decimal" value="#id#">
</cfquery>

Also assuming there is no data validation checking on #form.col#, how could this be exploited? Obviously they could cause the query to fail with an invalid column, but I don't see any way something more malicious could be done since multiple statements cannot be ran in a single <cfquery>. So something like this does not work...

#form.col#:

id = 1; delete from users; --comment everything else out...

I'm aware that with SELECTs it's easier to exploit using unions to get data you're not authorized to see, but I'm curious about this specific update statement.

Upvotes: 0

Views: 672

Answers (1)

Peter Boughton
Peter Boughton

Reputation: 112160

Whilst the traditional example for SQL injection involves sequential SQL statements, that is only a simple example used to highlight the issue - if unprotected user-derived text is allowed anywhere in any query there's a chance an attacker will be able to make use of it.

In this specific example, your query is:

update someTable
set #form.col#label = ?
where id = ?`

To abuse that is simple - prefix a genuine col value with something like:

public_column = (SELECT badly_encrypted_password 
FROM users WHERE username='admin' ), <orig_value>

The resultant SQL is then:

update someTable
set public_column = ( SELECT badly_encrypted_password FROM users WHERE username='admin' )
  , <orig_value>label = ?
where id = ?`

Which of course sets the value of that column to the result of the sub-query, and then a separate select in another area would then innocently return the sensitive data.

Alternatively, an attacker may decide simply to deface/remove data using this method, and depending on what precisely Oracle's SQL syntax allows, other things might be possible.

Upvotes: 5

Related Questions