[
https://issues.apache.org/jira/browse/TEXT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15792988#comment-15792988
]
Rob Tompkins commented on TEXT-52:
----------------------------------
Sebb's comment in TEXT-42 states:
I guess the question is: would using hex-encoding for all but alphanumeric
characters break any scripts?
If not, then the changing the encoding might help prevent some XSS attacks.
However it won't solve everything, as the quoted URL points out - there are
some contexts where it is not possible to safely quote external input.
The application doing the checks must take ultimate responsibilty for ensuring
that it uses the appropriate methods in the various different contexts. If it
uses an inappropriate method, that is not really a problem for LANG.
However it is important that the LANG Javadoc is clear on what each escape
method does, so the application designer can choose the appropriate method.
The downside of changing the encoding is that the generated output is longer
and harder to read.
Also it may be overkill for some purposes.
Maybe there should be a stricter version of the escape method that does
hex-encoding?
Alternatively, the Javadoc could point users to the ESAPI library if they
require more than just backslash escaping.
> [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScrip better
> javadoc
> -------------------------------------------------------------------------------
>
> Key: TEXT-52
> URL: https://issues.apache.org/jira/browse/TEXT-52
> Project: Commons Text
> Issue Type: Bug
> Reporter: Rob Tompkins
>
> Clarify the javadoc for this method to explain more precisely the limitations
> of the method in terms of string escaping such that folks realize that there
> could be a vulnerability. See TEXT-42 for more specifics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
