7 Replies Latest reply on Jun 18, 2014 9:23 AM by BreakawayPaul

    Addressing security scan results

    BreakawayPaul Level 2

      My office uses something called "IBM Security AppScan Standard" to scan web apps.  Two of the things it scans for (of course) are XSS and SQL injection.


      One of my pages got flagged despite my use of cfqueryparam, isValid(), and htmleditformat().  What happens is if you intercept the post data from the form and append something like &foo to a numeric value, you get back a CF error page that looks something like this:

      500 - Internal server error.




      at coldfusion.filter.FormScope.parseQueryString(FormScope.java:349)

      at coldfusion.filter.FormScope.parsePostData(FormScope.java:321)

      at coldfusion.filter.FormScope.fillForm(FormScope.java:271)

      at coldfusion.filter.FusionContext.SymTab_initForRequest(FusionContext.java:437)

      at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:33)

      at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)

      at coldfusion.filter.RequestThrottleFilter.invoke(RequestThrottleFilter.java:126)

      at coldfusion.CfmServlet.service(CfmServlet.java:175)

      at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89)

      at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)

      at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42 )

      at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)

      at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)

      at jrun.servlet.FilterChain.service(FilterChain.java:101)

      at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)

      at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)

      at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:286)

      at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543)

      at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203)

      at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428)

      at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)


      I've tried just about everything to get rid of this, including cftry/cfcatch, isvalid, replace(), and a few other things, but I still get the 500 error.


      I'm pretty sure the error is what's triggering the security alert.  Any ideas on how to fix this?

        • 1. Re: Addressing security scan results
          Dave Ferguson Level 3

          The actual code that is causing the error would be helpful.

          • 2. Re: Addressing security scan results
            BreakawayPaul Level 2

            Ok, let me try to narrow it down, otherwise I'll be posting a colossal text dump.  I can at least figure out of it's coming from the update query or the code itself.

            • 3. Re: Re: Addressing security scan results
              BreakawayPaul Level 2

              Ok, this seems to be a JRun problem, because even if I submit my form to a blank page with no processing, I still get the error.


              I tried it with this:

              <form action="temp.cfm" method="post" name="test">

              <p><label for="namefield">Name</label> <input type="text" name="namefield" id="namefield" size="30" /></p>

              <input type="submit" name="submitform" value="Submit" />


              And got the exact same error.

              • 4. Re: Addressing security scan results
                Steve Sommers Level 4

                I think there is something else going on. Do you have some code doing any sort of processing on the URL or FORM scoped variables in your application.cfc or cfm page? Your test.cfm page above works fine for me on CF11 & 9.

                • 5. Re: Addressing security scan results
                  BreakawayPaul Level 2

                  Nothing really, and I even renamed my application.cfm file.  I even tested it on localhost on my local machine in the CF Dev environment.


                  What I'm doing is this:


                  1. Load the page.
                  2. Open a Firefox addon called "Tamper Data".  We've found this to pretty closely replicate the scanner that out security people use.  If it passes this addon, it passes the scan, and vice versa.
                  3. Click "Start Tamper".
                  4. Type a number into the form field, then submit.
                  5. When the addon asks, I edit that post field by adding &foo, then click submit.


                  That gives me the error.


                  Perhaps the addon/scanner are doing something behind the scenes that we don't know about?

                  • 6. Re: Addressing security scan results
                    Steve Sommers Level 4

                    Ah, that duplicated the issue for me. In CF9 I get the 500 error. In CF11 I get a 400 response with a description of "The request sent by the client was syntactically incorrect." Both are correct responses because the syntax is incorrect -- the & should be encoded as &amp; if it is part of the field data value that it follows or foo must be followed by an = sign to delimit the field=value pair.


                    The scanner is probably complaining about the detail of the error message. All the root cause info sets scanners into a panic. I believe the URL and FORM field parsing is happening in the java runtime prior to coldfusion having control meaning prior to any cferror traps in application.cfc or .cfm files. You will most likely need to configure the java error handler to not display the details or execute your error template via a redirect. I've done this before but it's been a while and I do not remember off the top of my head how to do this. Google "coldfusion java error trap". Here is one reference for CF9 but remember CF10 and 11 uses Tomcat instead of JRun so the configuration might be slightly different: Handling 500 JRun servlet in ColdFusion - Stack Overflow

                    • 7. Re: Addressing security scan results
                      BreakawayPaul Level 2

                      Thanks Steve, that helps since we're using CF8, so the CF9 procedure will probably still work.

                      1 person found this helpful