CODEWITHSUNDEEP
sqlcoldfusionincludesql-injection
FunkoRobo
FunkoRobo

Reputation: 11

ColdFusion sql issue

Ran a security scan against an URL and received the report below:

The vulnerability affects

 /rolecall.cfm , bbb_id

This is the rolecall.cfm code:

<cfscript>
if (isDefined("url") and isDefined("url.bbb_id")) {
    if (url.dept_id eq -1)
        _include("sql", "getB");
    else
        _include("sql", "getBNow");
}

/*...*/
_include("sql", "getDPlaces");

/*Set up the model and go*/
model = {
    add    = 1,
    edit   = 0,
    remove = 0,
    places   = getDPlaces
};
</cfscript>

Upvotes: 1

Views: 149

Answers (2)

Adrian J. Moreno
Adrian J. Moreno

Reputation: 14859

If you're using IIS, you should read this article to see how to add SQL Injection protection directly to the web server. This will keep attack requests from ever reaching ColdFusion.

Be cautious of the strings they suggest you deny: 

<denyStrings> 
   <add string="--" /> 
   <add string=";" /> 
   <add string="/*" /> 
   <add string="@" />

Make sure you never pass an email address as the value of a query string parameter, otherwise you'll reject a legitimate request. You can allow the @ symbol if needed.

I would also highly suggest you take a look at HackMyCF, which will show you many other security concerns if they exist.

Upvotes: 4

SOS
SOS

Reputation: 6550

SQL Injection exploits databases by stuffing malicious sql commands into a query where they're not expected. Tricking the query into do something different than what it was designed to do, like performing a DROP or DELETE instead of a SELECT.

  1. Queries that use raw client parameters like this, are vulnerable: 

    WHERE policy_funct_id = #url.dept_id#

    Instead, always wrap client supplied parameters in cfqueryparam. It prevents them from being executed as a command. I don't know your column data types, so modify the cfsqltype as needed.

    WHERE policy_funct_id = <cfqueryparam value="#url.dept_id#" cfsqltype="cf_sql_integer">

  2. All of the dynamic table names are another (potential) vulnerability, like:

    -- potential sql-injection risk
SELECT * FROM #db.root#

    If #db.root# is user supplied, it's a sql-i risk. Unfortunately, cfqueryparam cannot be used on table names. Those must be manually (and carefully) validated.

Few other suggestions, unrelated to sql injection:

  • All the nested (select * from...) statements decrease readability. Instead, use a single level JOIN.

  • When using JOIN's, best to specify the source table (or table alias) for all columns. That avoids ambiguity and increases readability for yourself and anyone else reviewing the code. No need to guess which columns comes from which table.

Example

-- psuedo example
 SELECT  root.ColumnA
    , root.ColumnB
    , dept.ColumnC
    , subcat.ColumnC
    , etc... 
 FROM #db.root# root 
       INNER JOIN #db.content# content ON root.policy_root_id = content.content_id
       INNER JOIN #db.dept# AS dept ON ON content.dept_id = dept.policy_funct_id
       INNER JOIN #db.subcat# subcat ON subcat.dept_id = dept.policy_funct_id
 WHERE dept.policy_funct_id = <cfqueryparam value="#url.dept_id#" cfsqltype="cf_sql_integer">
 AND   content.is_newest = 1

Upvotes: 3

Related Questions