7 Replies Latest reply: Jul 29, 2012 4:49 AM by Adam Cameron. RSS

    Is cfinsert and cfupdate open to SQL Injection

    xgen Community Member

      Hello All,

       

      I'm looking for a real answer on if cfinsert and cfupdate are vulnerability to SQL Injection. The closest thing I can find from Adobe is Ben Forta's Personal recommendation. I was hoping to find some form of "official note" in the live docs to indicate there is a SQL Injection issue with cfinsert  - cfupdate. (Other than someone's post  to Ben's Blog)

      http://www.forta.com/blog/index.cfm/2006/10/3/Use-CFINSERT-And-CFUPDATE

       

      In this forum I have seen this question asked, and the only answer is "You should validate your inputs". Yes, you should, but that does not answer the question of if cfinsert and cfupdate is vulnerability to SQL Injection.

       

      I have found this blog entry that if I interpret is correctly from his findings cfinsert and cfupdate where only vulnerability to SQL Injection IF you did not give  cfinsert  - cfupdate the list of fields to take action on. -Is this true?

      http://blog.securityps.com/2009/05/demystifying-cfinsert-sql-injection.html

       

      Also, on a closely related note, is cfinsert  - cfupdate on ColdFusion 9 also vulnerable? If so, why? Seems like a BUG that could be easly addressed by the CF server team.

       

      Thank you,

        • 1. Re: Is cfinsert and cfupdate open to SQL Injection
          Dan Bracuk Community Member

          Try it.  If you are using MS SQL or Sybase, you can putting mulitple queries into a cfquery tag.

           

          Here is your test.  In a numeric field, put "2; update yourtable set somefield = something_else" and submit the form to something with a cfinsert or cfupdate.  See what happens.

          • 2. Re: Is cfinsert and cfupdate open to SQL Injection
            xgen Community Member

            Hello Dan,

             

            First off thanks, Yeah, I could take time and test that one example, its a good idea, but the multi query using the semi colon is one medthod of doing SQL Injection. I'm looking for a bit more of a real answer than the anecdotal, "yup I tried it and it did not do a SQL injection, so it must be safe".

             

            Thanks,

            Mark

            • 3. Re: Is cfinsert and cfupdate open to SQL Injection
              Adam Cameron. Community Member

              There is an issue raised in the CF bugbase - http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=78833.

               

              This implies:

              * yes it's a problem (the issue is open, not closed);

              * no it's not fixed.

               

              --

              Adam

              • 4. Re: Is cfinsert and cfupdate open to SQL Injection
                xgen Community Member

                Thanks Adam!

                 

                I guess from that we can also say that since it is "verified" by Adobe we can call it at least some what "official" that Adobe has confirmed that cfinsert and cfupdate open to SQL Injection.

                 

                Too bad they did not fix that in CF9. It would be a really really simple sell for me to put time / $ it would take to update all of our older code that uses cfinsert and cfupdate to something else, towards an upgrade cost of CF9.

                 

                Shame on Adobe adobe for knowlingly releaseing CF 9 with a security issue.

                • 5. Re: Is cfinsert and cfupdate open to SQL Injection
                  Adam Cameron. Community Member

                  I do agree with you here.  But to be devil's advocate for a second: the same could be said of <cfquery>.  One has to take additional measures to ensure the same vulnerabilities are mitigated with that.

                   

                  I'm not sure that it's really news that these two tags are not the most well-thought-out features in the CF arsenal, and if you listen to most opinions in the community regarding <cfinsert> and <cfupdate>, it's: "don't use them".

                   

                  They're great for quick and dirty insert/update processes in internal or test code, but I'd never use them in production.

                   

                  It also remains a fact that any external input (form fields, URL param) must be validated as being kosher and within expected margins before they're used in any way.  That is just common sense.  And if one neglects to do that: one brings any eventuality onto one's self.  The problem here really is with people not doing their "due diligence" on externally sourced data, not specififcally with <cfinsert>, <cfupdate> or <cfquery>.

                   

                  Still: I think Adobe should make it more clear in the docs that additional measures need to be take to make them safe.  And by that time... one might as well use a <cfquery> to do the SQL.

                   

                  --

                  Adam

                  • 6. Re: Is cfinsert and cfupdate open to SQL Injection
                    xgen Community Member

                    Yes, yes... I know... :-) ...

                     

                    "I'm not sure that it's really news that these two tags are not the most well-thought-out features in the CF arsenal"... well said.

                     

                    Its just that cfinsert and cfupdate is Sooo EZ to use. Yes, I have used a few CF ORMs, data mgr, and hand witten inserts / updates, but I keep comming back to cfinsert and cfupdate to do the simple stuff. I guess cfinsert and cfupdate and me have come to a parting of ways.

                     

                    Thanks

                    MB

                    • 7. Re: Is cfinsert and cfupdate open to SQL Injection
                      Adam Cameron. Community Member

                      Just an update on this old, tired-out thread.

                       

                      I just tested <CFUPDATE> and <CFINSERT> on CF9.0.2 and CF10, and the SQL being sent to the DB is indeed parameterised.

                       

                      --

                      Adam