[Project_owners] Rewriting a browser inside a XUL app
thaths at openscroll.org
Wed May 19 13:31:08 EDT 2004
Ben Bucksch wrote:
> Sudhakar Chandra wrote:
>> <browser id="parsed-rss-feed"
>> src="chrome://habarixenu/locale/about.html" flex="1" onload="return
>> var parsedDocument = window.frames.document;
>> parsedDocument.body.innerHTML = parsedContent;
> Another problem with this: Depending on how you wrote this, you probably
> gave remote content from RSS local chrome rights, creating a gapping
> security hole. Please don't use chrome: with content (even snipplets)
> from the network.
Here is how I have written it at present:
- The browser element opens up a local HTML page through a chrome://
url. The about.html page is installed as part of the application.
- The UI of the news aggregator is your basic two-pane approach. The
tree of the feeds is shown in the left frame. The right frame is where,
in the beginning, the contents of about.html are displayed.
- When the user clicks on a feed they are interested in, the application
downloads the RSS (checking the timestamp on a local copy first blah
blah blah) for that feed from the remote site. The rss is stored in a
local file. This file is then parsed and HTML content is generated
based on the items in the feed. This generated HTML content is the one
in parsedContent variable.
Is this a potential security hole? The fundamental function of any news
aggregator is to parse remote RSS feeds and display the content in some
format inside the chrome. By your reasoning, all news aggregators open
up potential gaping security holes because they put untrusted remote
content into chrome.
"Okay, brain. You don't like me, and I don't like you, but let's get
through this thing and then I can continue killing you with beer."
-- Homer J. Simpson
Slacker Without Borders http://openscroll.org/
Key fingerprint = 8A 84 2E 67 10 9A 64 03 24 38 B6 AB 1B 6E 8C E4
More information about the Project_owners