On 5 July 2013 05:56, Brad Fitzpatrick <bradfitz@golang.org> wrote: > Last time I sent a ...
10 years, 9 months ago
(2013-07-04 23:47:28 UTC)
#3
On 5 July 2013 05:56, Brad Fitzpatrick <bradfitz@golang.org> wrote:
> Last time I sent a patch for this, rsc rejected it.
I assume https://codereview.appspot.com/4519063/ is what you mean.
I've read through it, and disagree with Russ. Also, notice at that
time (over two years ago) this code did not escape \r, \n, < or >, and
those have been subsequently added for security reasons; the same
reasoning applies to U+2028 and U+2029.
I don't buy the argument about sticking strictly to the JSON spec for
two main reasons: (1) security (we escape < and > even though the spec
doesn't require it), (2) precedence (we have gone beyond specs in a
number of places for lesser reasons, e.g. Content-Type sniffing in
net/http). Note in particular that the spec does not *forbid*
escaping; we are still producing valid JSON.
I will also note that Google's internal JSON encoders also escape
U+2028 and U+2029.
I agree with you. On Jul 4, 2013 4:47 PM, "David Symonds" <dsymonds@golang.org> wrote: > ...
10 years, 9 months ago
(2013-07-04 23:50:10 UTC)
#4
I agree with you.
On Jul 4, 2013 4:47 PM, "David Symonds" <dsymonds@golang.org> wrote:
> On 5 July 2013 05:56, Brad Fitzpatrick <bradfitz@golang.org> wrote:
>
> > Last time I sent a patch for this, rsc rejected it.
>
> I assume https://codereview.appspot.com/4519063/ is what you mean.
>
> I've read through it, and disagree with Russ. Also, notice at that
> time (over two years ago) this code did not escape \r, \n, < or >, and
> those have been subsequently added for security reasons; the same
> reasoning applies to U+2028 and U+2029.
>
> I don't buy the argument about sticking strictly to the JSON spec for
> two main reasons: (1) security (we escape < and > even though the spec
> doesn't require it), (2) precedence (we have gone beyond specs in a
> number of places for lesser reasons, e.g. Content-Type sniffing in
> net/http). Note in particular that the spec does not *forbid*
> escaping; we are still producing valid JSON.
>
> I will also note that Google's internal JSON encoders also escape
> U+2028 and U+2029.
>
The input to this is not HTML, nor is the output, nor is the output ...
10 years, 9 months ago
(2013-07-09 00:08:33 UTC)
#9
The input to this is not HTML, nor is the output, nor is the output
necessarily inserted into HTML (e.g. this is a security hole if you
are passing it straight to a JS interpreter). It does not make sense
to put it in HTMLEscape because people won't know or remember to use
that and they won't even realise they have a problem until someone
exploits this hole to do an XSS attack. This is the same reason that
this function escapes < and >; not because they are strictly
necessary, but because it makes it safer.
Arguably, yes, HTMLEscape should not exist. Unfortunately that ship
has sailed. We can still make this code safer and with almost no
overhead.
OK but this CL is incomplete. HTMLEscape and func compact should both do the conversion ...
10 years, 9 months ago
(2013-07-12 02:11:18 UTC)
#11
OK but this CL is incomplete.
HTMLEscape and func compact should both do the conversion too.
HTMLEscape should do the conversion too. HTMLEscape is explicitly for converting
JSON to be safe to use in <script> tags, so JavaScript.
func compact should do this too. compact is called on the result of a
MarshalJSON method to check for validity and compact the JSON. It also rewrites
< > &, so it should rewrite U+2028, U+2029 too.
https://codereview.appspot.com/10883045/diff/14001/src/pkg/encoding/json/enco...
File src/pkg/encoding/json/encode.go (right):
https://codereview.appspot.com/10883045/diff/14001/src/pkg/encoding/json/enco...
src/pkg/encoding/json/encode.go:564: start = i + size
Please make this
i += size
start = i
continue
to match the other "handled" code above.
On 12 July 2013 12:11, <rsc@golang.org> wrote: > func compact should do this too. compact ...
10 years, 9 months ago
(2013-07-12 04:03:26 UTC)
#13
On 12 July 2013 12:11, <rsc@golang.org> wrote:
> func compact should do this too. compact is called on the result of a
> MarshalJSON method to check for validity and compact the JSON. It also
> rewrites < > &, so it should rewrite U+2028, U+2029 too.
Actually this was simpler. U+2028 and U+2029 are effectively space
(they are overly fancy \n), so I can just add them to func isSpace and
compact will strip them out entirely.
On 12 July 2013 14:09, <rsc@golang.org> wrote: > I don't see any change to isSpace, ...
10 years, 9 months ago
(2013-07-12 04:10:02 UTC)
#15
On 12 July 2013 14:09, <rsc@golang.org> wrote:
> I don't see any change to isSpace, which is good.
> U+2028 or U+2029 outside quoted strings (where isSpace is used) is
> invalid and should be rejected. It's the ones inside quoted strings we
> want to convert, and those don't use isSpace.
Yeah, just realised my mistake and thought I'd be able to upload a fix
before you looked at this again. ;-)
Stand by...
LGTM https://codereview.appspot.com/10883045/diff/32001/src/pkg/encoding/json/encode.go File src/pkg/encoding/json/encode.go (right): https://codereview.appspot.com/10883045/diff/32001/src/pkg/encoding/json/encode.go#newcode160 src/pkg/encoding/json/encode.go:160: // so just scan the string one rune ...
10 years, 9 months ago
(2013-07-12 04:31:35 UTC)
#17
Issue 10883045: code review 10883045: encoding/json: escape U+2028 and U+2029.
(Closed)
Created 10 years, 9 months ago by dsymonds
Modified 10 years, 9 months ago
Reviewers:
Base URL:
Comments: 11