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

Re: [caplet] ADsafe and the Standard Globals

Expand Messages
  • Mark S. Miller
    ... Currently, ADsafe is still approximately a subset of Caja. Were these added, it would cause significant breakage of the subset relationship. -- Cheers,
    Message 1 of 15 , Apr 10, 2008
    • 0 Attachment
      On Wed, Apr 9, 2008 at 10:17 PM, Kris Zyp <kris@...> wrote:
      > No confirm, alert, or prompt? Preventing annoyance exploits? ;) Or is there
      > another exploit I am not aware of?

      Currently, ADsafe is still approximately a subset of Caja. Were these
      added, it would cause significant breakage of the subset relationship.

      --
      Cheers,
      --MarkM
    • David-Sarah Hopwood
      ... and timezone ... And Array.prototype.toLocaleString, and String.prototype.localeCompare. Thanks for pointing this out -- it s better to have any ambient
      Message 2 of 15 , Apr 11, 2008
      • 0 Attachment
        Mike Samuel wrote:
        > On 10/04/2008, David-Sarah Hopwood
        > <david.hopwood@...> wrote:
        >> Douglas Crockford wrote:
        >> > They are creatures of the DOM.
        >>
        >> I can see the B-movie poster now :-)
        >>
        >> More seriously, all of the objects that Doug just granted access to,
        >> with the exception of Date, provide no authority -- they only provide
        >> pure deterministic functions, constant values, and the ability to
        >> allocate objects of those types (if you don't count that as pure).
        >> I had come up with exactly the same list for Jacaranda -- except
        >> that I had accidentially missed out encodeURIComponent.
        >>
        >> Date is an exception just because it grants access to what the Javascript
        >> implementation thinks the current date/time

        and timezone

        >> is, which is technically an authority -- but not one that is significant
        >> for ADsafe's threat model.
        >
        > Date also provides info about the user's locale, but so does Number to
        > some degree.

        And Array.prototype.toLocaleString, and String.prototype.localeCompare.
        Thanks for pointing this out -- it's better to have any ambient authority
        that we decide to allow thoroughly documented.

        --
        David-Sarah Hopwood
      • Mark Miller
        On Fri, Apr 11, 2008 at 2:13 PM, David-Sarah Hopwood ... In addition to the violations noted later in this thread, there s also Math.random(). -- Text by me
        Message 3 of 15 , Apr 11, 2008
        • 0 Attachment
          On Fri, Apr 11, 2008 at 2:13 PM, David-Sarah Hopwood
          <david.hopwood@...> wrote:
          > >> More seriously, all of the objects that Doug just granted access to,
          > >> with the exception of Date, provide no authority -- they only provide
          > >> pure deterministic functions, constant values, and the ability to
          > >> allocate objects of those types (if you don't count that as pure).

          In addition to the violations noted later in this thread, there's also
          Math.random().


          --
          Text by me above is hereby placed in the public domain

          Cheers,
          --MarkM
        • Douglas Crockford
          ... It is in the standard and it does not represent a leak. escape is not recommended for encoding URLs, but can be used for encoding values in cookies. Unless
          Message 4 of 15 , Apr 15, 2008
          • 0 Attachment
            --- In caplet@yahoogroups.com, "Mike Samuel" <mikesamuel@...> wrote:
            > > I am relaxing ADsafe to allow access to these standard globals:
            > >
            > > Array Boolean Date decodeURI decodeURIComponent encodeURI
            > > encodeURIComponent Error escape EvalError isFinite isNaN
            > > Math Number Object parseInt parseFloat RangeError
            > > ReferenceError RegExp String SyntaxError TypeError unescape
            > > URIError
            >
            > Is it really worth including {,un}escape in light of
            > http://msdn2.microsoft.com/en-us/library/9yzah1fh(VS.85).aspx ?
            > Is it a goal to support older versions of JS that don't have
            > {de,en}codeURIComponent?

            It is in the standard and it does not represent a leak. escape is not
            recommended for encoding URLs, but can be used for encoding values in
            cookies. Unless there is a stronger argument, I think it should be
            allowed.

            > Is RegExp.$1 is not allowed? If so, it may leak information from the
            > last match performed by privileged code.

            RegExp.$1 is not allowed because $1 is not the name of one of the
            Math/Number constants.

            RegExp['$1'] is not allowed because '$1' does not look like a
            stringified number.

            ADsafe.get(RegExp, '$1') is not allowed because RegExp is a function.
          • Mike Samuel
            ... I have no stronger argument than, in code I review, it is much more frequently misused than used properly. If the goal is to allow all innocuous ES
            Message 5 of 15 , Apr 15, 2008
            • 0 Attachment
              On 15/04/2008, Douglas Crockford <douglas@...> wrote:
              >
              >
              >
              >
              >
              >
              > --- In caplet@yahoogroups.com, "Mike Samuel" <mikesamuel@...> wrote:
              > > > I am relaxing ADsafe to allow access to these standard globals:
              > > >
              > > > Array Boolean Date decodeURI decodeURIComponent encodeURI
              > > > encodeURIComponent Error escape EvalError isFinite isNaN
              > > > Math Number Object parseInt parseFloat RangeError
              > > > ReferenceError RegExp String SyntaxError TypeError unescape
              > > > URIError
              > >
              > > Is it really worth including {,un}escape in light of
              > > http://msdn2.microsoft.com/en-us/library/9yzah1fh(VS.85).aspx ?
              > > Is it a goal to support older versions of JS that don't have
              > > {de,en}codeURIComponent?
              >
              > It is in the standard and it does not represent a leak. escape is not
              > recommended for encoding URLs, but can be used for encoding values in
              > cookies. Unless there is a stronger argument, I think it should be
              > allowed.

              I have no stronger argument than, in code I review, it is much more
              frequently misused than used properly.

              If the goal is to allow all innocuous ES built-ins, then it should be allowed.



              > > Is RegExp.$1 is not allowed? If so, it may leak information from the
              > > last match performed by privileged code.
              >
              > RegExp.$1 is not allowed because $1 is not the name of one of the
              > Math/Number constants.
              >
              > RegExp['$1'] is not allowed because '$1' does not look like a
              > stringified number.
              >
              > ADsafe.get(RegExp, '$1') is not allowed because RegExp is a function.

              Cool.
            • Mark S. Miller
              On Tue, Apr 15, 2008 at 4:42 PM, Douglas Crockford ... I just looked. They are not in the normative part of the ES3 spec. They appear only in Annex B. (B.2.1 &
              Message 6 of 15 , Apr 15, 2008
              • 0 Attachment
                On Tue, Apr 15, 2008 at 4:42 PM, Douglas Crockford
                <douglas@...> wrote:
                > > Is it really worth including {,un}escape in light of
                > > http://msdn2.microsoft.com/en-us/library/9yzah1fh(VS.85).aspx ?
                > > Is it a goal to support older versions of JS that don't have
                > > {de,en}codeURIComponent?
                >
                > It is in the standard [...]

                I just looked. They are not in the normative part of the ES3 spec.
                They appear only in Annex B. (B.2.1 & B.2.2)

                They have never appeared in the Caja whitelist, and probably never
                will. So they are not in any of the normative supersets of ADsafe.

                --
                Cheers,
                --MarkM
              • Douglas Crockford
                ... And they are no longer in ADsafe. JSLint will flag them in all cases.
                Message 7 of 15 , Apr 15, 2008
                • 0 Attachment
                  --- In caplet@yahoogroups.com, "Mark S. Miller" <erights@...> wrote:
                  > I just looked. They are not in the normative part of the ES3 spec.
                  > They appear only in Annex B. (B.2.1 & B.2.2)
                  >
                  > They have never appeared in the Caja whitelist, and probably never
                  > will. So they are not in any of the normative supersets of ADsafe.

                  And they are no longer in ADsafe. JSLint will flag them in all cases.
                Your message has been successfully submitted and would be delivered to recipients shortly.