[
https://issues.apache.org/jira/browse/SLING-12697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Liechti updated SLING-12697:
---------------------------------
Fix Version/s: (was: Engine 2.16.0)
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{}}}:
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.
was:
In case of excessive recursive calls, a huge stack of potential origins is
generated (see SLING-12478).
When using all those messages that sit in the RequestProgressTracker, a lot of
memory is used to generate a log message that actually helps the developer to
find the origin of the XSS violation. This may lead to OOM errors where the
system cannot recover from. This seems to be especially critical for recursive
calls where a servlet calls itself over and over again, building a bug amount
of tracked messages that then later on need to be analyzed. As nobody will go
through such a enormous stack, as well as it may get truncated during logging,
make sure to use the last 500 messages of the RequestProgressTracker in the
analysis of potential origins and put them into the log message instead.
This way, we achieve a log message that can first of all, be logged properly
and is still manageable to read and understood by the developer.
> 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{}}}:
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
