Loading ...
Sorry, an error occurred while loading the content.

Re: org.json.java

Expand Messages
  • Douglas Crockford
    ... The RFC says: All Unicode characters may be placed within the quotation marks except for the characters that must be escaped: quotation mark, reverse
    Message 1 of 7 , Jul 2, 2008
    • 0 Attachment
      --- In json@yahoogroups.com, "Tyler Close" <tyler.close@...> wrote:
      >
      > json2.js and JSONObject.java use different definitions of
      > "control-character". json.org seems to leave the term undefined.
      > What's the real answer and why isn't it written on the json.org
      > homepage?

      The RFC says: All Unicode characters may be placed within the
      quotation marks except for the characters that must be escaped:
      quotation mark, reverse solidus, and the control characters (U+0000
      through U+001F).

      It turns out that some implementations of JavaScript's eval function
      delete some characters before evaluation. (I hope to correct this in
      the next edition of the ECMAScript Standard.)
    • Tyler Close
      ... In the meantime, does the json2.js definition of control character cover all the potentially dangerous characters? Shouldn t all JSON emitters be escaping
      Message 2 of 7 , Jul 2, 2008
      • 0 Attachment
        On Wed, Jul 2, 2008 at 9:08 AM, Douglas Crockford <douglas@...> wrote:
        > It turns out that some implementations of JavaScript's eval function
        > delete some characters before evaluation. (I hope to correct this in
        > the next edition of the ECMAScript Standard.)

        In the meantime, does the json2.js definition of control character
        cover all the potentially dangerous characters? Shouldn't all JSON
        emitters be escaping these characters, since the output might be
        consumed by a Javascript eval() function. Since following the RFC
        currently results in potentially unsafe JSON output, putting the
        control character definition on the json.org homepage seems wise.

        I wonder how many different definitions of control character are used
        in the collection of implementations at the bottom of the JSON.org
        homepage.

        --Tyler
      • Douglas Crockford
        ... Yes. ... So far this hasn t appeared to be a problem. I haven t seen applications flinging around a lot of the Cf characters that get deleted by Firefox
        Message 3 of 7 , Jul 3, 2008
        • 0 Attachment
          --- In json@yahoogroups.com, "Tyler Close" <tyler.close@...> wrote:
          >
          > On Wed, Jul 2, 2008 at 9:08 AM, Douglas Crockford <douglas@...> wrote:
          > > It turns out that some implementations of JavaScript's eval function
          > > delete some characters before evaluation. (I hope to correct this in
          > > the next edition of the ECMAScript Standard.)
          >
          > In the meantime, does the json2.js definition of control character
          > cover all the potentially dangerous characters?

          Yes.

          > Shouldn't all JSON
          > emitters be escaping these characters, since the output might be
          > consumed by a JavaScript eval() function. Since following the RFC
          > currently results in potentially unsafe JSON output, putting the
          > control character definition on the json.org homepage seems wise.
          >
          > I wonder how many different definitions of control character are used
          > in the collection of implementations at the bottom of the JSON.org
          > homepage.

          So far this hasn't appeared to be a problem. I haven't seen
          applications flinging around a lot of the Cf characters that get
          deleted by Firefox before eval.

          For applications that need Cf characters in strings that don't want to
          have to escape them, a non-eval parser should be used, such as
          http://www.json.org/json_parse.js or
          http://www.json.org/json_parse_state.js.
        • Tyler Close
          ... I d be more worried about web apps that accept user input and so could be made to traffic in Cf characters without having thought about it. A tricky user
          Message 4 of 7 , Jul 3, 2008
          • 0 Attachment
            On Thu, Jul 3, 2008 at 8:31 AM, Douglas Crockford <douglas@...> wrote:
            > So far this hasn't appeared to be a problem. I haven't seen
            > applications flinging around a lot of the Cf characters that get
            > deleted by Firefox before eval.

            I'd be more worried about web apps that accept user input and so could
            be made to traffic in Cf characters without having thought about it. A
            tricky user might then be able to exploit the fact that strings
            silently change value when being passed back and forth by the
            application.

            --Tyler
          • Douglas Crockford
            ... That is a serious problem when using a naked eval. So json.js contains this step: text = text.replace(cx, function (a) { return u + ( 0000 +
            Message 5 of 7 , Jul 3, 2008
            • 0 Attachment
              --- In json@yahoogroups.com, "Tyler Close" <tyler.close@...> wrote:
              >
              > On Thu, Jul 3, 2008 at 8:31 AM, Douglas Crockford <douglas@...> wrote:
              > > So far this hasn't appeared to be a problem. I haven't seen
              > > applications flinging around a lot of the Cf characters that get
              > > deleted by Firefox before eval.
              >
              > I'd be more worried about web apps that accept user input and so could
              > be made to traffic in Cf characters without having thought about it. A
              > tricky user might then be able to exploit the fact that strings
              > silently change value when being passed back and forth by the
              > application.

              That is a serious problem when using a naked eval. So json.js contains
              this step:

              text = text.replace(cx, function (a) {
              return '\\u' + ('0000' +
              (+(a.charCodeAt(0))).toString(16)).slice(-4);
              });

              It converts the flimsy characters to escape sequences before eval so
              that they are preserved.
            Your message has been successfully submitted and would be delivered to recipients shortly.