Script in Feeds, the IE7 Feed View and the Windows RSS Platform


A presentation at Black Hat last week has sparked some discussion in the community. The presentation talks about the potential dangers of script in feeds. I posted on the RSS Team blog regarding the mitigations that are implemented in the IE7 Feed View and the Windows RSS Platform that specifically address potentially malicious scripts in feeds.

We welcome discussions about security and RSS which will ultimately benefit users. Keep the feedback coming!

Walter VonKoch
Program Manager

Comments (19)

  1. Anonymous says:

    If it is just JavaScript (e.g. ECMAScript), then I could care less.  However if it is VBScript, or ActiveX?.. I will be disabling it instantly.

    That said, I don’t know what one would *need* script in Feeds for.

  2. Anonymous says:

    "If it is just JavaScript (e.g. ECMAScript), then I could care less.  However if it is VBScript, or ActiveX?.. I will be disabling it instantly."

    I hate to disappoint you but JavaScript (ECMAScript) can do anything in IE at any particular security level that VBScript can do. One scripting language is not "more secure" than the other.

    In fact, most of the recent vulnerabilities have been exploited using JavaScript syntax, however I’m sure most of them could have also been exploited using VBScript syntax.

    And ActiveX is not a scripting language. If an ActiveX component were insecure, and could be maliciously scripted from a feed, then the malicious activities it could perform could be scripted using either JavaScript or VBScript syntax.

  3. Anonymous says:

    Does Outlook 2007 use the same platform? It seems to be able to view feeds with DTD’s, but not IE7. Any plans to change that?

  4. rss says:

    Outlook 2007 doesn’t use the same platform (except to synchronize feed lists).

    IE7 won’t support for feeds with DTDs (that is unlikely to change).

    Sean Lyndersay [MS]

  5. PatriotB says:

    "Outlook 2007 doesn’t use the same platform"

    That’s unfortunate.  Very unfortunate.

    But I suppose the Office folks don’t want to require their customers to have IE7 installed, in order to use RSS at all.

  6. Anonymous says:

    Scripts in feeds would be a very, very bad idea. An RSS feed is just a list of links, to say it boldly. It is made for machines to read, not for humans to read (humans need only to read a parsed result). Machines need _no_ behaviour on the pages, so scripts are unnecessary. If one would like to script in his/her RSS feed, it should be included in an XSL stylesheet.

  7. Anonymous says:

    Agree with Dirk. I can’t think of a non-abusive use of script in RSS feeds. Don’t process it.

  8. Anonymous says:

    If you folks would read the blog, you’d see that they don’t process script for feeds, period.

  9. Anonymous says:

    Follow all of the standards and don’t diverge with proprietary features. If something kicks enough ass suggest it for newer standards.

    One of the best parts of application/xhtml+xml is that in Gecko browsers it breaks the page 99.9% of the time there is an error. It either is coded correctly or it isn’t. Those who create webpages should be no less susceptible to pages not rendering as programmers and their programs not running because of a misplaced semi-colon for example. IE needs to be 200% less forgiving of 12 year olds who have downloaded Dreamweaver.

  10. Anonymous says:

    Actualy I am not to convinced of the need for HTML in feeds. Especialy where the text is just a summary of the page.

  11. Anonymous says:

    RSS is just a distribution mechanism, it is legal that any kind of content is passed along. However, for traditional RSS viewers content other than a static HTML subset does not make sense.

    Even static HTML could be abused, what do you do with <body> or meta refresh tags? The RSS reader should support only a small, well defined HTML subset, and all kind of active content shall be removed/blocked. Take a look what happened to Ebay when they permitted a "safe" subset of javascript in their article description. It’s simply not doable.

    Other people will build RSS Viewers based on our RSS API and displaying content through IE, so it would be sooo nice to have a ReducetoFeedHTML() function in the RSS API for that kind of application.

  12. Anonymous says:

    What is your opinion about sites creating a fake information bar? Should IE prohibbit this behaviour? Users might think it originates from IE.

    example: http://www.chinesepod.com/

  13. Anonymous says:

    qqq: I can’t think of a way anyone would prevent a spoof like that, aside maybe changing IE’s warning to show up elsewhere outside the document area.

  14. Anonymous says:

    > qqq: I can’t think of a way anyone would prevent a spoof like that, aside maybe changing IE’s warning to show up elsewhere outside the document area.

    Such as above the tab bar, but below the address bar?

  15. Anonymous says:

    Quote:

    IE needs to be 200% less forgiving of 12 year olds who have downloaded Dreamweaver.

    Answer:

    All application software, especially user agents such as Internet Explorer or FireFox, are designed to address the end user’s needs.  Period.

    An XML document can be invalid for a huge number of reasons, including various internet sites being down.  As an XHTML document can contain any XML data in addition to XHTML data, it can also be invalid.  As it can include (via XInclude) potentially malformed documents outside of the authors control, no, it is not appropriate to require XHTML to be well-formed nor valid before it is rendered.

    It is absolutely appropriate to fall back on the HTML 4.01 or HTML 5 parser when XHTML is not well formed.  It is never appropriate for a user agent to enforce validity.  It may choose to render the contents of invalid elements as text, however I would anticipate most user agents normalizing the DOM in phases.

    What I mean by this is (X)HTML arrives on a stream, and is put through a filter to build the DOM.  Once the DOM is built, it is analyzed for "this element is inside that element."  If a TR element is inside a TABLE element, then a new TBODY element is added, and the errant TR element is moved inside that TBODY.  It doesn’t matter if they are HTML or XHTML.

    The user does not care about the standard to which the content is written, and does not know the standard.

    The purpose of a standard is not to be exclusionary, or to prevent end users from accessing content.  The purpose of a standard is to provide a common starting point, so that everyone knows how a doument should be processed.

    When confronted by a document that claims to follow the standard, but does not, a best attempt should be made to process the document anyway.

    For an HTML user agent, such as a web browser, this means if the XHTML parser can’t process the document, then the agent should try the HTML 4.01 parser.  It should notify the user of this (incase they care), but it still should make the best effort that it can to display useful content to the end user.

  16. Anonymous says:

    There is really no reason to filter JavaScript, VBScript, .NET, ActiveX or other content from an RSS feed.  

    Why would you need JavaScript in an RSS feed?

    Main reason I can think of is printing.  Often, I have had to modify elements or CSS rules before printing.

    More to the point…

    An RSS file is an XML file with an XSLT and CSS attached.  As such, it should run with the same (and no higher or lower) permissions as any other XML file with an XSLT and CSS attached from the site that the RSS file resides on.

    if (zone(document).policy.allows.createActiveX())

    { /* do it */ } else { /* don’t */ }

    The rules should be constant, and not dependent on content type.  Either you have sufficient evidence that the document comes from a trusted source, and should be allowed to perform this function, or you don’t.  Content Type should not matter.

  17. Anonymous says:

    Don’t worry about RSS security.

    IE has so many bugs that this is insignificant.

    (10000.0 +- 0.001) ?

    Forget about 0.001  !

  18. betabite says:

    hyperlinked text usealy turn purple after clicked on. in the new ie, when in new tab, those visited hyperlinks do NOT turn purple and this disturbs me. please fix!!

    thanks

    e