Zhijie Shen commented on YARN-2528:

[~jeagles], no problem.  I compared our CrossOriginFilter with the one in 
Jetty. That one seems not to do any post-process for the string obtained from 
ORIGIN header. What's the reason that we need for our CrossOriginFilter? 
According to test case, you want to avoid the issue that the string contains 
the other header, don't you? HttpServletResponse.getHeader doesn't handle 
header splitting properly?

BTW, it seems that ours' only allows one origin in the request header, but 
Jetty's allows multiple one. And I find a specification: 
http://tools.ietf.org/html/draft-abarth-origin-09, which tells that ORIGIN can 
be a list. Any thought?

> Cross Origin Filter Http response split vulnerability protection rejects 
> valid origins
> --------------------------------------------------------------------------------------
>                 Key: YARN-2528
>                 URL: https://issues.apache.org/jira/browse/YARN-2528
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Jonathan Eagles
>            Assignee: Jonathan Eagles
>         Attachments: YARN-2528-v1.patch
> URLEncoding is too strong of a protection for HTTP Response Split 
> Vulnerability protection and major browser reject the encoded Origin. An 
> adequate protection is simply to remove all CRs LFs as in the case of PHP's 
> header function.

This message was sent by Atlassian JIRA

Reply via email to