On 08/02/17 23:42, Greg Wilkins wrote:
> 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.
Somewhere between me opening SERVLET_SPEC-88 and Ed asking for feedback
yesterday I misremembered my original thinking on this issue. Sorry.
My original position was aligned with Greg's. The component generating
the error page should take care of any necessary escaping / encoding
since it knows what format is being used whereas the caller of sendError
probably does not.
Taking Ed's improved text and adapting it gives:
* The caller is not responsible for escaping or re-encoding the
* message to ensure it is safe with respect to the current
* response encoding and content type. That is the responsibility
* of the component generating the error page.
Possibly re-word that last bit as "of the container as the generator of
the error page."
Mark
>
>
> regards
>
>
>
> On 9 February 2017 at 09:58, Edward Burns <edward.burns_at_oracle.com
> <mailto: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 <mailto: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 <mailto:edward.burns_at_oracle.com> | office:
> +1 407 458 0017 <tel:%2B1%20407%20458%200017>
> | 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_at_webtide.com <mailto:gregw_at_webtide.com>> CTO
> http://webtide.com