[
https://issues.apache.org/jira/browse/YARN-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128026#comment-14128026
]
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
(v6.3.4#6332)
