Ed,
I'm not really happy with giving an undertaking to include messages without
any escaping or re-encoding. If an attack vector is discovered that relies
on injecting text into an error message, then I think containers will
naturally react by escaping and/or encoding. I don't think the spec
should ban a prime defence mechanism.
More over, the generation of an error page may be beyond the knowledge of
the calling application. HTML is only the default and some servers may be
configured to send XML or JSON encoded error pages. A calling
application cannot know what encoding will result.
The message is passed as a unicode string, so it should be up to the
container how that is encoded, or even if it is encoded. I certainly have
seen configurations where such error messages are not sent to the client.
If the calling application wishes to control the content of the error page,
they are free to call setStatus, setContentType, etc and generate the page
themselves. If they wish to delegate generation of the error page to the
container, then they pass minimal information and how or even if that is
encoded is beyond their control.
regards
On 9 February 2017 at 09:58, Edward Burns <edward.burns_at_oracle.com> wrote:
>
> On 07/02/17 22:34, Edward Burns wrote:
>
> EB> I propose we resolve this by adding this statement to the text of
> EB> HttpServletResponse.sendError(), after "text/html":
>
> EB> The message is assumed to be in the character
> EB> encoding of the current response.
>
> >>>>> On Tue, 7 Feb 2017 23:37:40 +0000, Mark Thomas <markt_at_apache.org>
> said:
>
> MT> That text does not address the primary concern of addressing who is
> MT> responsible for ensuring that the message is safe to use as is.
>
> MT> I'd suggest the following alternative text:
>
> MT> The caller is responsible for ensuring that the provided message is
> safe
> MT> (e.g. user provided data is appropriately escaped) to be included
> MT> 'as-is' in the error response.
>
> I hope you don't mind if I reword your text as
>
> * The argument message will be included in the
> * response without any escaping or re-encoding. The caller is
> * responsible for ensuring this is safe with respect to the current
> * response encoding.
>
> Is that ok?
>
> Thanks,
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | 19 business days until planned start of JSF 2.3 Final Approval Ballot
> | 9 business days until DevNexus 2017
> | 34 business days until JavaLand 2017
>
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com