[gwt-contrib] Re: Be stricter about quoting JSON strings in AutoBeans. In particular, (issue1853803)
On 2012/10/13 03:42:46, cromwellian wrote: One option is to have an extra method like encodeForHtmlContext() where you only pay the tax in that circumstance. Would it cost really that much to post-process the output from AutoBeans (possibly depending on context)? For instance, using OWASP ESAPI [1] String json = AutoBeanCodex.encode(bean).getPayload(); string escaped = new DefaultEncoder().encodeForJavaScript(json); [1] http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/reference/DefaultEncoder.html http://gwt-code-reviews.appspot.com/1853803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Be stricter about quoting JSON strings in AutoBeans. In particular, (issue1853803)
I don't think it's a matter of simple character replacement once
something has been serialized to JSON string. For example, these
encoders will typically escape '\' character, but if there are already
legal escape sequences in the string, it will end up double-escaping
the payload leading to incorrect evaluation in JS. e.g. {foo:
\u} comes out of AutoBeanCodec, it will get escaped to {foo:
\\u} which is wrong.
On Sat, Oct 13, 2012 at 2:56 AM, t.bro...@gmail.com wrote:
On 2012/10/13 03:42:46, cromwellian wrote:
One option is to have an extra method like encodeForHtmlContext()
where you only
pay the tax in that circumstance.
Would it cost really that much to post-process the output from AutoBeans
(possibly depending on context)?
For instance, using OWASP ESAPI [1]
String json = AutoBeanCodex.encode(bean).getPayload();
string escaped = new DefaultEncoder().encodeForJavaScript(json);
[1]
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/reference/DefaultEncoder.html
http://gwt-code-reviews.appspot.com/1853803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Be stricter about quoting JSON strings in AutoBeans. In particular, (issue1853803)
On Saturday, October 13, 2012 12:30:24 PM UTC+2, Ray Cromwell wrote:
I don't think it's a matter of simple character replacement once
something has been serialized to JSON string. For example, these
encoders will typically escape '\' character, but if there are already
legal escape sequences in the string, it will end up double-escaping
the payload leading to incorrect evaluation in JS. e.g. {foo:
\u} comes out of AutoBeanCodec, it will get escaped to {foo:
\\u} which is wrong.
If an encoder does that, then it's clearly broken.
If {foo: \u} comes out of AutoBeanCodex, then it should be left as
is in an HTML or script context, and possibly escaped to
{quot;fooquot;: quot;\uquot;} in an HTML attribute context.
Matthew's proposal is basically equivalent to
htmlEscape(AutoBeanCodex.encode(bean).getPayload()) where htmlEscape is
defined as:
public String htmlEscape(String str) { return str.replace(,
\\u003C).replace(, \\u003E).replace(, \\u0026).replace(=,
\\u003D).replace(', \\u0027); }
It only replaces those chars in String literals, but they can only appear
in String literals anyway, so it really is equivalent in the end.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Be stricter about quoting JSON strings in AutoBeans. In particular, (issue1853803)
The context IIRC from internal discussion, is something writing
something like this:
script
var x = 'autoBean result'; //e.g. what you don't want
var x = '{foo: \u0061, don't stop believin'}'
/script
The codec you linked to to me looks like it will change backslash into
\x5c form perusing Codec.java and JavaScriptCodec.java, you can see in
http://owasp-esapi-java.googlecode.com/svn/trunk/src/main/java/org/owasp/esapi/codecs/Codec.java
that 5C is outside of the range that doesn't get encoded.
-Ray
On Sat, Oct 13, 2012 at 4:50 AM, Thomas Broyer t.bro...@gmail.com wrote:
On Saturday, October 13, 2012 12:30:24 PM UTC+2, Ray Cromwell wrote:
I don't think it's a matter of simple character replacement once
something has been serialized to JSON string. For example, these
encoders will typically escape '\' character, but if there are already
legal escape sequences in the string, it will end up double-escaping
the payload leading to incorrect evaluation in JS. e.g. {foo:
\u} comes out of AutoBeanCodec, it will get escaped to {foo:
\\u} which is wrong.
If an encoder does that, then it's clearly broken.
If {foo: \u} comes out of AutoBeanCodex, then it should be left as
is in an HTML or script context, and possibly escaped to {quot;fooquot;:
quot;\uquot;} in an HTML attribute context.
Matthew's proposal is basically equivalent to
htmlEscape(AutoBeanCodex.encode(bean).getPayload()) where htmlEscape is
defined as:
public String htmlEscape(String str) { return str.replace(,
\\u003C).replace(, \\u003E).replace(, \\u0026).replace(=,
\\u003D).replace(', \\u0027); }
It only replaces those chars in String literals, but they can only appear in
String literals anyway, so it really is equivalent in the end.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Be stricter about quoting JSON strings in AutoBeans. In particular, (issue1853803)
Should HTML-specific escaping be done on top of the value produced by
AutoBeans? Do we really want to pay the tax (each one of =' is
replaced by 6 chars!) for each AutoBean-based exchanged over the wire
(for example, RequestFactory uses Base64-encoding for its stableId and
version, which makes use =).
Also, the dangerous HTML chars depend on context: for a script, I
don't think any of those char is dangerous (given than
JSONObject.quote already escapes /, producing a \/script). For
another element (e.g. a span style=display:none), only and are
actual issues. And for attribute values, basically only quotes and are
issues, possibly and though I believe they've only been issues with
really old browsers. Moreover, for all those chars, the HTML escape is
shorter than the JS escape (lt; vs. \u003C, #34; vs \u0022)
The comments below assume the above is refuted somehow.
http://gwt-code-reviews.appspot.com/1853803/diff/1/user/src/com/google/web/bindery/autobean/shared/impl/StringQuoter.java
File
user/src/com/google/web/bindery/autobean/shared/impl/StringQuoter.java
(right):
http://gwt-code-reviews.appspot.com/1853803/diff/1/user/src/com/google/web/bindery/autobean/shared/impl/StringQuoter.java#newcode78
user/src/com/google/web/bindery/autobean/shared/impl/StringQuoter.java:78:
case '/': sb.append(\\/); break;
I don't think / needs escaping anymore if we escape . I guess it
was only escaped to avoid outputing /script that could close an HTML
script, but if is escaped, it'd become \u003C/script where /
doesn't need to also be escaped.
http://gwt-code-reviews.appspot.com/1853803/diff/1/user/src/com/google/web/bindery/autobean/shared/impl/StringQuoter.java#newcode86
user/src/com/google/web/bindery/autobean/shared/impl/StringQuoter.java:86:
if (c ' ' || c = 128 || DANGEROUS_HTML_CHARS.indexOf(c) != -1) {
Performance-wise, wouldn't it be better to add case lines above?
http://gwt-code-reviews.appspot.com/1853803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Be stricter about quoting JSON strings in AutoBeans. In particular, (issue1853803)
One option is to have an extra method like encodeForHtmlContext() where you only pay the tax in that circumstance. http://gwt-code-reviews.appspot.com/1853803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
