PaceFormatSecurity
+1. But let's add something to the effect of consumers MAY ignore unrecognized CSS/(X)HTML and any CSS/(X)HTML that they are not confident will not result in security problems.
Re: PaceFormatSecurity
-1. If the current security documents that cover the material are insufficient, they should be fixed, and not have it listed in our document. We should only point to where generic information can be found and list things that are Atom-specific. --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceFormatSecurity
Sam Ruby wrote: It seems to me that we have an obligation to either (1) disallow HTML, or (2) mitigate allowing HTML by providing a security section such as this one. If (2) can be solved by reference, then that clearly would be preferred. But to date, no such reference has been found. So, engaging in bad specification practice[0] is the answer? HTML security is a problem for the W3C and/or an HTML-WG. Existing RFCs constitute the IETF's definition of adequate security coverage for HTML. If we want to change the status quo in our document, we need to say that we're updating those RFCs at the top of our document. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg12625.html
Re: PaceFormatSecurity
-1, agree with Robert. Graham On 7 Feb 2005, at 6:35 pm, Robert Sayre wrote: -1. Covers HTML in too much detail, though it's still inadequate coverage. This is isn't our problem. I blame the W3C :) Robert Sayre
Re: PaceFormatSecurity to be updated?
On Wednesday, February 2, 2005, at 01:31 AM, Robert Sayre wrote: Every Atom Processor should carefully consider their handling of every type of element when processing incoming (X)HTML in Atom documents. ...and might wish to remove all unrecognized elements.
Re: PaceFormatSecurity to be updated?
Joe Gregorio wrote: On Wed, 02 Feb 2005 03:31:18 -0500, Robert Sayre [EMAIL PROTECTED] wrote: 10.1 HTML and XHTML Content Text Constructs and atom:content allow the delivery of HTML and XHTML into a client application. Many elements are considered 'unsafe' in that they open clients to one or more types of attack. Every Atom Processor should carefully consider their handling of every type of element when processing incoming (X)HTML in Atom documents. See the security sections of RFC 2854 and HTML 4.01 for some guidance on many types of attack. As I've stated before, referencing the security sections of these two documents will not be helpful to an implementer. Yes, you've stated that before. Two paragraphs on HTML security is still laughably inadequate, only they're in the wrong document, where they won't receive adequate review. What implementors *would* find helpful is a document covering these subjects authored by experts in HTML layout engines, JavaScript interpreters, and CSS. Anyway, the Paces don't have opposing requirements, and our AD has told us what to write. I'm not sure why we're wasting WG time on this. Robert Sayre
Re: PaceFormatSecurity
* Asbjørn Ulsberg [EMAIL PROTECTED] [2005-01-29 06:05+0100] On Fri, 28 Jan 2005 17:01:06 -0500, Robert Sayre [EMAIL PROTECTED] wrote: I guess the question is whether we can and should outline HTML security issues. I don't think we can or should. Considering the large amount of (X)HTML that are being syndicated via RSS and Atom today and will be in the future, I think we should. (X)HTML will be the main markup used inside all Atom Text Constructs, and while MathML, SVG and other markup languages we don't know about may contain security issues, they aren't nearly as important to mention as those that lie within (X)HTML. As far as SVG goes, I suspect a lot of the issues will be around Javascript, just as in (X)HTML. Dan
PaceFormatSecurity
I looked at format-05 and found that the security section is still
pretty anemic. Here is my stab at fleshing out that section:
http://www.intertwingly.net/wiki/pie/PaceFormatSecurity:
===
== Abstract ==
Fill out the security section of the format spec.
== Status ==
Open
Author: JoeGregorio
Much of the material presented here has been covered by Mark Pilgrim
in his post on consuming RSS Safely:
http://diveintomark.org/archives/2003/06/12/how_to_consume_rss_safely
== Rationale ==
Security is more than just encryption and signatures.
== Proposal ==
Add the following text to 10 Security Considerations
{{{
10.1 HTML and XHTML Text Constructs
Text Constructs allow the delivery of HTML and XHTML into a client application
which may then display that (X)HTML. Because that (X)HTML may be displayed
either in a web browser or via an embedded web browser in a desktop
application, many
security concerns will arise since that (X)HTML may be displayed in a different
context from which it was originally served. A consuming application needs
to be very careful about the context in which that (X)HTML is displayed to avoid
cross site scripting attacks and other forms information leakage.
An aggregator will certainly display the (X)HTML of a Text Construct in a
different context than if an HTML page had been loaded from the same server
as that had served up the Atom feed. That is, the (X)HTML may be displayed
through a different web site if is a web based aggregator, or as a local file
if the aggregator is a desktop kind. There are also aggregators that serve files
up via a web server that run off the desktop. Because of these differening
contexts there is an opening for cross site scripting attacks or other forms of
information leakage.
10.1.1 HTML Elements
The following elements are consider 'unsafe' in that they
open clients to one or more types of attack. Every client should
consider carefully their handling of each of them when processing
incoming (X)HTML in Text Constructs.
10.1.1.1 IMG Element
The image element may pose a threat by inadvertely leaking
information. That is, a
hostile feed may include a Text Construct with a web bug, a 1x1 pixel image
that gets loaded invisibly to the user. The request itself and the
referral information
the client application provides may leak information about who is reading the
content and when the content was read.
10.1.1.2 SCRIPT Element
All SCRIPT elements should be stripped from Text Constructs or all native
scripting support of the (X)HTML display engine should be disabled. Allowing
any script to run would allow cross site scripting attacks.
10.1.1.3 EMBED and OBJECT Elements
All EMBED and OBJECT elements should be stripped from Text Constructs.
The danger here is loading up an an embedded object in an unsafe context.
For example an ActiveX control could be run in local context considered safe
while it would not normally be loaded from it's origin site which was
considered unsafe. ActiveX is not the only technology to suffer from this
problem, SVG allows JavaScript to be embedded in it, and if displayed in an
EMBEB or OBJECT element could open the client up to a cross site scripting
attack.
10.1.1.4 FRAME, FRAMESET, and IFRAME Elements
The FRAME, FRAMESET, and IFRAME Elements allow loading (X)HTML in from a
different context.
10.1.1.5 META Elements
Some (X)HTML processors are very loose in what they will accept for
HTML, including
processing elements that would normally appear in the HEAD of a
document even when
they are present in the BODY. Such a loose (X)HTML processor may
process a META element
which could redirect the HTML processor to load another page.
10.1.1.6 LINK Elements
The same loose processing that may inadvertenly pick up META elements can also
pick up LINK elements which can cause CSS Stylesheets to be loaded. Please see
Section 10.1.2 on the potential problems with CSS.
10.1.2 CSS
The processing of CSS (Cascading Stylesheets) also has security
concers. CSS allows the
loading of images, which has all the same concerns as the IMG element
[Section 10.1.1.1].
In addition CSS allows HTML elements to be hidden or positioned
absolutely. If a group
of syndication feeds are processed and displayed in a single HTML page
then some errant or
malicious CSS could ovelay the entire page with a single large image
repeated endlessly, thus
rendering the entire page unusable. Some browsers also support
proprietary extensions which allow
the execution of scripts within CSS. For these reasons clients should
strongly consider stripping
all STYLE elements from the (X)HTML and also remove all STYLE
Attributes in the (X)HTML
elements themselves.
10.1.3 URIs
Since any consumer of an Atom feed will be processing URIs, the
security concerns
for handling URIs must also be taken into account. See Section 7 of RFC 3986.
10.1.4 IRIs
Since any consumer of an Atom feed will be processing IRIs, the
security
Re: PaceFormatSecurity
I don't like stuff like: All SCRIPT elements should be stripped from Text Constructs or all native scripting support of the (X)HTML display engine should be disabled. I don't think you need to should do any more than outline the threat model from each tech. Proscribing how to deal with it is not on, especially when they're this drastic. Graham smime.p7s Description: S/MIME cryptographic signature
Re: PaceFormatSecurity
Graham wrote: I don't like stuff like: All SCRIPT elements should be stripped from Text Constructs or all native scripting support of the (X)HTML display engine should be disabled. I don't think you need to should do any more than outline the threat model from each tech. Proscribing how to deal with it is not on, especially when they're this drastic. Agree w/ Graham. We don't know what kind of relationship the publisher and consumer have. I would strike all the details on HTML, leave the first paragraph, and refer to the security sections of RFC 2854 and HTML 4.01. Robert Sayre
Re: PaceFormatSecurity
Joe Gregorio wrote: Those two references are woefully inadequate, just compare the threats they outline versus the ones I outline in the Pace. If there were a good reference of all the problems that HTML can cause when used in email, *that* would be more in line with what we need, but I was unable to find such a reference myself. Maybe someone else has better google-fu than me. I guess the question is whether we can and should outline HTML security issues. I don't think we can or should. Robert Sayre
Re: PaceFormatSecurity
At 12:56 PM -0800 1/28/05, Tim Bray wrote: At this point we should appeal to our designated IETF culture/process experts; Scott/Ted/Paul, any guidance? -Tim It's up to the WG. If we do a long list, we will probably be told to make it much longer. If we do security-by-reference, we will probably be told that those references aren't very good, or up to date, or something. Given the two choices, I actually prefer security-by-reference because it points out the similarity of what we are doing to other protocols. Section 10.1.1 might instead read: - Many elements are consider 'unsafe' in that they open clients to one or more types of attack. Every client should consider carefully their handling of every type of element when processing incoming (X)HTML in Text Constructs. See the security sections of RFC 2854 and HTML 4.01 for some guidance on many type of attacks. Atom readers should pay particular attention to the security of the IMG, SCRIPT, EMBED, OBJECT FRAME, FRAMESET, IFRAME, META, LINK elements, but other elements may also have negative security properties. - Then skip the subsections. That gives the reader some guidance, but doesn't lock us into covering everything. --Paul Hoffman, Director --Internet Mail Consortium
RE: PaceFormatSecurity
Given the two choices, I actually prefer security-by-reference because it points out the similarity of what we are doing to other protocols. I agree. It's also a good practice to have only one authoritative source that talks about a topic, especially when that source has already been through the RFC approval process. -Scott-
Re: PaceFormatSecurity
On Fri, 28 Jan 2005 17:01:06 -0500, Robert Sayre [EMAIL PROTECTED] wrote: I guess the question is whether we can and should outline HTML security issues. I don't think we can or should. Considering the large amount of (X)HTML that are being syndicated via RSS and Atom today and will be in the future, I think we should. (X)HTML will be the main markup used inside all Atom Text Constructs, and while MathML, SVG and other markup languages we don't know about may contain security issues, they aren't nearly as important to mention as those that lie within (X)HTML. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceFormatSecurity
On Fri, 28 Jan 2005 13:21:08 -0800, Tim Bray [EMAIL PROTECTED] wrote: Whereas you could technically get by with warning-by-reference, I think that it's OK and fact probably essential to point out that img and script and object and so on; are potentially lethal; I agree. However, it is impossible to write a specification today about security issues we don't know of, but those we do know, like the elements you mention, should also be mentioned in the specification. I thought Joe got about the right level, except for the what to do stuff. Yep. If he leaves that out of the pace, I'm all +1 to it. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceFormatSecurity
On Fri, 28 Jan 2005 17:13:26 -0800, Paul Hoffman [EMAIL PROTECTED] wrote: Many elements are consider 'unsafe' in that they open clients to one or more types of attack. Every client should consider carefully their handling of every type of element when processing incoming (X)HTML in Text Constructs. See the security sections of RFC 2854 and HTML 4.01 for some guidance on many type of attacks. Atom readers should pay particular attention to the security of the IMG, SCRIPT, EMBED, OBJECT FRAME, FRAMESET, IFRAME, META, LINK elements, but other elements may also have negative security properties. This reads well, imo. But I would replace «(X)HTML» with «markup» in the first paragraph, because there may be security issues with other markup languages as well. I would then rewrite the second paragraph like this: Atom readers should pay particular attention to the security of HTML and XHTML's IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META and LINK elements, but other elements may also have negative security properties. I'm having a bit problem with calling EMBED an HTML element, though, since no HTML standard includes it. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
