OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Security Coordinator (securityaptusventures.com)
Date: Thu May 09 2002 - 10:31:26 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    On Tuesday 07 May 2002 12:36, Mike Messmore wrote:

    > Here is my web security mantra:
    > I am the web developer and I accept responsibility for the information
    > that I am putting on the internet/intranet. If I don't trust it, I
    > don't serve it.
    >
    OK Mike, but you know what? A lot of us get paid big bucks to move data
    around and present it. I build private equity trading networks and we have
    content from all over the place going hither and thither and yon. There's no
    way you can know where it all comes from or review it all. I have live feeds
    of syndicated financial data for instance. You want to tell me how to insure
    that data doesn't contain unwanted content? Its not even cost-effective for
    us to get together with a lot of these sources of data and review where they
    get it it how they filter it, if they even do! We just have to filter it
    ourselves as much as we can and throw it at our users, many of whom are doing
    extremely sensitve things in their browsers... I guarantee you that a switch
    like this would make us breathe a LOT easier!

    > --Mike Messmore
    >
    > On Tue, 2002-05-07 at 05:04, Lincoln Yeoh wrote:
    > > At 01:28 PM 5/6/02 -0500, Mike Messmore wrote:
    > > >Right now the w3c is trying to remove logic and layout from (X)HTML as
    > > >much as possible. It is a language for content. I don't see how logic
    > > >such as this is an elegant solution to the problem at all. It looks to
    > >
    > > It seems to me that the tag is for content.
    > >
    > > >me like yet another ugly hacked on extension to the HTML standard. Not
    > > >to mention the fact that even if it got accepted today you're looking at
    > > >5 years before enough people have a browser that it would make it worth
    > > >even considering using this on a site as some sort of a security
    > > >measure.
    > >
    > > It is indeed ugly. But the current situation is uglier. If you have a
    > > prettier solution, do let us know. Relying on parsers and filters to work
    > > doesn't look prettier to me.
    > >
    > > This tag proposal is indeed for the future. If we don't start now, five
    > > years from now I'm willing to bet so many more OTHER features would have
    > > been added that would make security even harder to maintain. People are
    > > creating more and more ways to turn things ON, I figure creating a space
    > > for OFF switches or even just debate would be useful.
    > >
    > > Acceptance concerns haven't stopped people from introducing new features
    > > and or even breaking websites for browsers that don't support them.
    > >
    > > I believe layering on more security is helpful, esp in this case the
    > > added cost seems minimal. Web app authors should continue to filter
    > > content, but this helps substantially increase security for those using
    > > web browsers that support the tag. A safety net.
    > >
    > > >Rather than making an obscure demand that will never be met or
    > > >supported, ask yourself this: Why are you allowing HTML from untrusted
    > > >users? Is there a better solution? If you trust the users, then HTML
    > > >is fine. Otherwise, you need to look somewhere else.
    > >
    > > Because users want HTML, not just plain text with some bold/underline
    > > stuff?
    > >
    > > As most of the browser security problems have been due to active content,
    > > not nonactive HTML, and most users are happy with just the latter, it
    > > seems that it is a decent compromise to have users receive HTML without
    > > active content.
    > >
    > > Which is likely to be safer - a browser viewing parsed and filtered
    > > hostile content, or a browser supporting the noactive tag viewing
    > > filtered hostile content marked noactive?
    > >
    > > My view is even if the noactive supporting browser parses the content
    > > differently from my filtering parser, the noactive tag will help make it
    > > very likely that the active content modules are turned off and thus
    > > reduce the risk substantially, even if one or both of the parsers have a
    > > bug.
    > >
    > > Here's one of many possible web app scenarios:
    > >
    > > Site A displays content licensed from Site B.
    > >
    > > Users trust Site A, but have not established any relationship with Site
    > > B.
    > >
    > > The tag will allow Site A to use active content on its site and help
    > > ensure that any active content that somehow slips in from Site B would be
    > > turned off.
    > >
    > > Regards,
    > > Link.