Can we get back on topic and discuss the potential issues with RSS instead of the gratuitous MSFT bashing? All MSFT has done is bring this to the front burner.
RSS enclosures can move anything. Corrupt the underlying XML (or the data it is trying to move in the enclosure) and all your victims will pull it onto their desktops automatically. An analog is having HTML email and using a preview pane. You wouldn't do that, but RSS enables it. Got a PDF that exploits an Adobe vulnerability? Add it as an enclosure. Got an image? Same deal. Got a zip? Go ahead. It's not just the currently trendy podcasting and audio files that pose threats.
Worse yet, there are many RSS clients our there, not just a few (unlike browser or email). Many opportunities to find holes. Most clients use IE to render the HTML, so there's also the risk of phishing, embedded script, moveable code and other standard HTML malware. What are the vendors doing to mitigate this? Good question. Anyone from feedburner, say, care to comment?
RSS doesn't stand for Really Scary Security - yet. MSFT just made it a much richer target - let's save the guesswork about the quality of their implementation for when it actually shows up.
I work for a log analysis firm, and the bane of our lives are logs where the information is presented inconsistently from one message to the next. So in some cases a message might have, say, an IP Address as the first word, and in another message its somewhere else in the line with as IP address:port, etc. It's a right royal PITA to write code to extract the IP address in this example if you have to find out every potential message that the app will ever issue in order to automate analysis.
So, in order to make storage, analysis and reporting easy, your framework should attempt to coerce a consistent approach to the data logged - even the plaintext "human readable" data if you can. If you can do the same with metadata about the event (e.g. ID fields, links to online KBs etc), so much the better.
Slashdot Mirror
RSS enclosures can move anything. Corrupt the underlying XML (or the data it is trying to move in the enclosure) and all your victims will pull it onto their desktops automatically. An analog is having HTML email and using a preview pane. You wouldn't do that, but RSS enables it. Got a PDF that exploits an Adobe vulnerability? Add it as an enclosure. Got an image? Same deal. Got a zip? Go ahead. It's not just the currently trendy podcasting and audio files that pose threats. Worse yet, there are many RSS clients our there, not just a few (unlike browser or email). Many opportunities to find holes. Most clients use IE to render the HTML, so there's also the risk of phishing, embedded script, moveable code and other standard HTML malware. What are the vendors doing to mitigate this? Good question. Anyone from feedburner, say, care to comment?
RSS doesn't stand for Really Scary Security - yet. MSFT just made it a much richer target - let's save the guesswork about the quality of their implementation for when it actually shows up.
So, in order to make storage, analysis and reporting easy, your framework should attempt to coerce a consistent approach to the data logged - even the plaintext "human readable" data if you can. If you can do the same with metadata about the event (e.g. ID fields, links to online KBs etc), so much the better.
BB