Subject: PaceFormatSecurity

From: Joe Gregorio <[email-masked]>
Date: Fri, 28 Jan 2005 14:37:13 -0500

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 concerns
for handling IRIs must also be taken into account. See Section 8 of RFC 3987.

}}}

== Impacts ==

== Notes ==

----

CategoryProposals

    Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Graham <[email-masked]>
Date: Fri, 28 Jan 2005 20:09:27 +0000

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

---

From: Robert Sayre <[email-masked]>
Date: Fri, 28 Jan 2005 15:55:10 -0500

> 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

---

From: Tim Bray <[email-masked]>
Date: Fri, 28 Jan 2005 12:56:58 -0800

> 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.

---

From: Tim Bray <[email-masked]>
Date: Fri, 28 Jan 2005 13:21:08 -0800

> 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 <img> and 
<script> and <object> and so on; are potentially lethal; I thought Joe 
got about the right level, except for the "what to do" stuff.  -Tim

---

From: Antone Roundy <[email-masked]>
Date: Fri, 28 Jan 2005 14:19:00 -0700

> Agree w/ Graham. We don't know what kind of relationship the publisher 

I agree with this, but...

> 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.

---

From: Robert Sayre <[email-masked]>
Date: Fri, 28 Jan 2005 16:40:01 -0500

Tim Bray 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
>  <img> and <script> and <object> and so on; are potentially lethal; I
>  thought Joe got about the right level, except for the "what to do"
>  stuff.

My problem with the "list" approach is that it can never be exhaustive. 
For example, it doesn't talk about table cells with a "background" 
attribute, and other junk that HTML components will happily render. And 
who knows what the WhatWG will have dreamt up.

Antone Roundy wrote:
>
>  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.

I agree that they could be better. However, the proposed text isn't even 
close to comprehensive (not that Joe is suggesting it is). I'm in favor 
of pointing to the best stable references we can and exuding paranoia.

Perhaps we could crib a bit from RFC 2557 (HTML email).[0]

Robert Sayre

[0] http://www.faqs.org/rfcs/rfc2557.html

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 28 Jan 2005 16:57:37 -0500

> 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

---

From: Robert Sayre <[email-masked]>
Date: Fri, 28 Jan 2005 17:01:06 -0500

>unable to find such a reference myself. Maybe someone else has better

I guess the question is whether we can and should outline HTML security 
issues.
I don't think we can or should.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Fri, 28 Jan 2005 15:10:40 -0700

> My problem with the "list" approach is that it can never be exhaustive.

True.  So I think we should suggest (in addition to having a list of 
particularly risky stuff like what's in the Pace), for HTML as well as 
for CSS, that applications operate from a list of trusted markup and 
delete everything else.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Jan 2005 17:13:26 -0800

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

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Fri, 28 Jan 2005 21:24:11 -0500

> 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-

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 29 Jan 2005 06:05:43 +0100

On Fri, 28 Jan 2005 17:01:06 -0500, Robert Sayre <[email-masked]>  
wrote:

> 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»

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 29 Jan 2005 06:06:54 +0100

On Fri, 28 Jan 2005 13:21:08 -0800, Tim Bray <[email-masked]> wrote:

> <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.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 29 Jan 2005 06:10:19 +0100

On Fri, 28 Jan 2005 17:13:26 -0800, Paul Hoffman <[email-masked]> wrote:

> Many elements are consider 'unsafe' in that they open clients to one or  
> more types of attack. Every client should consider carefully their  
> 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.

---

From: Dan Brickley <[email-masked]>
Date: Sat, 29 Jan 2005 06:28:04 -0500

* Asbjørn Ulsberg <[email-masked]> [2005-01-29 06:05+0100]
> issues, they aren't nearly as important to mention as those that lie  

As far as SVG goes, I suspect a lot of the issues will be around
Javascript, just as in (X)HTML.

Dan

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 29 Jan 2005 12:32:53 +0100

* Tim Bray wrote:
>experts; Scott/Ted/Paul, any guidance?

http://www.ietf.org/rfc/rfc3552.txt
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Joe Gregorio <[email-masked]>
Date: Sat, 29 Jan 2005 10:18:12 -0500

> Yep. If he leaves that out of the pace, I'm all +1 to it.

Glad to hear it. I have changed the wording of the Pace
to remove all the 'what to do' text.

"The following is a short list of the potential problems that
processing and displaying markup can cause. This list is 
not comprehensive and every consumer of Atom must 
consider carefully which elements and attributes are 
appropriate to process and display."

Again, I'd be open to security by reference if we could point
to a source or sources that were at least as comprehensive
as the list in the Pace. Given the dearth of resources found 
so far, should we consider putting together an informational 
RFC on Security Concerns for Processing and 
Displaying (X)HTML? Is there a more 
appropriate WG for that work to take place in. 

    -joe

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 29 Jan 2005 17:25:56 +0100

>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-masked] · 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/