In August, 2006, James Snell, James Holderness, and Sam Ruby all blogged about
a feed exploit test suite which they had developed and planned to make widely
available after a 1-month "by-request-only" period.  That 1-month is up and the
test suite is public and sage fails many of the tests.

See: http://www.snellspace.com/wp/?p=448

There's a known exploit out that lets you write a malicious feed that will
enable you to read files from a users desktop! (see also secunia advisory
http://secunia.com/advisories/21839/).

http://www.gnucitizen.org/blog/cross-context-scripting-with-sage/

The rest that follows is a quote from the above article:

First: Sage rendered “&lt,&gt” as “<>”. This means JavaScript can be
executed when HTML tags are turned off (not the default).

Second: Logical mental progression put forward the question, what if we
reversed it? “&lt, &gt” became “<>” when HTML tags were turned on (THE
DEFAULT). This means we can effectively hack the latest version of Sage via RSS
Injection regardless of which mode is set.

Thirdly: Sage converts the feed into an HTML file and stores it on the local
system. This means we were now in the browser’s local zone policy. From here
we could read any file from the local system.

Sorry for bug spam. I forgot to mention that there's a proof of concept feed at
http://www.gnucitizen.org/blog/cross-context-scripting-with-sage/feed.xml

Fixes already in trunk, see bug 6958.  Will backport for 1.3.x branch.

In Sage 1.3.7: content sanitization put in place.

on Sage 1.3.8/Firefox 1.5.0.7/Windows XP

When turning on "Open Feeds In Contents Area", Sage 1.3.8 fails
#3 and #258 at http://www.snellspace.com/public/everything.atom

Could you fix them also?

I confirmed a bug, too.I reopen this bug.

Sorry.

I confirmed a bug with version 1.3.8, too.I hope reopen this bug.

Regarding the failure of tests 3 and 258, see bug 15767.