OpenID4CF Updated To Fix Potential Security Issue

Last week I gave a 30 minute introduction to OpenID at our monthly developer tech talk lunch. Soon after the talk my co-worker Tim Allen sent me this article on a recently discovered security vulnerability in most open source OpenID implementations.

I was particularly interested because I maintain OpenID4CF, which is based on the OpenID4Java library. So I did a little more research into the issue and asked about it on the OpenID4Java mailing list. As it turns out OpenID4Java is potentially vulnerable to this attack, but a user on the list was able to give some advice on how to patch the library based on a fix committed to JOpenID.

Now I don't really know how exploitable this vulnerability is, but given how simple the fix was I went ahead and patched the fork of OpenID4Java I package for OpenID4CF and posted it to RIAForge. Hopefully OpenID4Java will be patched shortly, but in the meantime you can use the version I include with OpenID4CF if you want to protect against this potential vulnerability.

OpenID And ColdFusion

Recently I wanted to investigate building an OpenID identity provider in ColdFusion. While there are a few OpenID consumer libraries out there, I didn't really find any ColdFusion implementations for an OpenID server. Plus, given that OpenID is an authentication protocol there are heightened security considerations, so I wanted something that was well tested and widely used. This lead me to the OpenID4Java project. Looking at the documentation and source for the project there appeared to be pretty straight forward implementations for both an OpenID provider and consumer via the ServerManager and ConsumerManager classes so I began to port the sample JSP applications over to ColdFusion. That is were my problems began.

[More]

SQL Injection Consideration

Here is something I discovered the other day that surprised me a bit. ColdFusion data sources have an advanced option named "Allowed SQL" which, according to the documentation, defines "the SQL operations that can interact with the current data source." I know some shops use this setting to help protect against SQL injection attacks. For example they may limit a data source to only allow SELECT and Stored Procedures. While you may think that this would go a long way toward protecting the data source against SQL injection, this may not be the case. If the database credentials used for the data source have additional permissions these statements may be executed via SQL injection. For example, consider the following setup:

  • A SQL Server database: TESTDB
  • A table TESTDB.TestTable
  • A database user test_user with SELECT, INSERT, UPDATE, and DELETE permissions to TestTable
  • A ColdFusion data source "test" connected to TESTDB using the test_user credentials and the Allowed SQL option set to only SELECT and Stored Procedures.

Now, consider the following query.

<cfquery name="getItems" datasource="test">
SELECT * FROM TestTable WHERE TestID = #url.testID#
</cfquery>

You may think the above query would be protected against SQL injection because the data source limits the Allowed SQL to SELECT and Stored Procedures, but you would be wrong. Given this setup, the above this code is actually susceptible to SQL injection. Assuming this query were in a template index.cfm, you could easily delete all records in TestTable by issuing a request like index.cfm?testID=1%20DELETE%20FROM%20TestTable.

Now there are a number of ways you could protect against this attack, one of the easiest being the cfqueryparam tag, another being to limit the database user's permissions, but that isn't the point of this post. The point is you can't rely on the Allowed SQL advanced option to protect against SQL injection. You have been warned. (Note: I have only tested this against MS SQL Server so it may not apply to all database engines.)

BlogCFC was created by Raymond Camden. This blog is running version 5.8.001.