[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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