Bug 14772 – Pages loaded with special:// can load file:// resources that should not be allowed

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: New Bugs

[Rush Manbert]

Filed at the request of Geoffrey Garen (See http://bugs.webkit.org/show_bug.cgi?id=14765#c1)

If I load a page with a custom protocol that I have NOT registered as a local protocol with WebView, and that page contains references to certain types of local file:// resources, those resources get loaded by the page. This is supposed to be disallowed in the Safari 3 WebKit.

When loading the page with the custom protocol, you must resolve all of the file references to alsolute file:// URLs. Otherwise the special:// base URL from the main page is used to resolve their addresses and that just screws up.

What I have observed is that image, JavaScript, and CSS resources can be loaded, but flash files and references to *.html files cannot be loaded.

I have attached a Xcode project that demonstrates this problem. Please do the following:
1) Build the project. There will be warnings that Xcode does not know how to process the test.js file, but that doies not matter. All we're trying to do is copy test.js into the app bundle resources.
2) Run it against a nightly build of WebKit
3) The main page has 2 links. The one on top loads the demo file using the file:// protocol. Click it and see that the following things happen:
  3a) The alert is displayed that shows that the script file test.js was loaded
  3b) The "Back" link is colored green, which shows that the test.css file was loaded
  3c) The LocalImage.jpg file image is present. It has a couple of big plus signs and says "This is a local image file". (Sorry it's so big. The original is 2 inches by 1 inch in OmniGraffle.)
4) Click on the Back link to return to the main page
5) Click on the bottom link. This loads exactly the same file, but it does it using the special:// protocol. In the startLoading() method I resolve all of the file references to full absolute URLs before returning the HTML string, and the resulting HTML is displayed in the run log.
6) Note that test.js was loaded (the alert happened), test.css was loaded (the Back link is colored green), and the image file was loaded.
7) Note also that clicking on the Back link causes the (I guess) expected "Not allowed to load local resource" error.

This demo does not attempt to load a flash file and play it because I didn't want errors in the middle of the page load. To see that fail, build and run the demo project attached to bug #14765.

[Rush Manbert]

Created attachment 15694 [details]
Demo project that shows the problem.

[Geoffrey Garen]

<rdar://problem/5371288>

[Kevin McCullough]

So I learned something new today.  Here's what's happening.  For the security change there is a linked-on-or-after check that will enforce the stronger security if you link against a newer WebKit (newer than when the check was added).  The system webkit on tiger will not have this added security, and because of a versioning quirk neither does a locally built webkit.

The only way you can see this behavior, currently, it to use leopard (e.g. a WWDC distribution).  If you believe you are already linking against a Leopard System WebKit (use the command "otool -L <path to SpecialPictureProtocol.app/Contents/MacOS/SpecialPictureProtocol>" to see which WebKit it is linking against), then you may need to change your project settings in XCode to not use the Tiger SDK.

In XCode use GetInfo on the SpecialPictureProtocol project
In the General tab go to the Cross-Develop Using Target SDK:
Change that drop down to Current Mac OX (if in Leopard).

That should cause you to link against the latest WebKit and hit the linked-on-or-after check