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
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
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 :) I'm +1 on the pace, particularly now that the prescriptive text has been removed. 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. - Sam Ruby
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
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."
PaceFormatSecurity
-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?
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 to be updated?
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. Also, you have dropped all references to CSS. -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceFormatSecurity to be updated?
I had updated PaceFormatSecuruty based on feedback, removing all the proscriptive prose about removing elements and just pointing out potential security problems. -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceFormatSecurity to be updated?
On Feb 2, 2005, at 12:31 AM, Robert Sayre wrote: 10.1 HTML and XHTML Content I've dressed this up as PaceSecuritySection: http://www.intertwingly.net/wiki/pie/PaceSecuritySection
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?
Tim Bray wrote: There was a huge amount of discussion around PaceFormatSecurity, with input from our AD, and what smelled like converging language on the list. Is someone going to update the Pace to take that into account? -Tim --- 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. Atom Processors should pay particular attention to the security of the IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, and LINK elements, but other elements may also have negative security properties. (X)HTML can either directly contain or indirectly reference executable content. 10.1.1 URIs Atom Processors handle URIs. See Section 7 of RFC 3986. 10.1.2 IRIs Atom Processors handle IRIs. See Section 8 of RFC 3987. --- Robert Sayre
s/PaceFeedState/PaceFormatSecurity/ bleah
Sorry, typo. I repeat: there was lots of discussion, good input, and what smelled like convergence. Someone needs to update PaceFormatSecurity. -Tim
Re: PaceFormatSecurity
* Dan Brickley wrote: >> 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. If people think http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html is insufficient in this regard, now would be a good time for comments on the document. If there are a lot of issues around scripting, I should point out that it is essentially unreasonable to expect security con- siderations for a script media type to say much more than that it is exceedingly dangerous for a receiving user agent to execute such content in an uncontrolled manner. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
PaceFormatSecurity Updated
On Sat, 29 Jan 2005 06:06:54 +0100, Asbjørn Ulsberg <[EMAIL PROTECTED]> wrote: > 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 and > >
Re: PaceFormatSecurity
* Tim Bray wrote: >At this point we should appeal to our designated IETF culture/process >experts; Scott/Ted/Paul, any guidance? http://www.ietf.org/rfc/rfc3552.txt -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
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
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»
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 and
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
> 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
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
On Friday, January 28, 2005, at 02:40 PM, Robert Sayre wrote: Tim Bray wrote: On Jan 28, 2005, at 12:55 PM, Robert Sayre wrote: > 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. Whereas you could technically get by with warning-by-reference, I think that it's OK and fact probably essential to point out that and
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
On Fri, 28 Jan 2005 15:55:10 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote: > 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. 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. -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceFormatSecurity
Tim Bray wrote: On Jan 28, 2005, at 12:55 PM, Robert Sayre wrote: > 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. Whereas you could technically get by with warning-by-reference, I think that it's OK and fact probably essential to point out that and
Re: PaceFormatSecurity
On Friday, January 28, 2005, at 01:55 PM, Robert Sayre wrote: 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 agree with this, but... 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. I took a look at these, and didn't find them particularly enlightening. If there were an RFC with a more comprehensive and clear explanation of potential security issues with HTML, I wouldn't be opposed to simply referring to it, but given that I haven't seen one, I'm in favor of including more detail here. In section 10.1.2 (CSS), we might suggest stripping out all untrusted styling rather than all styling. For example, an application may have a list of things it trusts not to be abused, like text-decoration, perhaps color (yeah, it can be used to make text invisible--is that a SECURITY problem?), etc., and strip out everything else, whether it's a known security issue, or simply unknown.
Re: PaceFormatSecurity
On Jan 28, 2005, at 12:55 PM, Robert Sayre wrote: 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. Whereas you could technically get by with warning-by-reference, I think that it's OK and fact probably essential to point out that and
Re: PaceFormatSecurity
On Jan 28, 2005, at 12:09 PM, 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. I tend to agree with Graham; point out the potential security hole and give some indication of its seriousness and abuse potential, but don't prescribe how to deal with it. At this point we should appeal to our designated IETF culture/process experts; Scott/Ted/Paul, any guidance? -Tim PS: Good work, Joe, thanks.
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
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
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