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

YUI security

Expand Messages
  • christian.storm
    Does anyone know if anything is being done about the YUI! security vulnerability described in http://www.fortifysoftware.com/advisory.jsp? A link to this
    Message 1 of 5 , Apr 3, 2007
    • 0 Attachment
      Does anyone know if anything is being done about the YUI! security
      vulnerability described in http://www.fortifysoftware.com/advisory.jsp?

      A link to this article was just posted on a Dr. Dobbs Security update.
    • tssha
      ... To be clear, this is not a YUI-specific security vulnerability. These issues are endemic to Web development in general. We recommend having a look at the
      Message 2 of 5 , Apr 3, 2007
      • 0 Attachment
        --- In ydn-javascript@yahoogroups.com, "christian.storm"
        <christian.storm@...> wrote:
        >
        > Does anyone know if anything is being done about the YUI! security
        > vulnerability described in http://www.fortifysoftware.com/advisory.jsp?
        >
        > A link to this article was just posted on a Dr. Dobbs Security update.

        To be clear, this is not a YUI-specific security vulnerability. These
        issues are endemic to Web development in general. We recommend having
        a look at the following security practices at
        http://developer.yahoo.com/security/ and apply them to your own
        development.

        I will be drafting some new implementation examples on how to apply
        user-specific signatures when making transactions with Connection
        Manager, based on the YDN security recommendations.

        Regards,
        Thomas
      • Frederic Jean
        Hi Christian, I spend a good part of the morning going over the (sensationalized) articles around the issues as well as other documentation. The problems
        Message 3 of 5 , Apr 3, 2007
        • 0 Attachment
          Hi Christian,

          I spend a good part of the morning going over the (sensationalized)
          articles around the issues as well as other documentation. The problems
          described there are not unique to YUI or AJAX. These have been present
          ever since someone figured out how to get data through JavaScript... I
          have found
          http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications
          to be a good background on this issue (yes, it's focussed on the GWT. It
          doesn't suffer from the need to grab attention that is afflicting the
          Fortify docs.).

          On a YUI specific note, there are a couple things you can do:

          * Continue using your authentication and authorization framework.
          That will help make it difficult to get the data.
          * Add a header to each request using the
          YAHOO.util.Connect.initHeader() method. We have it setup to send a
          specific header with each request since this morning (in dev). Our
          server side code looks for the header and refuses to service the
          request if it is absent or not valid.

          Although I am glad that Fortify did raise the issue, I wish that they
          would have taken a less journalistic approach. The Google document
          provides some good information about the problem and suggest some
          solutions that go beyond GWT users.

          Hope this helps.

          Fred
          http://blog.fredjean.net

          christian.storm wrote:
          >
          > Does anyone know if anything is being done about the YUI! security
          > vulnerability described in
          > http://www.fortifysoftware.com/advisory.jsp?
          > <http://www.fortifysoftware.com/advisory.jsp?>
          >
          > A link to this article was just posted on a Dr. Dobbs Security update.
          >
          >
        • Nick Fitzsimons
          ... ... Strongly agree that this is very much a case of a company with good PR and nothing much to say, rather than a shock exposé of something we
          Message 4 of 5 , Apr 4, 2007
          • 0 Attachment
            On 4 Apr 2007, at 02:16:00, Frederic Jean wrote:

            > I spend a good part of the morning going over the (sensationalized)
            > articles around the issues as well as other documentation. The
            > problems
            > described there are not unique to YUI or AJAX. These have been present
            > ever since someone figured out how to get data through JavaScript...
            <snip>
            > It doesn't suffer from the need to grab attention that is
            > afflicting the
            > Fortify docs.

            Strongly agree that this is very much a case of a company with good
            PR and nothing much to say, rather than a shock exposé of something
            we hadn't all known for ages.

            > * Add a header to each request using the
            > YAHOO.util.Connect.initHeader() method. We have it setup to
            > send a
            > specific header with each request since this morning (in
            > dev). Our
            > server side code looks for the header and refuses to service the
            > request if it is absent or not valid.

            Surely this solution is susceptible to the problem of misconfigured
            proxies which make such things as transcoding based on content
            negotiation and the Accept: header so unreliable? If a badly-
            configured machine somewhere between me and the application fails to
            pass on, or mangles, the header (and custom headers are the most
            likely to suffer this fate), then your application will give the
            impression of having broken at my end. Doesn't look good, and from a
            discussion about HTTP that I hosted at BarCampLondon last year, it
            sounds like such problems are fairly common throughout the web :-(

            Regards,

            Nick.
            --
            Nick Fitzsimons
            http://www.nickfitz.co.uk/
          • Frederic Jean
            Nick, Thank you for reminding me that we don t all live in a world where the firewalls and proxies are well configured... It s quite likely that our customers
            Message 5 of 5 , Apr 4, 2007
            • 0 Attachment
              Nick,

              Thank you for reminding me that we don't all live in a world where the
              firewalls and proxies are well configured... It's quite likely that our
              customers might be stuck in such a world though. I'll have to think
              about it a bit. I guess that I could pass the token as a request parameter.

              Joe Walker posted a good writeup today. It's available at
              http://getahead.org/blog/joe/2007/04/04/how_to_protect_a_json_or_javascript_service.html
              . Joe is the author of the DWR framework and has been posting about
              these risks for a few weeks now.

              Fred

              Nick Fitzsimons wrote:
              >
              > On 4 Apr 2007, at 02:16:00, Frederic Jean wrote:
              >
              > > I spend a good part of the morning going over the (sensationalized)
              > > articles around the issues as well as other documentation. The
              > > problems
              > > described there are not unique to YUI or AJAX. These have been present
              > > ever since someone figured out how to get data through JavaScript...
              > <snip>
              > > It doesn't suffer from the need to grab attention that is
              > > afflicting the
              > > Fortify docs.
              >
              > Strongly agree that this is very much a case of a company with good
              > PR and nothing much to say, rather than a shock exposé of something
              > we hadn't all known for ages.
              >
              > > * Add a header to each request using the
              > > YAHOO.util.Connect.initHeader() method. We have it setup to
              > > send a
              > > specific header with each request since this morning (in
              > > dev). Our
              > > server side code looks for the header and refuses to service the
              > > request if it is absent or not valid.
              >
              > Surely this solution is susceptible to the problem of misconfigured
              > proxies which make such things as transcoding based on content
              > negotiation and the Accept: header so unreliable? If a badly-
              > configured machine somewhere between me and the application fails to
              > pass on, or mangles, the header (and custom headers are the most
              > likely to suffer this fate), then your application will give the
              > impression of having broken at my end. Doesn't look good, and from a
              > discussion about HTTP that I hosted at BarCampLondon last year, it
              > sounds like such problems are fairly common throughout the web :-(
              >
              > Regards,
              >
              > Nick.
              > --
              > Nick Fitzsimons
              > http://www.nickfitz.co.uk/ <http://www.nickfitz.co.uk/>
              >
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.