> On Feb 10, 2016, at 12:17 PM, brodhage <brodh...@snafu.de> wrote: > > Why? Because any application accessing web content via the WebView framework > (Sparkle, Safari and many other apps) might allow to "launch special / > default behaviour" (for example "file://" or "ftp://"; or Safari which starts > iTunes if you click a link to any app store resources)
No, not if those apps are well-written. Denying navigation from a remote URL to a to file: URLs is a well-known part of the browser security model. I haven’t looked at the Sparkle source, but I suspect that the reason the WebView didn’t block that request completely was because Sparkle loaded the HTML into the view in a way that made it appear to be a local resource, not remote. No offense, but browser security is a very big, very complex topic that a *lot* of effort goes into. It does not sound as though you’re an expert at it. (I’m certainly not, though I seem to know more about it than you.) As with most big complex topics, it's unlikely that someone who’s not an expert at it is going to come up with an insight on how to make it better. > 1.) If a domain is accessed, then do not allow access to ANY other domain. Um, no. This would completely break almost every real-world website, and not because of analytics/ads. It is extremely common to host page resources like images or scripts on different subdomains of a site, and also to use CDNs to optimize access time of static resources. As an experiment you could build yourself a little browser with a WebView, implement such a policy in your delegate callbacks, and try browsing with it to see how broken the web would be. > 2.) If a web content (or included resources) tries to access "unusual" > resources (like "file://" or "ftp://"; or "http://192.0 <http://192.0/>..." or > whatever) then ask the user for confirmation. * Yes, browsers already block requests for file: URLs, if the request comes from a page not loaded from a file: URL. * There’s nothing insecure with a page navigating to an ftp: URL, or other URL schemes that have apps registered to handle them, like itms:. It’s very common, especially on iOS. * The security considerations for obviously-LAN domains like 192.168.*.* are probably pretty complex, and I won’t answer as I’m not an expert. —Jens _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
