websecurity@lists.webappsec.org

The Web Security Mailing List

View all threads

Re: [WEB SECURITY] CRLF Injection - HTTP Response Splitting

M
Mon
Thu, May 3, 2012 8:51 AM

Hi Tanuj,

Thanks for your reply. I tried with a larger string
(%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a,
%0d%0a%0d%0a%0d%0a%0d%0a%20%0d%0a%0d%0a%0d%0a%0d%0a, etc.)

The response doesn't split and %0d%0a appear as printable characters in the
output.

Location:
https://domain.org/path/res.asp?https=redirect&key1=value1&key2=value2&key3=value3%0d%0a%0d%0a%0d%0a%0d%0a%20%0d%0a%0d%0a%0d%0a%0d%0aContent-Length:%200

%0d%0a encoding for CRLF doesnt seem to work, hence, I was trying different
encodings.

Br,

m0n

On Wed, May 2, 2012 at 5:01 PM, Tanuj Pathak Tanuj.Pathak@mphasis.comwrote:

Hi Mon,

First of all, we appreciate you to discuss  the concern because the
output varies for different applications. So nothing is stupid or
superb doubt here.
For your case we wanted to you to check with a large set of string also (
like  %0d%0a %0d%0a %0d%0a%0d%0a %0d%0a  ) as primary step. Then we can
go to a conclusion.
**
**
Tan


From: websecurity-bounces@lists.webappsec.org on behalf of Mon
Sent: Mon 4/30/2012 6:02 PM
To: websecurity@webappsec.org
Subject: [WEB SECURITY] CRLF Injection - HTTP Response Splitting

Hi all,

May be this a very stupid question, however, after many unsuccessful
attempts, I would appreciate your assistance.

In testing a web application, I found that on sending the following
request header:

GET /path/path-contd/resource.asp?key1=value1&key2=value2&key3=value3
HTTP/1.1
....

I got the the following response header:

HTTP/1.1 302 Found
Date: xxxx
Server: xxxx
Location: https://
<full-domain>/path/path-contd/resource.asp?https=redirect&key1=value1&key2=value2&key3=value3
....

I tried to inject "CRLF" (%0d%0a) in value3 to perform a HTTP Response
Splitting, however, the input was always output to the response header as
text and the injected CRLF (%0d%0a) was never executed. I tried:

  1. double url encoding: %250d%250a
  2. encoding the attack vector to unicode 16-bit
  3. injecting %0d%0a (and double encoded value) in value1 instead
  4. injecting %0d%0a (and double encoded value) in value2 instead

Am I missing something trivial or any other attack vector to bypass CRLF
Injection protection/filter? Is this the right approach? Or should I safely
assume that the application is performing proper URL sanitization?

Look forward to your replies. My apologies again in case my question is
naive.

Br,
m0n

Information transmitted by this e-mail is proprietary to MphasiS, its
associated companies and/ or its customers and is intended
for use only by the individual or entity to which it is addressed, and may
contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended
recipient or it appears that this mail has been forwarded
to you without proper authority, you are notified that any use or
dissemination of this information in any manner is strictly
prohibited. In such cases, please notify us immediately at
mailmaster@mphasis.com and delete this mail from your records.

Hi Tanuj, Thanks for your reply. I tried with a larger string (%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a, %0d%0a%0d%0a%0d%0a%0d%0a%20%0d%0a%0d%0a%0d%0a%0d%0a, etc.) The response doesn't split and %0d%0a appear as printable characters in the output. Location: https://domain.org/path/res.asp?https=redirect&key1=value1&key2=value2&key3=value3%0d%0a%0d%0a%0d%0a%0d%0a%20%0d%0a%0d%0a%0d%0a%0d%0aContent-Length:%200 %0d%0a encoding for CRLF doesnt seem to work, hence, I was trying different encodings. Br, -- m0n On Wed, May 2, 2012 at 5:01 PM, Tanuj Pathak <Tanuj.Pathak@mphasis.com>wrote: > Hi Mon, > > First of all, we appreciate you to discuss the concern because the > output varies for different applications. So nothing is stupid or > superb doubt here. > For your case we wanted to you to check with a large set of string also ( > like %0d%0a %0d%0a %0d%0a%0d%0a %0d%0a ) as primary step. Then we can > go to a conclusion. > ** > ** > *Tan* > > ------------------------------ > *From:* websecurity-bounces@lists.webappsec.org on behalf of Mon > *Sent:* Mon 4/30/2012 6:02 PM > *To:* websecurity@webappsec.org > *Subject:* [WEB SECURITY] CRLF Injection - HTTP Response Splitting > > Hi all, > > May be this a very stupid question, however, after many unsuccessful > attempts, I would appreciate your assistance. > > In testing a web application, I found that on sending the following > request header: > > GET /path/path-contd/resource.asp?key1=value1&key2=value2&key3=value3 > HTTP/1.1 > .... > > > I got the the following response header: > > HTTP/1.1 302 Found > Date: xxxx > Server: xxxx > Location: https:// > <full-domain>/path/path-contd/resource.asp?https=redirect&key1=value1&key2=value2&key3=value3 > .... > > I tried to inject "CRLF" (%0d%0a) in value3 to perform a HTTP Response > Splitting, however, the input was always output to the response header as > text and the injected CRLF (%0d%0a) was never executed. I tried: > > 1. double url encoding: %250d%250a > 2. encoding the attack vector to unicode 16-bit > 3. injecting %0d%0a (and double encoded value) in value1 instead > 4. injecting %0d%0a (and double encoded value) in value2 instead > > Am I missing something trivial or any other attack vector to bypass CRLF > Injection protection/filter? Is this the right approach? Or should I safely > assume that the application is performing proper URL sanitization? > > Look forward to your replies. My apologies again in case my question is > naive. > > Br, > m0n > > Information transmitted by this e-mail is proprietary to MphasiS, its > associated companies and/ or its customers and is intended > for use only by the individual or entity to which it is addressed, and may > contain information that is privileged, confidential or > exempt from disclosure under applicable law. If you are not the intended > recipient or it appears that this mail has been forwarded > to you without proper authority, you are notified that any use or > dissemination of this information in any manner is strictly > prohibited. In such cases, please notify us immediately at > mailmaster@mphasis.com and delete this mail from your records. >