2

I have a table like...

THINGS_TABLE
============
thing_key           int              PRIMARY KEY
thing_num           varchar(20)
thing_title         varchar(20)
thing_description   varchar(20)

And some ColdFusion (server-side code) functions that can add, edit and delete from this table. For example a createThing function might look like this in ColdFusion. The cfqueryparam parameters in the cfquery should prevent SQL injection, so I don't think SQL injection is something I need to worry about.

<cffunction name="createThing" access="remote" returntype="void">
    <cfargument name="thing_num" type="string" required="yes">
    <cfargument name="thing_title" type="string" required="yes">
    <cfargument name="thing_description" type="string" required="yes">

    <!--- write to db --->
    <cfquery name="createThingQuery" datasource="my_datasource">
        INSERT INTO THINGS_TABLE (thing_num, thing_title, thing_description) values (   
        <cfqueryparam cfsqltype="cf_sql_varchar" value='#thing_num#'>,
        <cfqueryparam cfsqltype="cf_sql_varchar" value='#thing_title#'>,
        <cfqueryparam cfsqltype="cf_sql_varchar" value='#thing_description#'>)
    </cfquery>
</cffunction>

Is it safe to reveal the actual column names in ajax calls that run the server-side code? For example, an ajax call that might look like this:

$.ajax({
    type: "POST",   
    url: "thingFunctions.cfc",
    data: { method : "createThing",
            thing_num : "the number",
            thing_title : "the title",
            thing_description : "the description"
            }})

This ajax makes it really obvious what the actual column names are in the database, and it is certainly possible for my ColdFusion function to use different argument names, but is there actually any advantage to use different names? It seems to me like it might just make the code more confusing for a developer to read, without providing any advantages from a security standpoint.

Also, perhaps there are other issues with using ajax calls like this that I'm not thinking of? I.e. a user maybe could edit the page JavaScript and call my ColdFusion code in ways it wasn't originally intended?

  • Related: security.stackexchange.com/questions/108515/… – TTT Mar 25 '16 at 21:22
  • Not directly a security thing but if you change something with the column names, all client code will break. This might be not the best design practice and changing code could introduce bugs which could be security relevant. The design pattern you could have a look at is called data model transformation – Noir Mar 25 '16 at 21:44
  • 1
    @Noir, the CF code is doing a data mapping. It's just mapping to the same name. If the table columns change, only the insert line on the server will change. – Neil Smithline Mar 26 '16 at 14:15
  • @Noir, Niel Smithline is absolutely correct. If we decided to change the column names at some future time, we would only have to change the INSERT INTO THINGS_TABLE (thing_num, thing_title, thing_description) line. Specifically the list of column names located there. Everything else could stay exactly the same. In fact this is the exact reason why this question exists--since it is possible to use names that differ from the actual column names in the data object that $.ajax accepts it made me wonder if there is any security advantage to doing so. – Ectropy Mar 28 '16 at 13:44
1

Not providing a direct mapping to column names is obfuscation. Security through obfuscation should not be relied on, but it does help, if only a little. As you point out, though, the question is to whether the tradeoff in obscuring these names is worth the extra maintenance burden. This is a matter of opinion, but I tend to say it isn't - even from a strictly security perspective, more obvious code is code that's less likely to have security issues.

Also, perhaps there are other issues with using ajax calls like this that I'm not thinking of? I.e. a user maybe could edit the page JavaScript and call my ColdFusion code in ways it wasn't originally intended?

An attacker can always modify anything on their own client. This is a fundamental point of web security.

I don't know ColdFusion enough to really understand what's going on in your example, but it looks like an attacker can just feed values into an endpoint to create new rows in your table. Should only certain types of users be able to do that? If so, you better put some authorization and authentication on the endpoint. Will there be problems if the table gets really large? Enforce per-user and per-IP rate-limits, and create an alert when the table reaches warning and critical levels.

  • That sounds like roughly what I was thinking. Doing extra work (and introducing confusion for developers reading the code) just for some security through obfuscation probably wouldn't give any real advantage. BUT I do see your point that the actual ColdFusion function should accept some sort of info to ensure that it's actually my application running the ajax, and that the user running the ajax is actually authorized to do so. In the example function there is no such verification, and thus there's nothing to stop a person from using the function as long as they know the ajax call to write. – Ectropy Mar 25 '16 at 18:22
2

I would agree with Xiong that obfuscation of table column names makes your code more complicated, and harder to understand. If you do this with every table, you might confuse other developers (or yourself, looking at the code a year later).

(I assume that your database is not directly reachable from the internet, but only through your own backend. If it is, you should review your architecture.)

Also, perhaps there are other issues with using ajax calls like this that I'm not thinking of? I.e. a user maybe could edit the page JavaScript and call my ColdFusion code in ways it wasn't originally intended?

Be always prepared that your API might not only be called from your own web page, but also from a curious developer, trying it out for fun, after having looked at the JavaScript code or HTTP traffic:

  • You should always validate user data before persisting it. Otherwise you might end up fixing data causing exceptions somewhere in your backend (e.g. trying to parse a string as date, but having just a garbage string value).
  • If your API route causes database rows to be added, it should probably only be available to authenticated users.
  • Your assumption that the database is not directly reachable from the internet is correct. Server-side code like ColdFusion is the only way we access it. Looks like the next step for me is making sure that the CF functions only are allowed to be called by authenticated users who I know are actually using my application, and not some ajax call they wrote themselves. That's a whole different question from this one, however. – Ectropy Mar 28 '16 at 13:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.