[jira] [Comment Edited] (LANG-871) [XSS] Possible attacks through StringEscapeUtils.escapeEcmaScript?

["Sebb (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LANG-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13836785#comment-13836785 ] 

Sebb edited comment on LANG-871 at 12/2/13 6:54 PM:
----------------------------------------------------

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.


was (Author: sebb@apache.org):
I guess the question is: would using hex-encoding for all but alphanumeric characters break any scripts?

If not, then the method should 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.escapeEcmaScript?
> ------------------------------------------------------------------
>
>                 Key: LANG-871
>                 URL: https://issues.apache.org/jira/browse/LANG-871
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.*
>    Affects Versions: 3.1
>            Reporter: Andy Reek
>              Labels: XSS
>             Fix For: Discussion
>
>
> org.apache.commons.lang3.StringEscapeUtils.escapeEcmaScript does the escape via a prefixed '\' on all characters which must be escaped. I am not sure if this is really secure, if am looking at the comments on https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.233_-_JavaScript_Escape_Before_Inserting_Untrusted_Data_into_JavaScript_Data_Values. They say it is possible to do an attack by escape the escape. I tested this with the string '\"' and the output was '\\\"'. Is this really ecma-/java-script secure? Or is it better to use the implementation used by OWASP?



--
This message was sent by Atlassian JIRA
(v6.1#6144)