[ 
https://issues.apache.org/jira/browse/TS-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003215#comment-15003215
 ] 

ASF GitHub Bot commented on TS-4019:
------------------------------------

Github user bryancall commented on a diff in the pull request:

    https://github.com/apache/trafficserver/pull/334#discussion_r44732404
  
    --- Diff: proxy/http2/HTTP2.cc ---
    @@ -448,7 +448,7 @@ convert_from_2_to_1_1_header(HTTPHdr *headers)
     
         // Combine Cookie headers ([RFC 7540] 8.1.2.5.)
         field = headers->field_find(MIME_FIELD_COOKIE, MIME_LEN_COOKIE);
    -    if (field) {
    +    if (field && field->value_validate()) {
    --- End diff --
    
    This shouldn't be necessary since you are going to check all the header 
below. You would be validating the cookies two times.


> Headers passed via HTTP/2 should be validated before passing to FetchSM
> -----------------------------------------------------------------------
>
>                 Key: TS-4019
>                 URL: https://issues.apache.org/jira/browse/TS-4019
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: HTTP/2
>            Reporter: Masakazu Kitajo
>             Fix For: 6.1.0
>
>
> HTTP/2 header fields which contain invalid characters must not be passed to 
> an origin server via HTTP/1.1, and it must be treated as a protocol error.
> {quote}
> 10.3.  Intermediary Encapsulation Attacks
>    The HTTP/2 header field encoding allows the expression of names that
>    are not valid field names in the Internet Message Syntax used by
>    HTTP/1.1.  Requests or responses containing invalid header field
>    names MUST be treated as malformed (Section 8.1.2.6).  An
>    intermediary therefore cannot translate an HTTP/2 request or response
>    containing an invalid field name into an HTTP/1.1 message.
>    Similarly, HTTP/2 allows header field values that are not valid.
>    While most of the values that can be encoded will not alter header
>    field parsing, carriage return (CR, ASCII 0xd), line feed (LF, ASCII
>    0xa), and the zero character (NUL, ASCII 0x0) might be exploited by
>    an attacker if they are translated verbatim.  Any request or response
>    that contains a character not permitted in a header field value MUST
>    be treated as malformed (Section 8.1.2.6).  Valid characters are
>    defined by the "field-content" ABNF rule in Section 3.2 of \[RFC7230\].
> {quote}
> https://tools.ietf.org/html/rfc7540#section-10.3



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to