Skip to content

Instantly share code, notes, and snippets.

@sergiotapia
Created May 6, 2014 16:39
Show Gist options
  • Save sergiotapia/89c2b90251c4d489a162 to your computer and use it in GitHub Desktop.
Save sergiotapia/89c2b90251c4d489a162 to your computer and use it in GitHub Desktop.

This advisory concerns a security risk in all supported versions of Active Record. There is no patch to apply for this issue.

Due to the query API that Active Record supports, there is a risk of unsafe query generation in two scenarios. Databases with a table that contains a column with the same name as the table and queries with join aliases which conflict with column names could be vulnerable to an attack where the attacker can perform certain manipulations to the SQL queries generated by Rails.

Determining Vulnerability

A vulnerable application will either contain columns named identically to their table, or have column names which conflict with join aliases.

For example, if you had a model called SecurityToken, which contained an attribute called security_tokens then the following code could be manipulated to return additional records:

SecurityToken.find_by_security_tokens(params[:security_tokens])

Due to the typical approach of pluralizing for tables and using singular names for columns, this kind of conflict is very unlikely.

The second scenario would be join aliases which conflict with a column name already in the query. For instance suppose users has a denormalized column contacts which indicates how many times a user has been contacted, and a Contact record for each. The following query could be manipulated to return additional records:

User.joins(:contacts).where(contacts: params[:contacts])

Workarounds

The simple work around is to call to_s on the value from params:

SecurityToken.find_by_security_tokens(params[:security_tokens].to_s)

User.joins(:contacts).where(contacts: params[:contacts].to_s)

Alternatively, rename any columns which collide with table names or likely join aliases.

Future Fixes

Unfortunately it is not possible to implement a reliable fix for this risk without breaking applications which rely on related functionality to build their queries. Future releases of Rails will be able to address this, however that functionality will need to be built in the open and have a long beta period to flush out unanticipated edge cases.

Credits

Thanks to Joe van Dyk and to Fraser Newton of Clio for reporting the issue to us.

@wedy
Copy link

wedy commented Jul 3, 2014

Hi Sergio, thanks for the info, im still not sure how the attack can be performed here

User.joins(:contacts).where(contacts: params[:contacts])
what will be in params[:contacts] that can break the applications

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment