Semantic of NPN_GetURL. Local files. History

John Yani vanuan at
Thu Feb 23 13:35:15 PST 2012

I am writing a plugin which intercepts data of a mime type, processes
it, generates an HTML result, and redirects the browser to this newly
created html file on the local drive.

I have two points, concerning implementation/semantic of NPN_GetURL ( ).

The first point concerns security issues

Some browser implementations, namely WebKit and Mozilla forbids
opening local files ("file://") when the plug-in is on a remote
(http://) page  (
) .
As long as the plugin can open sockets and read local files directly
and have the same rights as a browser, I don't see any reason to
forbid opening local files with NPN_GetURL.
I could see a security breach if a browser has broader rights than a plugin.
So, successful attack would require:
1) browser has broader rights than a plugin; (npapi plugins run in a
sandboxed environment, which is not the case; at least it can't be for
Windows' filesystems)
2) user installs the malicious plugin; (if I was an attacker, I would
just prompt user to install a trojan)
3) specifically crafted page includes <object
src="file_you_want_to_steal"> and sends the content to the plugin,
which sends it to you using sockets.
As you can see such attack is quite complicated.
Did I miss something?
So, I think the semantic of NPN_GetURL should clearly state if opening
"file://" using a plugin on "http://" page is possible.

The second point is a feature request concerning browser history.

As you know NPN_GetURL supports target option. If it is "_self" url
will be opened in current page. The problem is that a page page with
plugin is saved to history. So when I click back when I'm on html
result page, the content is redirected to the plugin which generates
an html result and redirects me there. Endless loop.
What I propose is to add a new target option "_self_no_history". Its
semantics would be the same as "_self", but the current page would be
deleted from history before redirect. So when I click back, I'll be on
the page before

What do you think?

More information about the plugin-futures mailing list