HTTP Response Splitting in CF2018

[Jdsplicer]

Hi, we recently had a security scan on one of our apps and we were dinged with "HTTP Response Splitting" issue. It occured on my .CFC pages. Below is what the testers performed on my CFC and the results.

I am running CF2018 Enterprise 2018.0.09.318650. I was curious if anyone had any suggestions on how to remediate this. My first step was to make sure "Enable Global Script Protection" was checked in the cfadmin, which it is. From there I believe the neo-security.xml file can be updated to help prevent CRLF injection, not sure what that would look like. Quite honestly I am not sure if that is the best or proper method. I get a little leary messing with some of the CF underlying files. Anyone have any other or better ideas?

Thanks

[James Moberg]

I noticed that the page was actually 404.  I performed a similar GET request against a CF2016 (non-enterprise) server to a non-existent CFC script and didn't see the extra response header returned.  I appended the following string to the URL param (I hope that I got it right) and it wasn't returned.

%0d%0aAppScanHeader:%20AppScanValue%2f1%2e2%2d670%0d%0aSecondAppScanHeader:%20whatever

Do you have any other technologies in front of the ColdFusion server?

Which web server are you using?  (We use IIS.)

Are you able to perform the test yourself on the server?

Are you able to perform the same test on other known ColdFusion servers?

[Jdsplicer]

Hi Jamo, we are running on top of WebSphere 9. I actually get a 403 forbidden error when I try to replicate what they did and I do not see those values in the request or response headers but only in the query string parameters from the URL. I am asking them to rescan to see if the issue still exists.

Thanks.

[BKBK]

Same in my test. The 'AppScanHeader' values come out as query-string parameters.

[Jdsplicer]

So rescan still showed the issue. I was able to actually reproduce the issue where the new header was showing even though it still returned a 404 error message. The way I resolved the issue was to add the following code below to my Application.cfc file. This may not be the 100% correct or best solution but this fixed my issue and the rescan confirmed it was no longer able to do the HTTP Response splitting.

<cfif cgi.QUERY_STRING contains "%0d%0a">

<cfset q = reReplaceNoCase(cgi.QUERY_STRING, "%0d%0a", "", "ALL")>
<cflocation url="#cgi.SCRIPT_NAME#?#q#">
</cfif>

Thanks.

[James Moberg]

How were you able to reproduce it?  Is it limited to WebSphere?  I'm curious as to whether this exploit will work with other CF/Server/OS combinations.  What was the full "raw" URL that you used (minus the hostname) that successfully reproduced the exploit?

[Jdsplicer]

Not sure if it is limited to websphere. It was hitting my cfc and after the method name is where the additional url values were added to created header

/services/authorization.cfc?method=getAppEnvironment%0d%0aAppScanHeader:%20AppScanValue%2f1%2e2%2d670%0d%0aSecondAppScanHeader:%20whatever

Response Headers

HTTP/1.1 404 Neither the method getAppEnvironment

strict-transport-security:

Content-Length: 11414

content-language: en-US

appscanheader: AppScanValue/1.2-670

x-frame-options: deny

access-control-allow-methods: GET,PUT,POST,DELETE,OPTIONS

Set-Cookie: JSESSIONID=0000KafftbOevrzzxGkuPZuUSoy:1d0abtc6l; Path=/

Set-Cookie: PD-H-DEV-ID=1_4_1_gFwvmWNZIlR3l6cOQKHu8mJx+Dk+RSOlIFzRug--CX5xmW99; Path=/

x-content-type-options: nosniff

expires: Thu, 01 Dec 1994 16:00:00 GMT

access-control-allow-origin: *

x-powered-by: Servlet/3.1

x-xss-protection: 1; mode=block

secondappscanheader: whatever was found in component

[James Moberg]

It must be occurring due to "x-powered-by: Servlet/3.1".  (I'm not sure what this is.)

We use IIS and we get a CF error that looks like this.

The method getAppEnvironment AppScanHeader: AppScanValue/1.2-670 SecondAppScanHeader: whatever was not found in component D:/www/authorization.cfc.

 This vulnerability must be specific to WebSphere and not ColdFusion.

I think your method of blocking is good.  It doesn't work on my config, but it appears a decent, non-standard vector to protect against.