[
https://issues.apache.org/jira/browse/SLING-12697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Liechti updated SLING-12697:
---------------------------------
Description:
For some edge cases, where a response was committed already (i.e. due to
sendRedirect or send Error), misleading information is provided for content
type header change violations (see SLING-12478).
When reading [the servlet api
spec|https://download.oracle.com/otndocs/jcp/servlet-3_1-fr-eval-spec/index.html],
we can see that in 5.4 Convenience Methods, where we talk about
{{sendRedirect}} and {{{}sendError{}}}:
{noformat}
These methods will have the side effect of committing the response, if it has
not already been committed, and terminating it. No further output to the client
should be made by the servlet after these methods are called. If data is
written to the response after these methods are called, the data is
ignored.{noformat}
Right now, changes to content type header are ignored by the response
implementation and comply the servlet api. However, when it comes to detection
of a potential violation, a false positive is created. The log message shows a
violation, even when the content type header is not changed afterwards.
was:
For some edge cases, where a response was committed already (i.e. due to
sendRedirect or send Error), misleading information is provided for content
type header change violations (see SLING-12478).
When reading [the servlet api
spec|https://download.oracle.com/otndocs/jcp/servlet-3_1-fr-eval-spec/index.html],
we can see that in 5.4 Convenience Methods, where we talk about
{{sendRedirect}} and {{{}sendError{}}}:
These methods will have the side effect of committing the response, if it has
not already been committed, and terminating it. No further output to the client
should be made by the servlet after these methods are called. If data is
written to the response after these methods are called, the data is ignored.
Right now, changes to content type header are not ignored, at least when it
comes to detection of a potential violation.
Instead, the change to the content type header must be ignored. To prevent
potential XSS vulnerabilities, changes to the response body must also be
ignored in the same manner. This should be the case already today, but must be
validated through unit testing.
> Potential origins of violations to the RequestDispatcher include API provides
> misleading information on a committed response
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: SLING-12697
> URL: https://issues.apache.org/jira/browse/SLING-12697
> Project: Sling
> Issue Type: Improvement
> Components: Engine
> Reporter: Remo Liechti
> Assignee: Remo Liechti
> Priority: Minor
>
> For some edge cases, where a response was committed already (i.e. due to
> sendRedirect or send Error), misleading information is provided for content
> type header change violations (see SLING-12478).
> When reading [the servlet api
> spec|https://download.oracle.com/otndocs/jcp/servlet-3_1-fr-eval-spec/index.html],
> we can see that in 5.4 Convenience Methods, where we talk about
> {{sendRedirect}} and {{{}sendError{}}}:
> {noformat}
> These methods will have the side effect of committing the response, if it has
> not already been committed, and terminating it. No further output to the
> client should be made by the servlet after these methods are called. If data
> is written to the response after these methods are called, the data is
> ignored.{noformat}
> Right now, changes to content type header are ignored by the response
> implementation and comply the servlet api. However, when it comes to
> detection of a potential violation, a false positive is created. The log
> message shows a violation, even when the content type header is not changed
> afterwards.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
