[webkit-dev] Security advice for linux browsers based on WebKit

[Serge Noiraud]

Hi,

I'm writing a webkit application which use only local files ( gramps-project )
I use python-webkit and pywebkitgtk. This is not a browser for the user.

If I understand correctly, in a near futur, my application will not work.
Is there a way to avoid this kind of problem ?
Can we authorize one application to use local files ?

I use in python :

        self.window = webkit.WebView()
        settings = self.window.get_settings()
        settings.set_property("enable-developer-extras", True)

Can we set this property too ? and how ?
Does this mean python-webkit and pywebkitgtk should take care of this ?

Adam Barth wrote:
> If you don't use WebKit to build a browser on Linux, you can ignore
> this message.
> 
> By default, WebKit allows local HTML files to inject script into any
> web page.  That means that if you open a local HTML file on your
> machine, it can effective XSS every web site, including the user's
> bank or webmail provider.  To protect against this threat, we have the
> following setting
> 
> Settings::setAllowUniversalAccessFromFileURLs
> 
> which disables this behavior.  For legacy reasons, we default this
> setting to "true," but I'd like to encourage to use the "false"
> setting by default in your browser, especially if your browser runs on
> Linux.
> 
> This issue is particularly important on Linux because many Linux users
> use a network file system, such as AFS or NFS, which maps the entire
> world into the local file system.  For example, if I made my home
> directly world-readable, it's quite likely that I would be able to
> control this URL on your user's machines:
> 
> file:///afs/cs.stanford.edu/u/abarth
> 
> If you don't override WebKit's default setting, I might be able to
> leverage this ability to read your user's email or transact on your
> user's bank accounts.
> 
> Of course, even with the "false" setting, I might still be able to
> read the contents of your user's /etc/passwd file or other sensitive
> information in your user's file system.  Over time, I hope we can
> further restrict the privileges granted to file URLs.  However,
> removing universal access is a necessary first step.
> 
> Please let me know if you have any questions.