You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2008/06/10 23:50:41 UTC
DO NOT REPLY [Bug 45180] New: CRLF Newline characters stripped from
header values
https://issues.apache.org/bugzilla/show_bug.cgi?id=45180
Summary: CRLF Newline characters stripped from header values
Product: Tomcat 5
Version: 5.5.26
Platform: PC
OS/Version: Windows Server 2003
Status: NEW
Severity: blocker
Priority: P2
Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: asf-bugzilla@rodneybeede.com
While trying to implement RFC 2231 with "Parameter Value Continuations" I had a
header that should appear as follows:
Content-Disposition: attachment;
filename*0="Rodney.20080516.VaR_Simple.HG2008_HG2008_20080516_issueDetailLog";
filename*1="_boy_this_is_a_long_header_value";
filename*2="_now_is_it_not.csv"
That is according to RFC 2231 which allows this. I use
HttpServletResponse.addHeader(String,String) to add the appropriate header as
so:
addHeader("Content-Disposition", above value with \r\n inside the string)
Unfortanetely Tomcat is replacing my String's "\r\n" after each ";" with two
spaces instead.
This results in the actual header returned to the browser being:
Content-Disposition: attachment;
filename*0="Rodney.20080516.VaR_Simple.HG2008_HG2008_20080516_issueDetailLog";
filename*1="_boy_this_is_a_long_header_value";
filename*2="_now_is_it_not.csv"
[Each ; is followed by <space><space><tab>filename instead of
\r\n<tab>filename]
Firefox 2.0.14 will gracefully correct this malformed, non-compliant RFC2231
header, but Internet Explorer 6 nor 7 will handle this correctly. IE is more
strict about the RFC2231 format.
I believe this may have been implemented to discourage XSS mistakes in code,
but now it breaks using \r\n inside header values.
Perhaps a new method such as "addUncheckedHeader(String,String)" that doesn't
scrub the \r\n would be appropriate?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45180] CRLF Newline characters stripped from
header values
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45180
--- Comment #4 from Jim Manico <ji...@manico.net> 2008-06-11 17:36:39 PST ---
It is actually quite illegal to have \r (carriage return) \n (newline) inside
of a HTTP 1.1 Header Value. If any HTTP server allows CLRF inside of a header
value, it can and will lead to HTTP Response Splitting Attacks.
http://en.wikipedia.org/wiki/HTTP_response_splitting
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
defines a field value to be of the following form. LWS is whitespace, so we are
really concerned about field-content in the spec.
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
That leads us to http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2
as Mark pointed out. TEXT and TOKEN explicitly disallows \r\n:
token = 1*<any CHAR except CTLs or separators>
TEXT = <any OCTET except CTLs,
but including LWS>
Where CTL's are defined as:
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
Separators are different from CTL's.
That leads us to quoted-strings
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
Whose elements are defined as:
qdtext = <any TEXT except <">>
The backslash character ("\") MAY be used as a single-character quoting
mechanism only within quoted-string and comment constructs.
quoted-pair = "\" CHAR
Ah, so rtf 2616 DID allow \r\n in header values you might say - but changeset
238 http://www3.tools.ietf.org/wg/httpbis/trac/changeset/238 amended rfc 2616
to disallow quoted-pair escaping of NUL, CR and LF.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45180] CRLF Newline characters stripped from
header values
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45180
--- Comment #7 from Julian Reschke <ju...@gmx.de> 2008-06-11 23:42:48 PST ---
> You are wrong. CLRF's in LWS is an OPTIONAL part of the HTTP 1.1 spec that
> anyone who cares about security ignores.
I didn't say that they are required to be sent. However it is *allowed* to send
them, thus a recipient must handle them correctly.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45180] CRLF Newline characters stripped from
header values
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45180
--- Comment #8 from Jim Manico <ji...@manico.net> 2008-06-11 23:48:32 PST ---
Right. And as Mark earlier stated per:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2
"A recipient MAY replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream."
Tomcat is making the compliant and secure choice, hence the "resolved" status
of this bug.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45180] CRLF Newline characters stripped from
header values
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45180
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #2 from Mark Thomas <ma...@apache.org> 2008-06-11 09:08:02 PST ---
>From section 2.2 of the HTTP/1.1 spec (rfc2616)
<quote>
HTTP/1.1 header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream.
</quote>
In an HTTP environment CR and LF characters may be converted to SP. Proxies are
one example where this might happen. You cannot rely on this conversion never
taking place.
You are correct that where Tomcat does this, it does it for security reasons.
This is valid since in HTTP, LWS has the same meaning as SP (see quote above).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45180] CRLF Newline characters stripped from
header values
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45180
--- Comment #5 from Julian Reschke <ju...@gmx.de> 2008-06-11 23:25:25 PST ---
>It is actually quite illegal to have \r (carriage return) \n (newline) inside
>of a HTTP 1.1 Header Value. If any HTTP server allows CLRF inside of a header
>value, ...
In general that's incorrect. CRLF is allowed as part of LWS (linear white
space).
> ... it can and will lead to HTTP Response Splitting Attacks.
That may be true, but doesn't affect what's legal or not.
If you think the HTTP spec should disallow CRLFs in header values, then better
join the httpbis working group and argue the case over there.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45180] CRLF Newline characters stripped from
header values
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45180
--- Comment #6 from Jim Manico <ji...@manico.net> 2008-06-11 23:34:31 PST ---
You are wrong. CLRF's in LWS is an OPTIONAL part of the HTTP 1.1 spec that
anyone who cares about security ignores.
[rule]
Square brackets enclose optional elements; "[foo bar]" is equivalent to
"*1(foo bar)".
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45180] CRLF Newline characters stripped from
header values
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45180
Julian Reschke <ju...@gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |julian.reschke@gmx.de
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45180] CRLF Newline characters stripped from
header values
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45180
--- Comment #1 from Julian Reschke <ju...@gmx.de> 2008-06-11 04:09:14 PST ---
>Firefox 2.0.14 will gracefully correct this malformed, non-compliant RFC2231
>header, but Internet Explorer 6 nor 7 will handle this correctly. IE is more
>strict about the RFC2231 format.
How is the rewritten header non-compliant with respect to HTTP? Keep in mind
that HTTP uses a format similar to MIME it is not the same; for instance,
there's no fixed line width limit.
Besides, as far as I recall, IE does not support RFC2231 anyway (if it does I'd
love to find out what it supports exactly).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45180] CRLF Newline characters stripped from
header values
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45180
--- Comment #3 from Rodney <as...@rodneybeede.com> 2008-06-11 09:21:12 PST ---
I concur with the previous comments. According to the HTTP 1.1 spec (RFC 2616)
there is no line length limitation with HTTP headers. The only exception is
with MHTML, but that affects the body content and not necessarily the headers.
19.4.7 MHTML and Line Length Limitations
HTTP implementations which share code with MHTML [45] implementations need to
be aware of MIME line length limitations. Since HTTP does not have this
limitation, HTTP does not fold long lines. MHTML messages being transported by
HTTP follow all conventions of MHTML, including line length limitations and
folding, canonicalization, etc., since HTTP transports all message-bodies as
payload (see section 3.7.2) and does not interpret the content or any MIME
header lines that might be contained therein.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org