• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

HTTP Response Splitting in CF2018

Explorer ,
Oct 26, 2020 Oct 26, 2020

Copy link to clipboard

Copied

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.

 

crlf.JPG

 

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

Views

634

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Oct 27, 2020 Oct 27, 2020

Copy link to clipboard

Copied

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?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Oct 27, 2020 Oct 27, 2020

Copy link to clipboard

Copied

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.

 

Jdsplicer_0-1603826398483.png

 

Thanks.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Oct 28, 2020 Oct 28, 2020

Copy link to clipboard

Copied

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

BKBK_0-1603911540129.png

 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Oct 29, 2020 Oct 29, 2020

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Oct 29, 2020 Oct 29, 2020

Copy link to clipboard

Copied

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?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Oct 29, 2020 Oct 29, 2020

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Oct 29, 2020 Oct 29, 2020

Copy link to clipboard

Copied

LATEST

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
Documentation